Sessions spanning 5-hour rate-limit windows cause inflated usage attribution at window start

Bug Description

When a Claude Code session is started in one 5-hour rate-limit window and continues (or resumes after idle) into the next window, the accumulated cache context from the old session appears to be charged against the new window — causing the usage meter to show ~60% consumed instantly with no new meaningful user interaction.

Environment

• Claude Code Version: 2.1.32
• OS: macOS Darwin 23.6.0
• Model: claude-opus-4-6 (also claude-haiku-4-5, claude-sonnet-4-5)
• Plan: Max

Steps to Reproduce

1. Start a long-running session (e.g., using subagents/teams) in one 5-hour window
2. Let the session go idle but don't close it
3. Resume activity after the window boundary rolls over
4. Observe the usage meter immediately showing high consumption despite minimal new input

Observed Behavior

After a window rollover on Feb 7 2026 at ~18:00 UTC, the usage meter showed ~60% consumed within the first 1-2 messages. Local log analysis confirmed:

• ~70M tokens consumed in under 2 hours, 99%+ of which were cache tokens (not user input/output)
• Two sessions spanned the window boundary — started Feb 6 21:20 UTC, went idle 21 hours, resumed Feb 7 18:00 UTC. Their resumed activity (15M tokens) was counted in the new window.
• 17 subagents spawned in 15 minutes collectively consumed 24M tokens, each independently creating 25-46K token caches on initialization
• Actual user input + model output totaled only ~20K tokens across all sessions

Key Session Evidence

| Session ID | Started | Resumed | Gap | Feb 7 Tokens |
|-----------|---------|---------|-----|-------------|
| 6dc56301 | Feb 6 21:20 UTC | Feb 7 18:00 UTC | 21 hours | 10,900,885 |
| b33a51ef | Feb 6 21:21 UTC | Feb 7 18:00 UTC | 21 hours | 4,065,234 |

Token Composition (session 6dc56301)

| Type | Count | % of Total |
|------|-------|-----------|
| Input tokens | 232 | 0.001% |
| Output tokens | 3,282 | 0.014% |
| Cache read | 22,333,767 | 92.6% |
| Cache create | 1,782,709 | 7.4% |

By end of session, each single API call consumed 192K tokens in cache_read for a 1-token response.

Expected Behavior

• Sessions that span window boundaries should either: (a) have their continued usage pro-rated or attributed to the original window, or (b) clearly surface to the user that a window transition occurred so they can start fresh
• Cache tokens (especially cache_read, which is replaying existing context) should be weighted differently than new input/output for rate limiting
• Subagent initialization cache costs should be more visible to users

Questions for the Team

1. When a session spans two 5-hour windows, which window gets charged for API calls made after the boundary?
2. Are subagent API calls counted as independent sessions for rate limiting, or grouped with their parent?
3. Are cache_read_input_tokens counted at the same weight as input_tokens and output_tokens for the 5-hour rate limit?
4. Is there any client-side mechanism to detect/display window transitions?

Additional Context

• Full audit report and raw JSONL session logs available on request
• The issue is reproducible any time a heavy session (especially with subagents) spans a window boundary
• Independently filing with Anthropic support for server-side usage log verification

🤖 Generated with Claude Code