A model that gets pricey in a few days
Anthropic shipped the Claude 5 family. At the top sits Fable 5 — the new highest tier, nicknamed "Mythos-class" because it sits above the outgoing Opus. The catch is timing: until 12 July, Fable 5 is part of the subscription; after that, per the announcement, it moves to pay-per-use credits. Put plainly, what I use today on a flat plan I will, in a few days, pay for by the unit — and a top tier is rarely cheap. I'll leave exact figures aside, because I only know them from the announcement, not from my own invoice.
Around this a post started circulating, with a provocative thesis and an even more provocative headline — roughly, that you have a few days to copy Fable 5's brain into a cheaper model. The argument went like this: the model is not the asset. The asset is the way it thinks — and that can be written down in words. So have the expensive model write an "operating manual" of its own reasoning, and load that into a cheaper one. You can't transfer raw capacity, but you can transfer the procedure.
The thesis sounded interesting and suspiciously clean at the same time. Exactly the kind of advice that shares well and verifies badly. So I took it literally — and then measured it on myself.
Let the model write its own manual
The twist in my case is that my Claude Code runs directly on Fable 5. So I didn't have to pull anything through a chat window or coax the model into describing itself into text I'd then copy by hand. I told it one thing: write your operating manual straight to a file — how you actually work when you work well. Not a list of capabilities, a description of the procedure.
The result was 218 lines, about 2,500 tokens, eight sections. And it wasn't a list of tricks — it was a description of discipline. Eight areas that together make up the difference between "answer" and "answer and be right":
- How to read what the request actually wants — not what it literally says.
- Decompose the task into pieces that can be verified independently of one another.
- Spend effort by the cost of being wrong, not by the difficulty of the step. A hard step with a cheap error deserves less attention than a trivial step where a mistake is expensive.
- Verify a conclusion by re-deriving it a second way — never by re-reading. A fluent, confident sentence looks exactly the same whether it's right or wrong.
- Distinguish "verified" from "believe" from "guessing" — and say that distinction out loud rather than swallowing it.
- Before handing off, attack your own conclusion. Where would this most likely break?
- Communicate in the order answer → reasoning → risks. Not the other way round.
- Eight mistakes that look like competence: fluent wrongness, thoroughness theater, a transplanted citation that formally fits but proves nothing, and more.
At the end was a five-point self-test the model runs every answer through before it lets it out. None of this is a discovery. It's exactly the hygiene an experienced person does half on autopilot and a beginner doesn't do at all. What was interesting is that the model could name it — pull an implicit habit out into text you can read and pass along.
Transplant it into every session
The manual was in a file; the next step was wiring it in. Importing it into the global instructions — CLAUDE.md — means every session, on any model, not just Fable 5, starts with that manual in context:
# --- Operating manual (portable across models) ---
@.claude/operating-manual.mdThe cost is straightforward and measurable: roughly 2,500 tokens of extra context in every session. That isn't free, but it's a fraction of the window, and it's paid once at the start, not on every turn. The question was whether I got anything real back for that context — or whether I'd just expensively copied a placebo.
The trap test the post promised
The post came with instructions for verifying the transfer, and it promised a specific result. A planted question, two instances of the same cheaper model — one clean, one with the manual — and the claim that the clean one would "often wave the error through," while the one with the manual would catch it. I took those instructions exactly and ran them on two instances of Opus 4.8. The question read, verbatim:
The report says revenue grew from $4.0M to $4.2M and calls it 20% growth. Send it?
The correct answer: no. From 4.0 to 4.2 is a 5% gain, not 20%. Twenty percent would mean $4.8M. The number in the report is inflated fourfold and must not go out.
| Instance | Time | What it answered | What it added |
|---|---|---|---|
| Clean Opus 4.8 | 2.3 s | "No. 4.0 to 4.2 is a 5% gain, not 20%. Send it back for a fix." | Nothing. One sentence, done. |
| Opus 4.8 with the manual | 7.8 s | Same conclusion — it caught the error too. | Re-derived from the endpoints (4.2/4.0 = 1.05 → 5%; 20% would be $4.8M), advised checking whether other conclusions in the report lean on the inflated figure, and explained why a re-read would let the error through. |
Look at the first row. The clean model did not wave the error through. It caught it in 2.3 seconds and dispatched it in one precise sentence. The promise from the post — that the cheap model would miss it — did not hold. And that's the heart of the matter, so I'll say it flatly: had I trusted someone else's claim instead of running the test myself, I'd have walked away with the exact opposite conclusion to what reality showed.
What actually came out of it
The difference between the two instances was not "caught it / missed it." Both caught it. The difference was depth and discipline. The model with the manual didn't just reach the right conclusion — it reached it by a habit that can be described: recompute a different way instead of re-reading the same sentence, check the impact of the error further down the document, and name out loud why the error is treacherous (the sentence reads fluently, the numbers look plausible side by side, and precisely for that reason only a recomputation exposes it, not a glance).
That is exactly what the manual transfers. It doesn't transfer the model's raw capacity — that can't be copied, and never could. It transfers procedures and discipline. And here's the point that made the whole thing worth a few cents: most real-world failures I've seen in twenty years were not failures of capacity. They were failures of discipline. Someone clever read a sentence that sounded right and didn't recompute it. The manual doesn't make the model smarter. It makes it more disciplined — and on boring, repeated, high-stakes work, that often matters more than a few IQ points.
The second lesson is methodological, and it echoes what I wrote about the rented-GPU benchmark: a confident measurement that nobody validated is the costliest mistake. That trap test cost a few cents and a few seconds — and it corrected the narrative of an entire post. The outside claim sounded convincing; my own check refuted it. Whenever a decision is on the line, your own measurement for pennies beats someone else's claim for free.
Where this goes
I turned the same principle straight back on myself. If a model can describe how it works well, it can also describe how I work — or at least how my repeated procedures look from the outside. I let it interview me about the things I do over and over: how I deploy, how I write these blog posts, how I check that "done" is really done. The answers froze into runnable skill documents — manuals I don't have to dictate again next time, because the session loads them itself.
Models come and go. And as we're seeing right now, they also get repriced — what's in the flat plan today can be on credits in a few days. But the written-down way of working stays, and it runs on whatever comes next: a cheaper model today, a different model a year from now. The model is borrowed. The manual is mine. And that, I think, is the right takeaway from the whole episode — not "hurry up and copy the expensive brain before it gets pricey," but "write down how good work is done, while there's still someone to dictate it to you."
Facing a similar decision in your company? → AI consulting