Skip to main content
Xerg currently supports QM as an explicit, host-independent one-shot source. The QM adapter consumes qm-snapshot/v1; it does not know whether QM runs locally, in Docker, on AWS, on Fly.io, or elsewhere. Collection is a separate transport concern. The fully certified path is QM on Fly.io with xerg_export/v1 views and a pinned one-shot exporter in the QM core image. QM is never auto-probed by xerg init. Operators choose one of three modes:
  • Snapshot: audit an already-created sanitized artifact with no database access.
  • Strict direct: connect with a dedicated xerg_reader that can select only export views.
  • Fly contained: use the QM core process’s existing database authority during one operator-authenticated, read-only export. This mode does not claim database-level least privilege.
For example:
The collector owns PostgreSQL and Fly access. It creates a bounded qm-snapshot/v1 JSONL artifact, and the synchronous QM adapter audits only that sanitized artifact. No database connection exists in the core adapter, and database credentials never enter Xerg Cloud.

​
What is reported

Xerg reports durable recorded model observations, underlying request counts where QM supplies them, input/output/cache token buckets, positive reported cost, catalog estimates for deterministic models, run timing/state/attempt evidence, harness/surface dimensions, and pseudonymous scope attribution. Current retained run_activity adds a local tool inventory, call/result pairing, error/truncation flags, durations where defensible, and result byte counts. It is never associated with model spend and never crosses the push wire.

​
Observation granularity

  • Pi, Claude, and OpenCode rows are request observations only when harness mapping is exact and the row count reconciles with QM turn metrics.
  • Codex rows are aggregate turn observations with a reconciled underlying request count.
  • When a durable run row is absent but a turn metric is present, Xerg creates a synthetic run with the metric’s pseudonymous run ID. Exact harness/model-count reconciliation remains request-level and retained activity stays attached.
  • Unknown, ambiguous, count-unreconciled rows, or model rows lacking both a matching run and turn metric remain aggregate.
  • Aggregate observations never enter request-sequence detectors.
QM turn metrics expose input and cache-read/write totals but no output-token total. Xerg retains output tokens from the durable model rows and does not claim that bucket was independently reconciled at the turn level. QM model timestamps also vary by harness. Xerg uses the authoritative run/turn timestamp for daily attribution rather than pretending Pi or OpenCode flush time is request time.

​
Finding and signal coverage

QM’s current export cannot prove stable charged attempt chains, exact tool input/result/state fingerprints, or cache-entry write/read lifecycles. Therefore retry-waste, tool-loop, and cache-thrash are explicitly unavailable rather than inferred. QM may still emit neutral signals where its export directly supplies their observed metrics, including context outliers, context growth, fixed-cadence activity, premium-model routine labels, or deep-loop activity. Current-window tool streaks and attempt counts remain neutral evidence only. Every audit includes detector coverage and source stability. A result such as $0 identified waste is not a claim that unassessed or unpriced usage was free.

​
Hosted behavior

An explicit push sends normal Audit Push Payload v6 summaries with environment: remote and a deployment pseudonym. Raw QM session, scope, run, turn, or call identifiers never enter the snapshot, local cache, report, log, or push payload. Hosted dashboard, trends, Compare, Optimizations, Ask Xerg, Xerg Slack, and hosted MCP read the resulting summary like any other runtime audit. QM itself does not gain native access to Xerg’s hosted MCP. A QM Slack agent can explain setup, audit an authorized pre-created snapshot in a private scope, interpret results, and read an already-pushed summary. It cannot start live Fly or database collection. Continuous follow capture, durable tool-history capture beyond QM’s retention window, and live Slack-triggered collection are not currently supported; pushing remains an explicit approval step.