fix(server): Codex usage bills requests whose counters rewind to an earlier snapshot#29385

Problem

When a Codex request's cumulative token counters fall back to an earlier snapshot of the same rollout, the usage reader drops that request and counts it as malformed. The Usage page then undercounts and shows "1 malformed or inconsistent usage record(s) were skipped" for good, because the cached rollout is never re-read. Reproduced on main (ac8dce0cc3) with the rollout from the issue: 1,670 tokens and 1 skipped record, instead of 1,910 tokens and none. The last request's totals (1,300 in / 260 out) fall below the previous snapshot (1,400 / 270). Totals minus the request (1,100 / 220) give back the second snapshot exactly.

Change

• codexUsage.ts: for a request with cumulative counters, take base = cumulative − last and require it to be valid usage. It is then accepted in any of these cases, and only last is billed:
  • there is no baseline yet;
  • base equals the baseline exactly (the old exact-delta case);
  • base is at or below the baseline in every field: a rewind, which includes the old restart case where base is zero.
• A rewind is accepted only if it is a restart or its timestamp is later than the last billed request's. That timestamp is stored in a new optional scan-state field, lastRequestTimestampMs. #22392 already relies on the same fact: a replayed event keeps its original timestamp. So a replay of an older request, already counted, is still counted as malformed, as on main. When no timestamp has been recorded yet (a state cached before this field existed), rewinds are refused until the next billed request records one. The recorded timestamp only ever moves forward, so an accepted request with an older timestamp cannot reopen the window.
• Counters that rise past the baseline in any field are still counted as malformed. The rule accepts any lower remainder, not only one equal to an earlier snapshot. Matching earlier snapshots exactly would mean keeping snapshot history in the persisted state.
• usageScanCache.ts: the scan cache goes to v11, and v10 is added to the legacy file names. As in #23729, cached Codex entries that recorded skipped records are re-read once, so the warning clears for rollouts that will never change again. Clean entries pick up where they left off. The new state field is optional, so their cached states still decode.

Scope and approval

Fixes pingdotgg/t3code#29363

Verification

• Red test first: parseCodexLine > bills a request whose cumulative counters rewind to an earlier snapshot (commit 6eda0537e2). On main it fails with processed [1200, 120, 350, 0, 12], skipped 1; with the fix it passes with [1200, 120, 350, 240, 12], skipped 0. The fifth request shows that billing after the rewind still lines up with the new, lower baseline.
• parseCodexLine > does not bill a replay of an earlier request as a counter rewind (…): two cases, a fresh scan and a state resumed from before request timestamps were recorded. In both, a verbatim replay of the second request after the third is not billed and counts 1 skipped record, as on main. Each case failed against the commit before its guard: processed [.., 120, ..], skipped 0.
• parseCodexLine > does not let an older accepted request reopen the rewind window for a replay: a legacy request timestamped before the last billed one is accepted, and a replay after it is still refused. It failed with the replay billed ([1200, 120, 12, 120], skipped 0) before the timestamp was kept monotonic.
• The v10 upgrade cases in usageScanCache.test.ts and UsageService.test.ts now run, so a skipped v10 Codex entry is re-read while a clean one picks up where it left off.
• vp test run on codexUsage.test.ts, usageScanCache.test.ts, UsageService.test.ts, usageTranscriptReader.test.ts: 112 passed. vp run check:changed: format, lint, knip, typecheck (3 packages) and tests all pass.
• Runtime: the issue's rollout, through parseCodexLine and through readTranscriptRecords (buffered, and streaming with a threshold of 0):

• Real app: a dev server with a fresh database (T3CODE_DEV_SEED=0) and CODEX_HOME pointing at a directory holding only that synthetic rollout. Usage page filtered to Codex, 30 days, Tokens. Preview browser, 1280×800, DPR 1, light theme.
  • Upgrade path: in an earlier run, the server that captured "Before" was reloaded on the first fix commit (637874bd7b). It re-read its v10 cache entry (3 records, 1 skipped) into v11 (4 records, 0 skipped).
  • "After" was captured at 94837c3366 on a fresh database. Later commits only change how the request timestamp is recorded and what happens when none is recorded. Neither affects this rollout, and the runtime output above at d232272fe4 is identical.

Evidence: Usage page, Codex filter, 1280×800, light theme

Before	After	Diff0	DiffT (10% fuzz)
ac8dce0cc3	94837c3366	ac8dce0cc3 vs 94837c3366, 53,587 px	ac8dce0cc3 vs 94837c3366, 33,713 px

What else changed between the two captures: the warning line is gone, so everything below it moves up 60px, which lights up most of the diff images. The sidebar thread age also changed ("now" → "1m"). The page has no other differences.

Not checked: desktop and mobile clients. Neither changes; they show the same server summary. The reporter's real 786-rollout corpus was not replayed here.

Fix by Claude Opus 5.5 (Claude Code, high effort) through T3 Code's automated issue flow, reviewed by GPT-6.1 Sol (Codex) and Claude Opus 5.5.

🤖 Generated with Claude Code