Pro Max 5x Quota Exhausted in 1.5 Hours Despite Moderate Usage

You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert

I have searched existing issues and this hasn't been reported yet

This is a single bug report (please file separate reports for different bugs)

I am using the latest version of Claude Code

What's Wrong?

Pro Max 5x Quota Exhausted in 1.5 Hours Despite Moderate Usage

Summary

On a Pro Max 5x (Opus) plan, quota resets at a fixed interval. After reset, with moderate usage (mostly Q&A, light development), quota was exhausted within 1.5 hours. Prior to reset, 5 hours of heavy development (multi-file implementation, graphify pipeline, multi-agent spawns) consumed the previous quota window — but that was expected given the workload. The post-reset exhaustion was not.

Investigation reveals the likely root cause: cache_read tokens appear to count at full rate against the rate limit, negating the cost benefit of prompt caching for quota purposes.

Environment

Plan: Pro Max 5x

Model: claude-opus-4-6 (1M context)

Platform: Claude Code CLI on WSL2

Session: Single continued session with 2 auto-compacts

Data Collection Method

All data extracted from ~/.claude/projects///.jsonl session files, specifically the usage object on each API response:

This should NOT exhaust a Pro Max 5x quota. For comparison, Window 1 consumed 24.4M effective tokens/ho ur during heavy development and used the previous quota window — but that was 2.8x more intense.

If cache_read counts at full rate (suspected actual behavior):

Each API call sends the full context as input. With a 1M context window, calls near the compact threshold send ~960k tokens each. Even with prompt caching, if cache_read counts at full rate against quota, a single call costs ~960k quota tokens.

Specific Issues

1. Cache read token accounting against rate limits

Expected: cache_read tokens should count at reduced rate (1/10) against rate limits, matching the reduced cost.

Observed: Quota exhaustion rate is consistent with cache_read counting at full rate.

Impact: On a 1M context window, each API call sends ~100-960k tokens. With 200+ calls per hour (normal for tool-heavy Claude Code usage), quota depletes in minutes regardless of caching.

2. Background sessions consume shared quota

Sessions left open in other terminals continue making API calls (compacts, retros, hook processing) even when the user is not actively interacting. These consume from the same quota pool.

In this case, token-analysis (296 calls) and career-ops (173 calls) were running without active user interaction but still consuming significant quota.

3. Auto-compact creates expensive spikes

Each auto-compact event results in one API call with the full pre-compact context (~966k tokens) as cache_creation, followed by a fresh start. This means the most expensive single call happens automatically, without user action.

4. 1M context window amplifies the problem

Larger context window = more tokens per call = faster quota depletion. The 1M window is marketed as a feature but becomes counterproductive when cache_read tokens count at full rate against quota.