See the cost of reaching
a supported answer.
Follow captured usage through investigation, verification, and follow-up. Distinguish priced usage, estimates, and activity whose cost is unknown.
Account for the work behind the conclusion.
Keep usage attached to the case and the session that produced it. A rollup and a receipt that describe the same activity are counted once.
A cost shows the price version it was computed with. An unpriced model reads unpriced, never a fallback rate.
What happened in this change?
Follow an example from the instruction to the verified fix, then install RepoOps and open your own.
Implementation details & evidence
Never pay an AI invoice you can't verify
Metered AI billing bills four token types at four rates, per model, per tier, through retries and orchestration layers. Billing Guard keeps your own ledger, recomputes every day's expected cost from your own telemetry, and flags the difference against the provider's bill. All local, on data you already own.
Billing Guard ships today: the reconciliation engine runs in the RepoOps dashboard (the Billing Guard subtab under Telemetry), the repoops-billing-audit CLI, and the Claude Desktop extension, over the local telemetry capture, the Anthropic Admin API billing pull, and a versioned per-model rate card. Eight detectors need only the daily usage and cost reports, and those eight run in all three surfaces. The two request-level detectors (duplicate-request and ghost-prompt) are wired only in the dashboard, and they stay quiet until you point Claude Code's own OTLP log exporter at it; without that opt-in the dashboard reports the same eight. The hosted team rollup ships at /team/billing-guard: per-repo (not per-developer) reconciliation history, once a connected desktop syncs its sweep. Billing Guard detects and reconciles only. It flags what to dispute; it never caps, throttles, or blocks spend.
Why this exists
Nobody recomputes the bill
Third-party figures, attributed and linked in the research post. Anthropic and OpenAI dispute the reported error patterns.
The report
What Billing Guard flags
An illustration of what the CLI reports, not a verbatim transcript. The first run signs you in by email and downloads the audit engine; comparing billed against expected needs a provider admin key, and a run without one stays in telemetry-only mode. The same findings render in the dashboard's Billing Guard section with a per-day ledger and an evidence-bundle export.
repoops-billing-audit
$ npx repoops-billing-audit --window 30 [guard] recomputed 30 days from local telemetry x the per-model rate card [guard] ------------------------------------------------------------ [guard] 27 days reconcile inside the 2% tolerance band [guard] Jul 03 billed $41.20 vs expected $19.85 (2.1x) -> retry-storm signature [guard] Jul 07 billed $12.40 vs expected $0.00 -> no logged usage that day [guard] Jul 09 invoice delta +9.8x day-over-day -> runaway-invoice alarm [guard] ------------------------------------------------------------ [guard] 3 findings -> evidence bundle written for dispute
How it works
Three ledgers, one verdict
Your ground truth (ships today)
RepoOps captures Claude Code session telemetry locally across every tracked repo: per-request token counts by type (input, output, cache read, cache write), model, and timing. This is the customer-side ledger every audit starts from. It stays on your machine unless you connect a team and turn streaming on in settings, which pushes redacted batches (metadata only by default) to your team's audit log.
The provider's claim (ships today)
RepoOps pulls Anthropic's Admin Usage and Cost API: token usage sliced by key, workspace, model, and service tier, plus the daily cost report. Anthropic's own documentation lists cost reconciliation as a primary use case for this API.
The independent recomputation (ships today)
A per-model rate card recomputes expected cost from raw token counts, with cache reads and cache writes priced at their own multipliers. Token counts are the stable primitive; client-side dollar estimates are approximations, so comparisons use a tolerance band, not cent-equality.
The detectors (ship today)
Reconciliation findings mapped to the error signatures auditors report, plus the failure mode from the headlines. Eight run in the dashboard, the CLI, and the Claude Desktop extension. The two request-level detectors (duplicate-request and ghost-prompt) run only in the dashboard, the surface that reads the local request log.
- Billed usage exceeding logged usage beyond the tolerance band
- Charges on days your logs show no usage at all
- Implied per-token price that matches no published rate
- Duplicate-charge and retry-storm burst signatures
- A cache-read token share that diverges between your local telemetry and the bill, even when total cost stays in band
- Day-over-day invoice deltas (the runaway 10x pattern)
- Spend that restarts from zero, where the day before billed nothing and a day-over-day ratio has nothing to compare against
- The provider's own usage and cost reports disagreeing with each other
- The same request id logged more than once on a day (a definite double-log, not a statistical guess)
- A locally failed request that still carries a nonzero cost
variance-band / ghost-usage / rate-check / duplicate-burst / cache-share-divergence / delta-alarm / cold-start-spend / contradiction / duplicate-request / ghost-prompt
Evidence you can dispute with
A finding is only useful if finance can act on it. Each flagged day exports an evidence bundle: your token counts, the recomputed expected cost, the provider-reported figure, and the delta, ready to attach to a support ticket or chargeback.
Honest limits
Reconciliation has blind spots and Billing Guard says so in the UI: client cost figures are approximations (hence the tolerance band), telemetry is opt-in so a day without local capture reads cannot-verify rather than becoming a finding, and some Anthropic line items (Priority Tier, code execution) appear in only one of the two provider endpoints, so they surface as cannot-cross-verify annotations. Scope matters too: local telemetry sees one working directory while an Admin key bills the whole organization, so the detectors that compare against local capture are marked scope-sensitive rather than treated as gospel. The hosted rollup at /team/billing-guard groups by repository, not by developer, and stays honestly empty until a connected desktop syncs a sweep. And Billing Guard only ever detects: no budget caps, no kill switch, no throttling. It tells you what to dispute; it never blocks the spend.
Figures above are third-party claims, attributed inline and linked from the research post. Anthropic disputes the reported error patterns and says it does not charge for incomplete requests or route customers to older models.