Claude Code's usage limit bug: what actually happened

Yes - Claude Code had a real, confirmed usage-limit bug, and Anthropic published a root-caused postmortem naming the exact cause. But "the bug" currently covers at least three different things: one resolved incident with a fix and a version number attached, two separate GitHub threads still open months later describing a similar symptom, and ordinary setup waste that looks identical from inside a lockout message. Only the first one is confirmed fixed - the other two are still open questions, and mixing them up is why the same forum thread keeps getting linked for three unrelated problems.

What really happened to Claude Code's usage limits this spring

The most-cited GitHub report on this, issue #41930, was filed April 1 under the title "Critical: Widespread abnormal usage limit drain across all paid tiers." Forbes covered the story the same week the problem started, and devops.com followed with its own "Token Drain Crisis" piece - both are the news-coverage results that currently rank for this query, and both describe the symptom without the cause, because the cause hadn't been published yet.

What users could see from the outside: sessions that had run the same kind of work for months suddenly cost far more, sometimes exhausting a five-hour or weekly window in minutes instead of hours. Comments on #41930 include a Pro subscriber whose ccusage data showed a single session reading back 64.8 million cache tokens against 837 input tokens - a roughly 77,000x ratio - and a separate report of an overnight multi-agent run that burned roughly 20% of a monthly plan while producing zero forward progress. I pulled the issue directly from the GitHub API rather than trusting the title: it carries state_reason: completed, closed April 24 - Anthropic's own classification of "we fixed this," not a stale-bot timeout.

Anthropic's own postmortem, the short version

The actual root cause isn't visible from any of the forum threads - it's in the postmortem Anthropic published, and it's more specific than "the cache broke":

The primary cause was a caching bug introduced March 26: a clear_thinking_20251015 header, combined with a keep:1 setting, was supposed to clear old reasoning once when a session had been idle for over an hour. Instead it fired on every single turn for the rest of the session, which meant far more of each request had to be reprocessed as fresh, uncached input - the same mechanism the separate prompt-cache bug covers, but a different trigger. Two secondary changes compounded it during parts of the same window: a March 4 change that dropped the default reasoning effort from high to medium (reverted April 7), and an April 16 system-prompt instruction capping responses to 25 words between tool calls, which hurt output quality independent of billing (reverted April 20, v2.1.116). That level of mechanism-specific detail - the exact header, the exact setting, the exact dates - only exists in Anthropic's own writeup, not in any of the forum threads or news pieces that broke the story while it was still unfolding.

The GitHub threads still open right now

Two other reports use almost identical language to #41930 and get grouped with it in search, but neither has a completed state:

#16157 is the biggest bug thread in the repository by a wide margin - opened January 3 on v2.0.76, nearly three months before the confirmed incident even started, and still getting comments as recently as August 6. It reads less like one bug than a running channel for "my usage felt wrong today," which is exactly why it never resolves: there's no single root cause for a thread to close against. #38029, opened March 24, is narrower - abnormal consumption specifically tied to resuming a session - and its most recent comment, from July, is someone recommending a third-party tool that claims to cut token spend. Treat that the same way as any unaudited package pitched inside a bug thread: it sits between your terminal and Anthropic's API on the strength of a comment, not an audit, and neither open issue needs you to install anything to be worth reading.

Confirmed incident, ongoing complaint, or your own setup - how to tell

Before assuming you've found a new instance of either GitHub thread, place what you're seeing against what each one actually looks like:

| Signal | Confirmed incident (Mar 26 - Apr 23) | Still-open threads (#16157, #38029) | Your own setup | | --- | --- | --- | --- | | Version | Any build released Mar 26-Apr 10, before v2.1.101 | No clean version boundary - #16157 opened on v2.0.76 and is still active today | Any version | | Shape of the spike | Sudden and session-wide; the same workflow you always run costs far more overnight | Recurring, often tied to a specific pattern: session resume, or overnight multi-agent runs | Gradual - grows with context size, CLAUDE.md size, or subagent count | | What fixes it | Nothing to do - already patched in v2.1.101 and later | No fix yet; add a data point with real /usage numbers rather than a fresh duplicate | Trimming what you feed every turn - see why "usage limit reached" happens |

If you're on a current build and the spike is gradual rather than sudden, you're very likely in the third row, not the first two - that's a setup question, not a bug report. Walking it as a sequence instead of a table catches the two edge cases the table can't:

What to check before you file a new report

Two commands answer most of this without guessing:

$ npx @anthropic-ai/claude-code --version
2.1.222 (Claude Code)

That's this article's own check, run today. If yours reports anything at or after 2.1.101, the confirmed incident's fix is already in your build. Then open /usage inside a session and watch whether cost tracks the work you're actually doing - a sudden jump with no version change, no new MCP servers, and no larger CLAUDE.md than last week is the pattern worth a fresh, specific bug report (your version, your /usage output, and whether it's sudden or gradual), not a +1 on a two-year-old mega-thread that will get lost in triage.

When none of this is actually the problem

This whole incident and both open threads describe Anthropic's own consumer usage-limit metering - the 5-hour and weekly windows on Pro, Max, and Team. If you're running Claude Code through Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry, you're not metered against those windows at all; a cost spike there is a provider-side billing question, not this bug. And a calculator or estimate (including the one linked below) can only ever approximate what Anthropic's own /usage reports - treat the built-in command as the source of truth, not a third-party number.

FAQ

• Is the Claude Code usage limit bug fixed? One confirmed incident is: the March 26-April 23, 2026 caching regression was root-caused and fixed in v2.1.101, with limits reset for every subscriber on April 23. Two other GitHub threads describing fast usage drain, #16157 and #38029, are still open and don't have a confirmed fix.
• What actually caused the usage-limit bug? A caching header meant to clear old reasoning once per idle hour instead fired on every turn for the rest of a session, forcing far more of each request to be reprocessed as new, uncached input - detailed in Anthropic's own postmortem.
• How do I know if I'm hitting the old bug or a new one? Check your version first - claude --version at or past 2.1.101 means the confirmed incident's fix is already in your build. If usage still spikes suddenly with no setup change, that matches the pattern in the still-open threads, not the resolved one.
• Are the GitHub reports about this actually fixed? Only #41930 carries state_reason: completed - Anthropic's own classification of "fixed," confirmed by an engineer's comment linking the postmortem. #16157 and #38029 remain open with no equivalent closing comment.
• Should I install a tool that claims to fix Claude Code's usage-limit bug? No - one open thread has a comment pushing exactly that, and it's the same pattern worth being wary of anywhere: a third-party package sitting between your terminal and Anthropic's API on the strength of a comment, not an audit.

None of this replaces checking your own numbers - Claude Code's 5-hour limit, explained covers the mechanics once you know which problem you have, and the usage limit calculator turns a usage pattern into an estimated ceiling if you'd rather not wait for a lockout to find out - or run UsageCut's free local scan to see whether your own setup, not a bug, is what's burning the budget early.

Made by Neo

UsageCut by ClockedCode - not affiliated with Anthropic. The figures on this page are measured on real Claude Code sessions and labeled measured or estimated where it matters.