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

Status Closed — not planned

Reported on v2.1.32

Maintainer reply None cached

Activity 5 comments · opened Feb 7, 2026 · closed Mar 25, 2026

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

Start a long-running session (e.g., using subagents/teams) in one 5-hour window
Let the session go idle but don't close it
Resume activity after the window boundary rolls over
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

When a session spans two 5-hour windows, which window gets charged for API calls made after the boundary?
Are subagent API calls counted as independent sessions for rate limiting, or grouped with their parent?
Are cache_read_input_tokens counted at the same weight as input_tokens and output_tokens for the 5-hour rate limit?
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

View original on GitHub ↗

5 Comments

github-actions[bot] · 8 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

tradesdontlie · 7 months ago

https://www.reddit.com/r/ClaudeCode/s/3c7p314dr0

github-actions[bot] · 6 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

evolv-to · 6 months ago

This issue was closed for inactivity, but it's very much still relevant. I've found concrete evidence of the underlying mechanism that may explain the inflated usage at window boundaries.

TL;DR: Claude Code's Bun processes maintain persistent HTTPS connections and actively reconnect to Anthropic's API servers during macOS DarkWake cycles (brief 2-45 second kernel-level maintenance wakes during clamshell sleep). These reconnections appear to anchor the 5-hour rolling window -- meaning the window starts ticking from a phantom server-side touch, not from any user action.

Evidence

I had 9 Claude Code sessions open across different projects. macOS unified log shows all 9 processes making HTTPS calls to port 443 during every DarkWake cycle overnight:

| DarkWake Time (IST) | Claude Code PIDs Active | Notes |
|---|---|---|
| 05:16:02 | All 9 | Simultaneous HTTPS calls |
| 05:34:00 | All 9 | Different hostnames -- active TLS reconnections to new CDN nodes |
| 05:42:29 | All 9 | Simultaneous HTTPS calls |

My /usage showed a reset time of 10:29 AM. The DarkWake at 05:34 + 5 hours = 10:34 -- within 5 minutes of the observed reset. Zero entries in history.jsonl during the sleep window. The laptop was in clamshell mode -- display off, no user present.

This is likely the same root cause as what you describe: sessions spanning window boundaries get their accumulated cache context charged to the new window because the window anchor is set by a background reconnection, not by user activity.

Full writeup with pmset logs, unified log evidence, and timeline: #37752

I'd suggest reopening this issue or at minimum cross-linking, since the evidence in #37752 provides the mechanism that was missing from the original report here.