Skip to content
AI Primer
update

Fable 5 users report heavy Claude Code credit burn before July 7 cutoff

A Fable maintainer set the Claude subscription cutoff for 11:59:59pm PT on July 7 as users posted high Claude Code credit usage. One estimate claimed about $2,267 of usage across two $200 accounts in six days.

7 min read
Fable 5 users report heavy Claude Code credit burn before July 7 cutoff
Fable 5 users report heavy Claude Code credit burn before July 7 cutoff

TL;DR

  • Fable 5 subscription access has a precise cutoff: trq212's reply puts it at 11:59:59pm PT on July 7, and his availability thread says Anthropic aims to restore it when capacity allows.
  • The credit burn got visible fast: giffmana's Claude Code screenshot showed $73.50 spent against a $70 monthly limit, while Theo's rough tally estimated about $2,267 of usage across two $200 accounts in six days.
  • Expensive runs produced real work: Yacine's Box3D post claimed a native CUDA rewrite ran about 30x faster, and Simon Willison's writeup says Fable found five sqlite-utils release blockers for about $149.25.
  • Users converged on Fable as a planner, not a typer: the fable-advisor post routes implementation to GPT-5.5, and PerceptualPeak's harness used Fable as director, Opus as implementer, and Codex as reviewer.
  • The benchmark story has a price tag: Artificial Analysis says Claude Fable 5 with Opus 4.8 fallback led all eight capability indices, while costing over 100x DeepSeek V4 Pro on one Strategy & Ops comparison.

Fable's cutoff turned into a scavenger hunt for quota surfaces: steipete showed reset countdowns in CodexBar, the fable-advisor post packaged a cheaper delegation pattern, and a ClaudeAI cache analysis put numbers on an 8% total-spend waste pattern inside subagent-heavy Claude Code runs. Peter Gostev's effort table made the hidden knob visible: the same Manhattan prompt ranged from 73.2k tokens at low effort to 367.1k at max.

Subscription cutoff

Fable's subscription window got an exact ending time late in the run. trq212's cutoff reply set it at 11:59:59pm PT on 7/7; his earlier thread said Fable would come off subscription plans after July 7 while Anthropic tried to restore it "as soon as capacity allows."

The rollout note attached to that thread laid out the staged policy:

  • API and consumption-based Enterprise: fully available from launch.
  • Pro, Max, Team, and seat-based Enterprise: included at no extra cost for a limited window.
  • After the included window: subscription use requires usage credits.
  • Later: restore Fable as a standard subscription feature when sufficient capacity allows.

The last day read like a build sprint with a meter running. Kimmonismus called it the last day of Fable 5, and Daniel's countdown post told Claude subscribers to use it before it left.

Usage-credit burn

Claude Code exposed the meter directly. giffmana's screenshot showed /usage-credits with $73.50 spent, 100% used, a $70 monthly limit, and a "Buy more" path inside the terminal UI.

Theo posted two account screenshots: one account showed Fable at 99% weekly usage, and the second account showed 83%. Later, Theo's rough calculation put the effective usage at about $2,267 across two $200 accounts in six days.

Yacine's cost reports escalated from a single prompt over $130 to a $300-per-day estimate if he used Fable like Codex, then to a GPT-5.5 comparison after he said Fable had cost $200 in two hours.

Reddit saw the same quota shape. One ClaudeAI post said Fable used 11% of tokens for a concise summary versus Haiku at 60%, yet the author reached 96% of weekly Fable quota in about a day; another post asked whether upgrading from 5x to 20x would reset Fable usage before the pay-per-usage switch.

Peter Gostev's same-prompt run made effort-level burn concrete in his table:

  • Low: 73.2k tokens, 27 tool calls, 12m, 711 lines of code.
  • Medium: 190.3k tokens, 58 tool calls, 44m, 1,702 lines of code.
  • High: 296.3k tokens, 88 tool calls, 1h 15m 42s, 1,660 lines of code.
  • XHigh: 261.7k tokens, 165 tool calls, 1h 35m 30s, 2,291 lines of code.
  • Max: 367.1k tokens, 122 tool calls, 1h 50m 40s, 2,425 lines of code.

Real engineering output

High spend produced real artifacts. Yacine said Fable helped rewrite Box3D in native CUDA, about 30x faster on his GPU than CPU, at about $200 in the Box3D post.

The follow-up matters more than the headline number. Yacine said he transcribed a Dennis Gustafsson talk, had Fable build the tools, drove down time per frame, and corrected Fable by making it check profiling output.

Fable also left bugs. Yacine's GPT-5.5 follow-up said GPT-5.5 found and fixed bugs left behind by Fable, and his blunt post said Fable "lies A LOT."

Simon Willison's case was release engineering, not a stunt. Willison's writeup says sqlite-utils 4.0rc2 was mostly written by Claude Fable for about $149.25 and that Fable found five release blockers before a stable 4.0 release; his tweet described the same review as an estimated unsubsidized $149.25.

Doodlestein's FrankenSim run used three Fable Claude Code sessions on xhigh and reported one day of progress on a pure-Rust computational geometry and physics stack in the FrankenSim progress post. A later screenshot claimed the session reproduced Orszag's Re_c = 5772.22 benchmark with a cross-ISA deterministic stack.

