fix(usage): count each Antigravity call once#23622

Problem

Antigravity writes the same usage message to up to four places in a conversation database: the step's usage (steps.metadata field 9), the step's retry list (28 → 2), the generation's usage (gen_metadata.data 1 → 4) and the generation's retry list (1 → 17 → 2). The usage reader made a record for every copy. Only response-id copies were merged, and almost no usages carry a response id, so most Antigravity calls were counted three or four times. Every Antigravity figure on the Usage page (requests, tokens, API-equivalent cost) was about 3× too high.

Reproduced on main ed3f965e07 by running readAntigravityUsage on a conversation DB that stores one id-less call as a step usage, a step retry, a generation usage and a generation retry, all with identical counters. It returned 4 records.

Change

All of this is in apps/server/src/provider/Drivers/antigravityUsageReader.ts, inside one conversation:

• metadata() drops a retry entry whose counters (fields 2, 3, 4, 5, 9, 10) equal its entry's main usage, unless the retry carries an id the main usage does not. A retry with different counters, or with its own id, is still a separate record. If the main usage has no model id, it takes the dropped copy's model id, for both naming and pairing.
• usageCandidates() pairs each id-less generation usage with the next unpaired id-less step usage that has the same counters and the same usage model id (field 1), nth with nth, and emits one record per pair. The record takes the better timestamp of the two, and takes the generation's model if the step's is unknown. The copies of one call are identical usage bytes, so they always pair, even for models whose display names the step and generation write differently. Two real calls with equal counters both survive, and so do calls with different model ids. Step-only and generation-only usages are still counted.
• The response-id merge across files is unchanged.

Scope and approval

Fixes #17071 GitCafe: https://git.cafe/pingdotgg/t3code/issues/17071 Triaged bug via the automated issue flow. The fix follows the direction in the issue and its triage comment.

Verification

Tests in antigravityUsageReader.test.ts. Each new test failed before the change it covers and passes now:

• vp test run apps/server/src/provider/Drivers/antigravityUsageReader.test.ts apps/server/src/usage/UsageService.test.ts: 52/52 pass. These include the existing retry-with-different-counters, step-only and response-id merge tests. vp lint and vp fmt --check on both files are clean, and tsc --noEmit for apps/server passes.
• Runtime transcript at 4bdbca1039 (unchanged at 752c416341): the real reader on a constructed conversation DB.

• Performance: 3000 steps plus 3000 generations with identical counters read in about 250 ms, roughly the same as main. Most of that is the existing one-row-at-a-time generation reads. Pairing is one map lookup per usage.
• This is a server-only change with no layout change, so there are no screenshots. Not checked: real Antigravity conversation databases. There are none on the test machine, so all databases were constructed with the field layout described in the issue.

Claude Opus 5.5 (claude-opus-5-5) via Claude Code in T3 Code.

🤖 Generated with Claude Code

Independent review and proof audit (head 752c416)

Reviews (fresh read-only agents, full diff against main):

• Claude Sonnet 5.5: VERDICT: NEEDS_JULIUS. No over-count. It found two under-count paths that only someone with real data can rule on: (1) an id-less retry with the same counters as its main usage is always dropped, even if it was billed separately; (2) a step with no generation can pair with an unrelated generation that has equal counters and model, and with missing rows that collapses two calls into one. It also suggests softening the "steps and generations run in the same order" comment, because counts don't depend on order and only the timestamp chosen for a pair does.
• Claude Opus 5.5: VERDICT: MERGE. It found the same two under-count paths and judged both acceptable: they need missing rows, or a real retry that billed exactly the same counters. Non-blocking: when one side has model id 0 and the other has a real id, the pairing keys differ, so that call is still counted twice (the same as on main).

Can two real identical calls be merged? Across steps, no: R5 keeps both, as long as each call has its step and generation copies. Inside one retry list, yes: a retry with identical counters is treated as the successful call's own copy (R11).

Proof audit. Pass 1 found R3, R6, R7, R8 and R10 (the Usage RPC totals) had no test. The rows were then captured with the real reader and with UsageService.readSummary (the server.getUsageSummary RPC) on synthetic conversation DBs. The reader and the RPC agree on every row, before and after. Pass 2 audit: VERDICT: SUFFICIENT. Hashes checked, R3 and R8a rerun at head.

The capture driver's own "true calls" were 1 for R8a/R8b and 2 for R11. Audit pass 2 judged those expectations mis-designed against the counts in https://git.cafe/pingdotgg/t3code/issues/17071 (step usages = calls, every retry-list entry repeats its main usage's counters). The "Expected" column uses the audited expectation.

• Driver: ev23622.capture.test.ts, sha256 7183c1781a0bec97bc309244a2d43bc73556254d3b424e0ee8e7257fec12e607
• Transcripts: before.log (reader at merge-base f054d1b801, sha256 7bc213be…525309), after.log (reader at head, sha256 3511df28…a228a0e9), rerun.log
• Not verified: real Antigravity databases. A separately billed retry with identical counters (R11), and a generation and a step that have each lost their own partner, are under-counted by design.