[Bug] Opus 5.5 Usage Limits Exhausted Within 1-2 Days

Your local transcripts can show where the week went, even though they don't record the usage percentage. Every assistant entry in ~/.claude/projects/*/*.jsonl has a usage block: uncached input, cache reads, cache writes (5-minute vs 1-hour) and output. The usual culprits for "30–50% a day without changing anything" show up clearly in those numbers:

• Cache rewritten after a pause. If you come back to a long session after the cache has expired (5 minutes, or 1 hour for the 1-hour cache), the next message rewrites the whole history as cache writes. Writes cost far more than reads. Several returns a day to a 300k-token session add up quickly.
• A few huge tool results. One big file read or one test log stays in context and is re-read on every later turn.
• Subagents. Each one carries its own context. An "efficiency improvement" session that fans out to agents can easily cost more than the work it reviews.

I wrote a free local script that totals these per day and per session (disclosure: it's mine): npx github:lowkey-studio/quotatrace --only claude --since 3d. It reports cache rebuilt after a pause, the most re-read tool results, subagent share and the heaviest sessions, with counts only, no prompts or paths. npx github:lowkey-studio/quotatrace meter install additionally starts logging the 5-hour and weekly percentages from the status line, so next week you can see quota points per million tokens and spot any jump that your token use doesn't explain. https://github.com/lowkey-studio/quotatrace

Before assuming the limits shrank — check whether your own session logs show amplification. From auditing agent usage across 110 tools, the common quiet multipliers are retry chains (one logical operation attempted N times, each attempt re-sending its context) and duplicate records after crashes/resumes. A heavy agentic day with a flaky test suite can legitimately multiply visible "usage" several-fold without any single request being wrong.

Quick local check: pip install agentmeasure → agentmeasure check scans your Claude Code session files for duplicate records, retry amplification and unresolved retry chains — local only, no upload, no account. If the numbers come back clean, that's strong evidence for a limits-side issue worth escalating with support; if they show a 3-4x retry multiplier, you'll know where the budget went.

Adding data points that suggest the 5-hour session meter got much stricter around Oct 13, while the weekly meter didn't change. Plan: [PLAN], all Opus 5.5, speed: standard, 1h prompt cache, no subagents, no fast mode. Timezone ET.

Method: summed usage from every unique assistant message in ~/.claude/projects/**/*.jsonl and compared against the cached five_hour / seven_day utilization in ~/.claude.json. "Weighted" = cache_read×0.1 + cache_write×1.25 + output×5 + input (rough API-price ratios, only used to compare like with like).

1. 5-hour meter today (measured):

| Window (Oct 14) | Calls | Cache read | Cache write | Output | 5h used |
|---|---|---|---|---|---|
| 10:10–11:21 | 280 | 34.8M | 0.96M | 186k | 0% → 38% |
| 16:10–16:37 | 98 | 19.4M | 0.34M | 89k | 0% → 13% |

That's roughly 150k–215k weighted tokens per 1% of the session.

2. Earlier 5-hour windows that never hit the limit:

| Window | Weighted | Would be at today's rate |
|---|---|---|
| Sat Oct 10, 16:00–21:00 | 26.9M | ~125% |
| Sun Oct 11, 18:00–23:00 | 23.7M | ~110% |
| Mon Oct 12, 10:00–15:00 | 22.6M | ~150% |

Daily totals for the week: Sat (from 4pm) 40.8M, Sun 51.0M, Mon 46.7M, Tue 21.1M, Wed 16.6M. My usage roughly halved, yet Tue/Wed are the first days the 5h limit felt tight.

3. Weekly meter looks unchanged: 45% → 48% between 11:21 and 16:34 today for ~12M weighted, i.e. ~4M per 1%. The week-long average is ~3.7M per 1%, so they're consistent. Only the session meter's conversion seems to have shrunk, roughly by half or more.

Other notes:

• Client went 2.1.295 (Sat–Mon) → 2.1.296 (Tue) → 2.1.299 (Wed). The timing lines up with the change, though I don't see anything usage-related in the changelog.
• I'm not on a peak-hour reduction as far as I know (removed for Pro/Max per the May 6 announcement). The 16:10 window is off-peak anyway.
• Cache writes are all ephemeral_1h, so this isn't the 1h → 5m cache regression some people mention.

Could someone confirm whether the 5-hour session allowance changed around Oct 13?

@leolim031, that's a clean method. The weak point is the meter side: cachedUsageUtilization in ~/.claude.json only holds the latest fetched value (with fetchedAtMs), so before/after windows depend on catching it at the right moments.

Thanks to your pointer I added a record mode to a free local tool I maintain (disclosure: mine). It polls that cached snapshot every 60 s and appends each new reading (5-hour and weekly utilization, resets_at, fetch time) to a local file. It changes no settings and makes no network requests:

npx github:lowkey-studio/quotatrace record

Leave it running, and npx github:lowkey-studio/quotatrace --only claude --since 7d then joins those readings with the transcript calls by timestamp. You get percent per 1M tokens for every 5-hour and weekly window, with raw tokens and "billable" tokens (uncached input + cache writes + output) side by side. It also lists the steps that are out of line with the calls behind them. That would turn "5h got ~2× stricter around Oct 13" into a per-window series anyone can reproduce. https://github.com/lowkey-studio/quotatrace