Rohit Ghumare · September 2, 2026 · 9 min read

Fable 5.1 Burned the Meter in Twenty Minutes

Anthropic shipped Claude Fable 5.1 on September 1 with one number on the poster: cache reads cost 75% less, so typical work runs around 25% cheaper and long agentic loops up to around 45% cheaper. By the next morning the timeline was full of Max 20x subscribers who had lost a five-hour session in about twenty minutes. Both things are true at once, and the reason is not a glitch you can wait out. The cut was to an API list price. The wall people hit is a plan meter, and the plan meter was never told about the cut.

What Wednesday looked like

By September 2 the reports had a shape. MLStreetTalk wrote that Fable 5.1 was "mind-blowingly good" and that the Max 20x limits were "a joke": the five-hour limit gone in about 20 minutes, and the weekly limit worth roughly two five-hour limits, so a week of tokens could go in an hour of heavy use. AbdoKerdawy reported that the first five-hour session after the launch reset lasted under an hour, the next one 1.5 to 2 hours, and that 77% of the Fable weekly allowance was spent after about three hours of work. hours_for posted the most useful number of the day: 18 minutes and 90,000 tokens in the main context, and the five-hour meter already read 10%. Two years of Claude Code on the latest model at high effort, and they had "never seen a model run this fast through its limits".

The loudest report came from doodlestein, who said they had blown through the five-hour limits on all 28 of their Max 20x accounts in one day doing audits of their projects, "first time ever", and guessed at a caching bug in the new Claude Code. PaulFidika replied that across a dozen Max plans, Fable 5.1 hit the five-hour wall while "barely doing anything", four subagents running. argofowl, on two Max 20x subscriptions, could not do deep work with Fable even with the current 50% boost, and pointed at the other shoe: on September 14 the boost ends and weekly limits shrink by another 17%.

Every number above is a user's account of their own meter, not a measurement of Anthropic's system. Keep that in mind, because the reports agree on the shape and disagree on the size, which is what you would expect from a meter nobody can read directly.

Two meters, in one paragraph

The mechanics get their own essay: Claude Has Two Meters. The 20x Is Only on One. The short version: every Claude plan has a rolling five-hour window, paid plans add a weekly cap on top, and the "5x" and "20x" in the Max names are defined on the five-hour window only. Claude Code draws from the same pool as the chat app. Fable specifically is capped at 50% of the weekly limit on both Max tiers, per the pricing page. How much any of that buys "depends on the length and complexity of your conversations, the model you choose, and the features you use", in Anthropic's own words, "so there's no fixed message count". This essay is about what happened when a new model met those two meters on launch day.

The meter is not the bill

Read the launch post again with the meters in mind. The prices that changed are API prices: $10 per million input tokens and $50 per million output tokens, unchanged from Fable 5, and cache reads down from $1.00 to $0.25 per million. The Claude Code changelog for 2.1.257, the release that made Fable 5.1 the default Fable model on September 1, says the same thing in one line: "1M context, 10/10/10/50 per Mtok with $0.25/Mtok cache reads". Every claim of "cheaper" in the post is a claim about that price list. "For typical workloads, costs are reduced by around 25% relative to Fable 5", and "for complex coding and highly agentic tasks, the savings could be up to around 45%". Those are dollar sentences.

A subscription never sees dollars. When you sign into Claude Code with a Max plan, the support docs describe a shared pool with a rolling reset, and every turn sends three things to the model: the full conversation history, the project context (CLAUDE.md and the files read), and the new prompt. The plan meter charges for that traffic by some weighting of tokens, model, and effort that Anthropic does not publish. The Fable 5.1 post does not mention the plan meter at all. Nothing in it says the weights changed, and nothing in it says a cached token now costs the meter a quarter of what it did on Monday.

So the same prompt is priced in three currencies, and the launch touched one of them.

That is the whole explanation for the paradox. A 400,000-token context that is 95% cached became a lot cheaper to send through the API on Tuesday. On the plan meter it costs whatever it cost on Monday, because the meter counts the traffic, not the invoice.

Where a five-hour meter goes in twenty minutes

If the weights did not change, something about the traffic did. Four candidates, all of them ordinary.

The history you re-send. Anthropic's own guidance names conversation length among the biggest consumers, and the Claude Code docs call history the fastest-growing one, which is why /compact and /clear exist. Fable 5.1 defaults to a 1M-token context in Claude Code. A bigger window is an invitation to a longer session, which means a longer history per turn, which means more meter per turn.

Effort. Launch coverage reported that Fable 5.1 matches or beats Fable 5 at low and medium effort and pulls ahead at the higher tiers, so the tier people reach for is the expensive one. The 2.1.257 changelog changed --effort to "lift a new model's default-effort hold for that session only", and added an s option to /effort so you can set effort for the current session. Higher effort is more thinking tokens per turn. The meter charges for thinking.

Subagents. Every subagent is another loop sending its own history. PaulFidika's report names four. The Hacker News anecdote the two-meters essay quotes, five research agents spinning up 26 subagents and finishing a weekly allowance in twenty minutes, is the same mechanism at a larger fan-out. 2.1.257 added CLAUDE_CODE_SUBAGENT_MODEL_FORCE, which pins every subagent to one model regardless of what the agent definition asked for. That is a meter knob dressed as a model knob.

