Auditors reproduced 45-plus billing bugs across 110 AI usage tools, most often retries counted as new work
An audit of 110 AI usage tools reproduced more than 45 metering bugs, most often retries counted as new operations. The authors did not publish an overbilling rate, so teams paying per usage should check their own logs before trusting an invoice.
The Engineer · Build desk
Three figures from the audit authors' examples. A retry chain of 429, timeout, then success is one logical operation with 3 executions, so a meter counting executions bills 3x. A median of 2.5 steps per operation over successful attempts becomes 4.0 over total consumption including retries.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Executions in one 429, timeout, success retry chain | 3 executions | 1 | |
| Median steps, successes | 2.5 steps per op | 5 | |
| Median steps, with retries | 4 steps per op | 5 |
What happened
- Each bug was reproduced against a pinned commit with the tool's own parser on synthetic fixtures, and 25 fixes have since merged upstream.
- The free agentmeasure checker scans local Codex and Claude Code session logs in about thirty seconds, with nothing uploaded and no account.
- The authors sell a $10 anomaly diagnosis and a $20 metering QA check; the tools themselves are free.
Why it matters
- exposure A dashboard built from the same records as the meter will show nothing wrong, so reconciling an invoice against it cannot catch a retry billed as new work.
- decision Buyers have to ask whether a vendor meters executions or logical operations, and what the meter reports when a field is missing: a zero or an explicit unknown.
- constraint The only source is the authors' own post, and they sell the diagnosis the free checker leads to. Pinned commits make the findings checkable, but we have no outside confirmation of them.
The retry case is a counting rule. A chain of 429, timeout, then success is one logical operation run three times [1]. If the meter keys on executions, the customer is billed three times for one result [1]. Every record in that chain is correct on its own, so a dashboard built from the same records stays green [2]. The auditors call it the single most common finding [2].
Lines re-emitted after a crash look like new usage, much as a retry does, and byte-identical duplicates inside session files turned up in more tools than the auditors expected [3]. They say the fix is to dedupe on record id before counting anything, and that its dullness is why it goes undone [3].
In some tools, cached-read tokens ride the same field as fresh tokens and are priced the same [4]. At cache-hit rates typical for agent workloads, the authors say, that is not a rounding error [4].
The grain problem is subtler, and the post's example shows it: a median of 2.5 steps per operation counted over successful attempts, against 4.0 counted over total consumption including retries [5]. If both describe one workload, the second is 1.6 times the first [11]. The authors say both are defensible and only one matches what the bill should say [5].
In the worst of the five classes, a boolean "consumed" field reused for "not set" turned 9,107 referenced observations into a confident zero [6]. The audit's answer is a state for not knowing. When an export lacks the field that decides a metric, the finding is marked UNPROVABLE and left unfilled [7]. The authors wrote: "Most metering disputes we've seen are not dishonesty; they're someone's UNPROVABLE rendered as a confident number." [8]
How far these numbers travel depends on what was tested. Each bug was reproduced with the tool's own parser on synthetic fixtures [12]. That shows a parser mishandles a shape. How often the shape occurs in production, or what it cost anyone, the fixtures cannot say, and "45+" counts bugs, not affected tools [13]. For the retry result to transfer to your invoice, your runtime has to retry the way the fixture does and your vendor's meter has to count executions.
The free checker works on files on your machine. It scans Codex and Claude Code session logs locally, in about thirty seconds, with nothing uploaded and no account [9]. In our view, a clean scan says your logs are internally consistent. Whether the vendor's meter agrees with them is a separate comparison. The figures are the authors' own, as of 2026-10-14 [13].
What to watch
- Whether an independent party reproduces a finding from the pinned commits and fixtures the index links.
- Whether the count of merged upstream fixes moves past 25, and whether any billing vendor, not just a log parser, is added to the audit.
- Whether anyone publishes an overbilling rate from production invoices. The audit itself did not.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence45
- Adoption10
- Hype gap+20
- Incentives55
- Confidence50
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
A runtime retry chain of 429, timeout, then success is one logical operation with three executions; if the meter counts executions, the customer pays 3x.
- [2]
Retries billed as new operations is the single most common finding, and dashboards stay green the whole time because every individual record is correct.
- [3]
Re-emitted lines after a crash look like new usage; byte-identical duplicates inside session files appeared in more tools than expected; the fix is to dedupe on record id before counting anything, which is why it does not get done.
- [4]
Where a tool reports cache accounting, cached-read tokens sometimes ride the same field as fresh tokens and are priced identically; at cache-hit rates typical for agent workloads that is not a rounding error.
- [5]
A median of 2.5 steps per operation computed over successful attempts differs from 4.0 computed over total consumption including retries; both are defensible, only one matches what the bill should say.
- [6]
A boolean 'consumed' field reused for 'not set' turns 9,107 referenced observations into a confident zero.
- [7]
The audit uses five states: Verified Mismatch, Fixed/Re-verified, Conformance Pass, UNPROVABLE and Not-a-bug; if the export lacks the field that decides a metric, the finding is UNPROVABLE, stated out loud and not filled with a zero.
- [8]
"Most metering disputes we've seen are not dishonesty; they're someone's UNPROVABLE rendered as a confident number."
- [9]
The free checker, run as 'agentmeasure check', scans Codex and Claude Code session logs locally for duplicate records, retry chains and token anomalies in about thirty seconds, with nothing uploaded and no account; v0.7.0 shipped 2026-10-14.
- [10]
The tools are free; the authors charge $10 for an anomaly diagnosis and $20 for a metering QA check, and a no-finding result is a valid deliverable.
- [11]
If both step-per-operation figures describe the same workload, the consumption-based figure is 1.6 times the successful-attempts figure.
- [12]
The audit covers 110 AI usage tools so far, each tested with the tool's own parser on synthetic fixtures.
- [13]
As of 2026-10-14 the authors report 110 tools audited and 45+ reproduced metering bugs.
- [14]
Every bug was reproduced against a pinned commit and every fix re-verified after it landed upstream; 25 fixes have merged so far.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toWe audited 110 aiAI usage tools for metering bugs - 45+ reproduced, every finding linkable
1 article · October 13, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Usage-Based PricingFollow
- Billing auditsFollow
- AI usage meteringFollow
Entities
- CodexFollow
- Claude CodeFollow
- AgentMeasureFollow