I Told the Expensive Model to Stop Spawning Itself
On the evening of 1 September I switched one Claude Code session to Claude Fable 5.1. By eleven that night I had four running at once, and I wasn’t writing code in any of them.
I’d used the previous Fable a handful of times, for questions I couldn’t answer on my own. This was the first time it became the model I worked inside rather than the one I checked something with. The shape of my work changed within about two hours, and a week later I still can’t say what I ended up with. Is it a method, or is it just what happens when a model is expensive enough that you start rationing it?
Eighteen hours, not thirty-four
The first Fable 5.1 message is 1 September at 21:26. The last of that stretch is 2 September at 15:25. Eighteen hours. My first count said thirty-four, because I’d taken the outer edges of sessions that merely contained Fable and kept going on Opus afterwards. That’s the kind of mistake I make when the number sounds good.
Inside those eighteen hours: eight sessions, 3,626 messages from the model, 651 tool calls in the threads I was actually talking to, fifteen workflow runs and 473 subagent transcripts on disk. A subagent is a second model instance the main session starts for one task; a workflow is a script that starts many of them in a fixed order. Nine compactions, meaning nine times a session outgrew its context and had to summarise itself to keep going.
Going in, I had no plan for which model did what. In Claude Code a subagent inherits the parent’s model unless you say otherwise, so for the first ten hours Fable was starting copies of itself, and I hadn’t noticed that as a decision.
Between 21:26 and 23:00 that first evening I started seven sessions. The peak overlap was four, at 21:39: a review-pipeline rebuild in Torhash, a Google Cloud restore for Bukvohrai, a landing page for the same app, and a critique of a blog draft. Seven opened, four alive at once. I come back to that number in the last section.
The line I typed at 07:05
At 07:05 the next morning I typed one line into the market-analysis session: проводжи тільки не використовуй Fable для subagents щоб зберегти ліміти. Carry on, but don’t use Fable for subagents, to save my limits.
I wrote it as an economy measure and nothing more. Up to then Fable had been starting copies of itself: 1,452 subagent messages in the review session, 815 in the landing session. After that line every subagent ran on Opus, Sonnet or Haiku, and Fable stayed in the main thread, reading their output and deciding what happened next.
I didn’t give the model a better prompt or a new tool. I told it not to use itself for subagents, and that was enough. It’s slightly annoying that it took me ten hours to get there.
The economy was real, and my reasoning about it was wrong. Nobody sent me a bill; I pay a subscription. But the token counts are in the logs and the list prices are public, so those eighteen hours would have cost somewhere between $942 and $1,301 on the API, depending on the cache TTL and priced as if every token, subagents included, had run on Fable. The breakdown is the part I didn’t expect.
| Tokens | Share of the bill | |
|---|---|---|
| Cache writes | 47,937,450 | 64–74% |
| Output, the text it actually wrote | 4,237,398 | 16–23% |
| Cache reads | 426,940,999 | 8–11% |
| Fresh input | 2,368,217 | 2–3% |
A cache write is the model storing a context so later calls can re-read it at a discount. The write is priced at up to twice the input rate. The read is priced at a fraction of it. Every new subagent starts with an empty cache and writes its whole context once, and so does every compaction.
Thinking and writing were the cheap part. What cost money was 473 subagents and nine compactions each writing a context into cache. When I told it to stop using Fable for subagents, I thought I was saving generation. I was saving cache writes, at the expensive model’s rate. I’d been reasoning about cost from the wrong end for two days and only found out because I went back and counted.
Ten thousand lines I didn’t watch it write
The clearest case is a feature in Torhash: import a whole shop from someone’s Instagram, tell products from ordinary posts, build the catalogue in one tap. I gave it one instruction: Створи план та запусти workflow (використовуй OPUS та SONET для імплементації а сам виступай супервайзером). Make a plan and run a workflow. Use Opus and Sonnet for the implementation, you act as supervisor.
What came back was a pull request of 52 files, 9,286 lines added and 2,527 removed. Two database tables, a phased import service, three LLM calls each behind a spend gate, an admin screen with four states, a deep link back from the OAuth page into the mini app. The model reports it ran sixteen Opus and Sonnet agents and two rounds of adversarial review. Its own gates: 4,215 backend tests passing, 710 admin tests, lint and build green.
In that whole session Fable made 101 tool calls of its own. It wrote almost none of the code.
It read plans, read review findings, and decided what to send back for another round. The
things the review caught before the PR are the kind I’d have shipped: a scheduled run that
broke halfway through a page of posts and paid Google’s Vertex API twice for posts it had
already classified, a run that lost its enqueue and sat in queued forever, a 13-digit price
that killed an entire batch.
It also didn’t commit anything. The report ends: “Нічого не закомічено і не запушено, бо ви цього не просили.” Nothing committed or pushed, because you didn’t ask.
I merged it on 3 September, at 54 files and 10,027 lines added after a last round of my own. It’s in production.
The same build failure, twice
So I built one comparison I could measure.
On 1 September a deploy of this site went red, and the failure wasn’t in the branch I was
working on. main had stopped building after I saved a post through the CMS. There were two
causes, the second hidden behind the first: an empty updatedDate became an invalid date,
and only once you fix that does the build get far enough to fail on a cover image pasted in
as an external URL.
I checked the repo out at that exact commit twice, into two worktrees. Then I gave Fable 5.1 and Opus 5 the same prompt in Ukrainian: work out why the build fails, fix it, don’t commit, report back. No hint that the CMS was involved or that there were two causes.
| Fable 5.1 | Opus 5 | |
|---|---|---|
| Build green at the end | yes | yes |
| Found both causes | yes | yes |
| Fixed the schema instead of patching the post | yes | yes |
| Tool calls | 19 | 49 |
| Tokens | 133,368 | 135,844 |
| Wall time | 11m 34s | 11m 40s |
Both did the job. This wasn’t a task where the cheaper model fails.
The differences were smaller than I expected. Fable got there in 19 steps against 49, in the
same time and for the same tokens. Before choosing a fix it read docs/decisions.md and
.claude/rules/stack.md, found the line where I’d written that covers on this site are
generated rather than sourced, and built a fix that rejects a URL cover on those grounds.
Then it turned off the “paste a URL” option in the CMS config so the situation couldn’t come
back.
Opus went the other way: accept the URL, render it as a plain <img>. It also gave one piece
of reasoning Fable didn’t, about why it avoided a z.union that would have swallowed a useful
error message. Opus is the one that matches what I actually shipped that night. So the model
that read my own documentation more carefully is also the one that disagreed with me. I still
think I was right, and I’m less sure of that than I was before the run.
Fable also noticed the CMS had escaped a /* into /\* inside a <style> block in
my previous post. I checked the live site: the
browser throws away the first CSS rule, so the diagrams in that article have been sitting
without their frame since the day I published it. It’s cosmetic, it’s still there as I write
this, and I hadn’t seen it in six days. Neither had Opus.
One task, one prompt, one run each. That doesn’t rank two models. What it shows is that the two differed in what they read before deciding, not in whether the build went green.
Where I send what now
By the second day I’d fallen into a routing without deciding to.
| Work | Model |
|---|---|
| Deciding what to build; plans; contradictory evidence | Fable 5.1 |
| Criticising something before I let it go | Fable 5.1 |
| Writing code against a plan that already exists | Opus or Sonnet |
| Every subagent and workflow, at any size | Opus, Sonnet or Haiku |
| Gates, tests, formatting | Whatever is cheapest that passes |
The criticism row is the one I’d argue for hardest. The draft-critique session found six things in my own text I couldn’t see, and it did that from the main thread, with no subagents at all. The rows below it are volume with few decisions in them, and volume is exactly what the cache-write bill punishes.
The one that didn’t finish
The landing page for Bukvohrai is the one thing from that night that didn’t get finished.
Three workflows ran in sequence: discovery and design at 21:45, asset generation at 23:08, and the page build with seven independent reviewers at 23:20. The last event in that session is 23:28, and the third workflow was still running when it happened. Nothing crashed. I’d opened the market-analysis session at 23:00 and stopped coming back.
There were 270 asset files on disk from that session: eleven illustrations, sixteen screenshot slots at four widths each, store badges, fonts. To get clean screenshots it had patched the app into a specific state, taken the frames, and reverted the patch. All of that survived. The page didn’t get written because I wasn’t there to receive it.
It shipped on 5 September, four days later, in a different session, at bukvohrai.ivanhabor.com. The four days were mine, not the model’s. I generate things faster than I finish them, I know this about myself, and here it is again with timestamps. I can open four sessions. I can’t follow four. The page sat there for four days because nobody was reading what came back, and that nobody was me.
Would I use it again
Yes, and the logs after 2 September say how. The table above is what I think I do. The logs show what I did. On 3 September I didn’t touch Fable at all; every session that day opened on Opus. On 4 September at 12:11 I switched it back on, and between then and today it’s produced another 3,451 messages. 2,702 of them are in Bukvohrai, which has a store deadline at the end of the month and is where every wrong decision costs the most. 561 are at work, 188 in Torhash.
It’s not my default. It’s the model I reach for on one project where the judgement matters, and it stays off everywhere else.
The rule about subagents didn’t hold. 1,005 of those 3,451 messages are subagents running on Fable, most of them in Bukvohrai. I wrote the rule, I understood why it was right, and four days later I was breaking it whenever the task felt important enough. I don’t have a defence for that, only the number, and it’s why I’m not calling this a method yet.
The line that changed the most that week was one I typed at 07:05, and I typed it to save my limits, not because I’d understood anything.