Cache misses. A prompt cache hit is cheap on the API and, presumably, cheap on the meter. A miss re-reads the whole prefix. The changelog around the launch is a list of ways a session can miss the cache without you doing anything: 2.1.257 fixed Remote Control re-sending the Bash tool definition and causing a miss, fixed sessions with an advisor model missing the cache on background requests, fixed screenshot-heavy sessions missing the cache on every turn once images passed a size cap, and fixed blocking Stop hooks causing a miss on the next turn. 2.1.259, on September 2, fixed the prompt cache being invalidated when the OAuth token refreshed in sessions with telemetry disabled. Any one of those turns a warm session cold.

Run the dial with the defaults and you get a session that dies in half an hour. Add four subagents and it dies in nine minutes, and then you wait the rest of the five-hour window for the meter to roll. That asymmetry is what makes launch day feel worse than the arithmetic: the wall is not a slowdown, it is a stop, and the stop lasts hours.

The caching hypothesis

doodlestein's guess deserves its own paragraph because it is the only explanation on the table that would make this a bug rather than a price. The guess is that the new Claude Code build was missing the prompt cache and re-billing the prefix on every turn. It is unverified. Anthropic has not said anything about it, and no one posted the line that would settle it.

That line exists now. Since 2.1.251 on August 28, /cost prints a per-session prompt-cache line: hit ratio, misses, tokens re-cached, and whether the session is warm or cold. If your session is burning and the hit ratio is high, the meter is doing what it does and the fix is in your traffic. If the hit ratio is low on a long session that has not changed shape, you are re-reading your context every turn, and the question becomes which of the fixes above you were waiting for. At API prices a miss on a 400,000-token prefix costs $4.00 where a hit costs $0.10. On the plan meter the ratio is unpublished, but it is not one.

The counter-reports

Not everyone hit the wall. JaanusBuilds said their 20x plan gave them roughly 7 billion tokens per seven days on mixed Opus 5 and Fable 5 use and called the limits "pretty solid", next to about 1.3 billion tokens per 30 days of Grok 4.6 on a Cursor plan. xrpl_adam called hitting limits in under 30 minutes on a $200 plan "an IQ test for using AI" and blamed spawning dozens of agents at random. sciguy, who runs eight OpenAI 20x plans and four Claude Max 20x plans, said Fable 5.1 is still substantially better than GPT-5.6 and that "a Max plan dies in minutes". On September 3 kangketikk posted the mirror image from the other vendor: Codex hitting its own five-hour limit before finishing a single issue on a repo where Claude Code finished more.

Read together, the counter-reports are not a rebuttal. They are the same meter under different traffic. A user who runs one loop at medium effort on a 200,000-token context and a user who runs five loops at xhigh on a million-token context are not on the same plan in any sense that matters, even when the checkout page says they are.

One more case is worth separating out. On August 30 Anthropic warned that infostealer malware on users' own machines was lifting Claude login sessions and spending the victims' usage: "If your usage limits looked like they refilled and then drained while you weren't using Claude, this was likely the cause." A meter that drains while you sleep is not a Fable 5.1 story. Check the sessions list before you blame the model.

The knobs that exist today

• /usage shows the five-hour and weekly percentages and when each resets; status line scripts get a rate_limits field with used_percentage and resets_at for both windows.
• /cost shows the prompt-cache line since 2.1.251: hit ratio, misses, tokens re-cached, warm or cold.
• /effort with s sets effort for this session only (2.1.257), the same way /model does.
• CLAUDE_CODE_SUBAGENT_MODEL_FORCE pins every subagent to one model, ignoring per-spawn and agent-definition overrides (2.1.257).
• Auto-continue at the limit reset has been on by default since 2.1.234 on August 18; turn it off in /config if you would rather be there when the meter rolls.
• The desktop app's compact indicator changed meaning in late August to track plan usage instead of the context window, which is why some people ran /compact at a red circle and watched nothing change (issue #91075).
• Some users reported being offered a once-a-week reset of the five-hour meter when they hit it (MaaSonder, September 3); it resets the session window, not the week. walidbelr reported that upgrading from Max 5x to 20x reset their limits too.
• On September 14 the temporary 50% weekly boost ends and a permanent 25% raise begins, which Anthropic itself described as "a 17% reduction in weekly limits on Claude Code" compared to today, per BleepingComputer. Theo quoted the same thread saying the separate weekly limit for Fable goes away on that date, so the 50% Fable cap would merge into the one weekly meter; treat that as reported until the support page changes.
• On paid plans you can turn on usage credits and keep working at standard API rates when the meter is out, per the pricing FAQ. That is the one place the 75% cache-read cut reaches a subscriber.

What this changes

If you are on a subscription, stop reading launch posts for prices. Read them for traffic. A model that thinks more per turn, defaults to a bigger window, and rewards fan-out is a model that spends your meter faster no matter what it does to the invoice, and the invoice is the only thing the launch post priced. Watch /cost for the cache line, set effort per session, pin your subagents, and decide before a long run whether you would rather finish it on API credits. The meter did not change on September 1. The model did.