[BUG] /usage "Current session" (5h) shows significant usage with no new work in that window — unclear whether cache-read replay counts against the limit

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title: /usage "Current session" (5h) shows significant usage with no new work in that window — unclear whether cache-read replay counts against the limit

What happened

I have a single long-running Claude Code conversation (session) that's been open across two calendar days, with multiple auto-compactions along the way. Yesterday (Aug 11) I did substantial work in it: several file edits, a git commit, installing and authenticating the GitHub CLI, creating a fork, pushing a branch, rebasing, force-pushing, and opening a PR.

Today (Aug 12), before doing anything else, I sent two short, text-only messages in that same conversation (no tool calls, no file edits, no commands) asking a general question about Claude Code. When I checked /usage after that, it showed:

• Current session: 17% used, resets 1:29pm (a 5-hour rolling window that, per the reset time, started around 8:29am today)
• Current week (all models): 19% used, resets Aug 13

Since the 5-hour "Current session" window had clearly rolled over to a fresh window this morning, and the only activity inside that fresh window was two plain-text replies, I expected usage in that window to be close to 0%, not 17%.

What Should Happen?

What I think is going on (unconfirmed)

The lifetime /usage stats for this conversation show it has accumulated ~197.4M cache-read tokens over its life (it's a very long, multiply-compacted session). My guess — not confirmed — is that every turn in a conversation this size requires replaying/re-reading a large amount of accumulated context even when nothing new happens, and that this cache-read replay counts (at least partially) against the rolling 5-hour session limit. If that's right, a conversation's length/history size silently taxes the current usage window independent of how much new work is actually requested in that window, which is surprising and not something /usage makes clear.

Error Messages/Logs

Steps to Reproduce

Reference data (from /usage, Claude Code CLI)

Session
Total cost:            $86.94
Total duration (API):  1h 31m 17s
Total duration (wall): 1d 22h 35m
Total code changes:    2538 lines added, 312 lines removed
Usage by model:
    claude-opus-4-8:   9.0k input, 461 output, 50.4k cache read, 29.9k cache write ($0.3802)
    claude-haiku-4-5:  2.0k input, 43 output, 0 cache read, 0 cache write ($0.0022)
    claude-sonnet-5:   86.5k input, 448.0k output, 197.4m cache read, 3.4m cache write ($86.55)

Current session: 17% used, resets 1:29pm (Europe/Madrid)
Current week (all models): 19% used, resets Aug 13 at 8:59am (Europe/Madrid)

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Platform: Claude Code CLI, macOS (Darwin 25.5.0).

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Warp

Additional Information

• Confirm/clarify whether cache-read tokens from replaying long conversation history count against the 5-hour "Current session" limit, and if so, by how much relative to fresh input tokens.
• If that is expected behavior, surface it in /usage — e.g., break down the current window's usage by "new work" vs "context replay," so long sessions don't look like they're burning budget for no reason.
• Consider recommending /compact or /clear more proactively (banner/warning) once a session's cache-read overhead crosses some threshold, since right now the only signal is a confusingly high percentage with no explanation.