Orchestrator pattern

Users converged on Fable as the expensive planner. Matthew Berman's split put it as Fable for planning and GPT-5.5 for execution; the fable-advisor post packaged the same idea as a Claude plugin with GPT-5.5 as an implementer sub-agent through Codex CLI.

The Fable Advisor repo describes the pattern as an architect lane on Fable, routine implementation lanes on cheaper models, and verification before completion.

PerceptualPeak's custom harness had four moving parts in the workflow post:

  1. Fable 5: director and strategist, zero implementation.
  2. Opus 4.7: primary implementation agent.
  3. Codex GPT-5.5: independent review and verification agent.
  4. Harness: Claude channels plus fakechat, stop hooks, and a resume prompt when context hits 700k.

Zeeg reported Fable's first clear value add in verifying agent instructions and tools against curated evals, while still calling price and latency unacceptable in a hands-on review. Matt Lam adjusted his workflow to use Fable as orchestrator with Pi and GPT-5.5 workers after OpenBench harness tests, according to his OpenBench thread.

Benchmark premium

Artificial Analysis put the cost argument next to domain benchmarks. Claude Fable 5 with Opus 4.8 fallback led all eight capability indices, while Claude Opus 4.8 ranked second on six of eight and GPT-5.5 xhigh ranked second on two, according to Artificial Analysis.

The same post surfaced the premium:

  • Open weights: GLM-5.2 max led five of six industry indices and scored 53 on Engineering, within 2 points of Claude Sonnet 5 max and GPT-5.5 xhigh at 55.
  • Strategy & Ops: Claude Fable 5 with fallback scored 12 points above DeepSeek V4 Pro max, at $3.48 per task versus $0.03, over 100x the cost.
  • Legal: Gemini 3.1 Pro Preview completed tasks in 0.8 minutes, about 7x faster than Claude Fable 5 with fallback at 5.4 minutes, while scoring within 11 points, 48 versus 59.
  • Budget tier: DeepSeek V4 Flash max completed tasks for under $0.04 across all six industry indices while scoring mid-pack.

The clean read is brutal: Fable topped the charts, but the efficient frontier had cheaper points all over it.

Subagent prompt cache

r/ClaudeAI

Claude Code is quietly overpaying ~14% on subagent prompt cache — and it's Anthropic's to fix, not a setting you can change

0 comments

Claude Code's burn also has a harness-level cache problem in at least one heavy-subagent workflow. farono's Reddit analysis parsed about two weeks of local transcripts, roughly 95 sessions, 1,800 subagents, and 6.8B input tokens.

The post's measured and modeled claims were specific:

  • Subagent prompt cost was about 14% too high.
  • Total spend was about 8% too high, because main sessions and output were not affected the same way.
  • A subagent cold start was about 37k tokens, but only about 950 tokens, roughly 3%, were the actual task.
  • The other 97% was mostly boilerplate: system prompt, tool definitions, and project rules.
  • Dynamic fields such as date, cwd, git branch, and reminders appeared early, which broke prefix-cache reuse for later static content.
  • Parent caches expired while waiting on child agents; the analysis said 96% of those were real cache deaths clustered just past the 5-minute line.

The counterintuitive result was the best part. Extending every subagent to a 1-hour cache modeled 8.6% worse, while the linked GitHub issue modeled two narrower fixes: a 1-hour TTL before child dispatch for about 6% savings, and a 1-hour TTL on the identical static prefix plus moving dynamic content after it for about 7.6% savings and roughly 88% cheaper cold starts.

Further reading

Discussion across the web

Where this story is being discussed, in original context.

On X· 5 threads
TL;DR5 posts
Subscription cutoff3 posts
Usage-credit burn7 posts
Real engineering output6 posts
Orchestrator pattern5 posts
·
Other sources· 1 post

sqlite-utils 4.0rc2, mostly written by Claude Fable (for about $149.25)

I wrote about the sqlite-utils 4.0rc1 release a couple of weeks ago. Since we only have Claude Fable on our Max subscriptions for a few more days, I decided to see if it could help me get to a 4.0 stable release that I felt truly comfortable about, since I try to keep to SemVer and like my incompatible major versions to be as rare as possible. I started with this prompt, in Claude Code for web on my iPhone: Final review before shipping a stable 4.0 release - very important to spot any last minute things that would be a breaking change if we fix them later Here's that initial report it created for me. There were some significant problems that I hadn't myself encountered yet - 5 that Fable categorized as "release blockers". Here's the worst of the bunch: 1. delete_where() never commits and poisons the connection (data loss) Table.delete_where() (sqlite_utils/db.py:2948) runs its DELETE via a bare self.db.execute() with no atomic() wrapper — compare Table.delete() at db.py:2944, which wraps correctly. The connection is left in_transaction=True, so every subsequent atomic() call takes the savepoint branch (db.py:430-440) and never commits either. Reproduced end-to-end: db = sqlite_utils.Database("dw.db") db["t"].insert_all([{"id": i} for i in range(3)], pk="id") db["t"].delete_where("id = ?", [0]) # conn.in_transaction is now True db["t"].insert({"id": 50}) db["u"].insert({"a": 1}) db.close() # Reopen: rows are [0, 1, 2] — the delete, row 50, AND table u are all gone. That's a re

Share on X