T3 Code · Linux verification · September 25, 2026
#13650 usage scan tests
Pull request · Original issue #7258 · Earlier proposal #7265
Local accuracy and regression checks pass. Full GitHub CI, Macroscope correctness and CodeRabbit’s final incremental review pass on the latest commit. Macroscope requires human review before approval. No PR has been merged or closed.
Large history records must not erase usage. Records above 8 MiB now stream through the existing JSON tokenizer, retaining usage and attribution fields while passing over tool/message content. Ordinary records retain native parsing. No record is discarded because of its size.
Accuracy in the real app
The fixtures contain a 517 MiB Codex tool output with usage before and after it, plus a 65 MiB Claude assistant record carrying 10,000 tokens and a subsequent 200-token record. The correct initial total is 10,520 tokens. A fresh reader-level retest of #7265 at d1b28acc counts only 520 on these same fixtures: it drops the large Claude record containing 10,000 tokens. The replacement preserves that record.
Main: 10,200 tokens. Codex usage is missing.
Replacement: 10,520 tokens, including Codex’s 320.
UI totals are rounded; exact values were asserted from real WebSocket responses. Both fixtures use current timestamps, so 7/30/90-day views must agree. The Cursor-login banner is unrelated to these transcript scans. GitHub’s attachment upload was rejected, so screenshots are hosted externally.
Incremental updates and restart
| Action | Expected and observed |
|---|
| Initial scan, all three date windows | 10,520 |
| Copy the Claude file to a second path | 10,520 — no double-counting |
| Append 100 input + 110 output tokens | 10,730 |
| Reload browser | 10,730 |
| Terminate and restart the test server | 10,730 |
Warm scan after restart: 3 ms. Browser verification reported no page errors. During a forced full rescan, 30 environment-metadata requests all succeeded; the slowest took 33 ms. This is a local responsiveness probe, not a load-test guarantee.
Scan time and memory
| Fixture | Main: median / peak RSS | Replacement: median / peak RSS | Accuracy |
|---|
| 20,000 ordinary records | 72 ms / 97 MiB | 64 ms / 108 MiB | Exact counts match |
| 65 MiB record containing usage | 195 ms / 334 MiB | 188 ms / 127 MiB | Exact counts match |
| 517 MiB tool-output record | 1085 ms / 1628 MiB | 1328 ms / 168 MiB | Main loses the transcript; replacement keeps both usage events |
Three fresh Node processes per implementation and fixture. Median elapsed reader time and maximum process RSS across the three runs; filesystem caches were not cleared. The 517 MiB comparison is a successful read versus a failed read, not a speedup. The streaming dependency adds modest process overhead for ordinary records. A separate run with a 64 MiB V8 old-space limit also completed the 517 MiB scan correctly; total process RSS reached 191 MiB in that configuration. A JavaScript heap limit does not cap buffers or total process memory.
Twenty-nine real Codex/Claude transcripts, 309 MiB and 9,680 usage records, produced identical full reader results. Five alternating runs per file: sum of per-file medians fell from 680.3 ms to 574.8 ms (about 15%). Private history contents were not published; temporary copies were deleted.
Before and after: visible elapsed timer
Same 647 MiB dataset, 90-day view and Refresh action. Real-time playback. The large stopwatch starts at the actual click and stops when the received result appears in the test caption. The caption is test instrumentation, not product UI.
| Full rescan | Before | After |
|---|
| Visible stopwatch | 1.778 s | 2.359 s |
| Server scan | 1,631 ms | 2,196 ms |
| Exact usage (expected 10,730) | 10,200 — 530 missing | 10,730 — correct |
This case proves the accuracy fix, not a speedup. Main finishes sooner because it fails to read the Codex transcript. For a speed comparison with identical results, see the 29-file real-history benchmark below: 680.3 → 574.8 ms (about 15%).
File modification times changed before each refresh to force complete rereads; filesystem caches not cleared. Sequential local Linux runs without competing scans. These are refresh timings, not initial navigation timings. No page errors. Initial navigation is visible before each timed action.
Additional after-only full rescan and cached refresh recording: cached server scan 4 ms. This is not a before/after comparison.
CodeRabbit risk assessment
At 099777b85d: Minimal merge risk; Low security architecture risk; no established blocker. Failed reads preserve cached usage; resumed reads deduplicate old and new records. Source inspection agrees with those findings.
Remaining hardening: selected metadata and nesting have no explicit budget in the usage caller. Maliciously writable provider directories can still cause excessive memory use. There is no new filesystem endpoint. A future budget should explicitly surface incomplete usage, rather than silently omit records. This is not evidence that every possible input is bounded.
CodeRabbit's 41.67% docstring-coverage warning is separate from correctness. Its first full review had processing errors; the final successful incremental review covered three usage files. Macroscope correctness passes but requires human review for metering and shared-parser changes.
Regression coverage
- 215 server tests: usage readers/service/cache/pricing/aggregation, JSON projection and transcript import. Includes Cursor, OpenCode and Antigravity reader coverage.
- 132 shared/client/web tests: usage merging, formatting, refresh, state, pricing controls and charts.
- Large-record tests preserve Claude fast-mode pricing, Grok model allocation, Codex model switches, fork-copy suppression, repeated keys and deduplication.
- Byte-exact CRLF/UTF-8 boundaries, unfinished tails, appends, malformed records, rewritten files, persisted cache and transcript cleanup.
- Shared streaming helper matches JSON.parse across varied chunk boundaries; existing import allocation/depth limits remain tested.
- Server typecheck, scoped lint, formatting and whitespace checks pass.
- Full GitHub CI passes on the latest commit, including all server shards, the desktop build, release smoke tests and thread-transfer size ceilings.
Tested commit: 099777b85dd44f008ba59b20dc034e168b8348cd. Main baseline: e5a46d6c5d00b89afba5274a94d42428c8d79763.
Scope and limits
This changes server-side JSONL ingestion and the shared JSON selector. Token accounting, pricing, wire contracts and client layouts retain their behavior. Existing cache entries remain compatible, preserving saved usage after transcript cleanup. Real browser testing used the local web client; native Windows/macOS, Electron, mobile and remote/tunnel execution were not exercised locally.
Macroscope marks correctness as passed and eligibility as requiring human review because the change affects production usage/cost metering and shared JSON selection. CodeRabbit’s first run reported processing errors for all six files. Its final incremental review of the three changed usage files completed successfully with no actionable findings; that is not full successful coverage of the earlier shared-parser changes. This is not an automated approval to merge.
Memory use scales with retained usage metadata and results, not discarded tool-output strings; this is not a fixed cap on the entire server. General unreadable/malformed-source reporting remains the separate work in #11321, and provider accounting changes remain separate.