## Description The Usage tab (Settings > Usage) showed completely different, and apparently wrong, data on a first check versus a second check minutes later — same session, no other sessions running concurrently. ## First read - Total cost: $42.61 - Total duration (API): 26m 22s - Total duration (wall): 2d 19h 30m - Usage by model: **only `claude-opus-5`** listed — 4.7k input, 106.7k output, 36.0m cache read, 2.2m cache write ($42.61) - Current session: 100% used ## Second read (same session

Usage report (/usage or settings Usage tab) shows materially wrong/incomplete data on first read, self-corrects later, same session

Status Open

Maintainer reply None cached

Activity 0 comments · opened Aug 17, 2026

Description

The Usage tab (Settings > Usage) showed completely different, and apparently wrong, data on a first check versus a second check minutes later — same session, no other sessions running concurrently.

First read

Total cost: $42.61
Total duration (API): 26m 22s
Total duration (wall): 2d 19h 30m
Usage by model: only claude-opus-5 listed — 4.7k input, 106.7k output, 36.0m cache read, 2.2m cache write ($42.61)
Current session: 100% used

Second read (same session, shortly after)

Total cost: $89.85
Total duration (API): 4h 45m 58s
Total duration (wall): 6h 22m 54s
Usage by model:
claude-opus-5: 2 input, 80 output, 23.3k cache read, 25.1k cache write ($0.2651)
claude-sonnet-5: 830 input, 847.2k output, 117.6m cache read, 5.1m cache write ($70.43)
claude-haiku-4-5: 34.4k input, 854.6k output, 76.3m cache read, 5.8m cache write ($19.16)
Current session: 4% used

Why this matters

The session in question was a long-running background job that dispatched many subagents with explicit model overrides (haiku for mechanical work, sonnet for judgment passes), per the user's own instructions. The first usage read showed 100% of cost attributed to claude-opus-5 with no sonnet/haiku line items at all — which looked like a serious cost/routing bug (as if every subagent's model override was being silently ignored and everything was billing at the most expensive tier). This caused real user alarm and back-and-forth before a second check revealed the "real" numbers, which line up with the intended haiku/sonnet routing and show only a negligible opus-5 sliver.

Whatever the underlying cause (stale cache, incomplete data at time of first render, a race in how the usage stats are aggregated for still-active/background sessions), the tab should not present partial/incomplete usage data as if it were final and complete — especially not omitting entire model line items. At minimum this should be clearly marked as "still aggregating" rather than shown as a final total.

Environment

Session ID: 2ac034d0-8c16-4957-a683-cd86d50c2126
The session was a background job (long wall-clock duration relative to API duration in both reads), which may be relevant to why its usage aggregation lagged.

View original on GitHub ↗