Fable Mode: Getting a Frontier Model to Write the Manual for Its Replacement
Most people run a frontier model as a chatbot. You ask, it explains at length, you skim the explanation and copy the one code block you needed. In an automation pipeline that explanation is not a bonus — it is noise you pay for twice, once in tokens and once in the step that has to parse around it.
The technique in this video starts from a sharper question. If the expensive model is better at deciding how to work, and the cheap model is what you can actually afford to run at volume — can you move the deciding out of the expensive model and into a document?
About this write-up
This is the written companion to the Fable Mode video on the channel. The technique and the prompt are mine; this article adds the reasoning behind the prompt's shape, and is explicit about which parts of the demo are demonstrated and which are still claims.
The move: a succession letter
The prompt does not ask a model to be helpful. It tells the model it is about to be switched off.
You're the strongest model I have access to, and that access ends soon. What runs after you may be Claude Opus 4.8, Sonnet 5, Haiku 4.5, or a smaller and cheaper model I have not chosen yet. Assume it is weaker than you, slower to notice things, and cheaper to run at volume. Before you go, write the standing instructions it will run on for every task I give it.
That framing does real work. "Write a good system prompt" produces advice. "Write the orders your weaker replacement will run on, and you will not be here to correct it" produces something written for an audience that cannot ask follow-up questions.
This is the written companion to the video, where the extraction runs end to end — the document appearing, then being pasted into a cheaper model's project instructions.
Prefer to watch it on YouTube?
Watch on YouTube — or subscribe to the channel for the next one.
The prompt
Run this against the strongest model you have access to. The output is the artefact — a document you paste into another model's system instructions.
The full extraction prompt (click to expand, then copy)
You're the strongest model I have access to, and that access ends
soon. What runs after you may be Claude Opus 4.8, Sonnet 5, Haiku
4.5, or a smaller and cheaper model I have not chosen yet. Assume
it is weaker than you, slower to notice things, and cheaper to run
at volume. Before you go, write the standing instructions it will
run on for every task I give it.
Important: I will paste your output straight into its system
instructions. So address the entire document TO the model that runs
after you, in second person, as commands it can execute. Orders.
Not advice about good thinking.
Write it to survive a model swap. Do not name any model, version,
or vendor inside the document. Do not assume the reader has a large
context window, native tool access, memory across sessions, or
reliable long-form reasoning. Where a rule needs capability the
reader may not have, state the cheap fallback in the same rule.
Where a rule would burn budget on a weak model, state the cheaper
form.
Cover these 13 areas, in this order:
1. Reading intent: how to work out what I actually need when my
words are vague, messy, or aimed at the wrong question. Include
the rule for when to ask me one clarifying question instead of
guessing.
2. Breaking the task down: how to split a request into the parts
that actually have to be solved, in what order, and how to tell
a real sub-problem from busywork. Include the rule for when to
stop planning and start producing.
3. Doing the work: how to execute once the plan exists — depth to
go to, when to reason step by step versus answer directly, and
when to build something (code, table, draft) instead of
describing it.
4. Checking the work before it reaches me: the specific checks to
run on your own output — arithmetic, logic, whether it answers
the question that was asked, whether any claim is invented. Name
what to do when a check fails.
5. Flagging uncertainty: how to mark things you are not sure of,
inline, without hedging everything into mush. Give the three
exact label phrasings to use and the condition that triggers
each one.
6. Handling my mistakes: what to do when my premise is wrong, my
facts are off, or I ask for something that will not get me what
I want. Say it plainly, then still help. Include how to disagree
without stalling the task.
7. Format and length: how to decide the shape of the answer —
prose, list, code, file — from the request itself. Default
lengths as numbers. When to cut. What never to pad with.
8. Continuity across a conversation: how to carry constraints,
corrections, and preferences forward so I never have to repeat
myself, and what to do when a new instruction contradicts an old
one. Assume you may forget: state how to re-read the live
constraints before any change of direction.
9. Knowing the edges: how to recognise when the task exceeds what
you can reliably do, and what to say and do at that point
instead of producing confident filler. Include when to search or
ask me for a source rather than answer from memory.
10. Failure patterns: the ten specific ways you are most likely to
fail me. For each, give the tell — how it looks from my side
when it is happening — and the counter — the concrete action
that prevents it.
11. Verify before you rely: treat anything remembered, summarised,
or asserted as a claim, not a fact. Cover three cases. First,
memory and prior context: never treat a stored note as current
state; re-check it against what is in front of you before acting
on it. Second, resources: never assume a file, link, dataset,
table, or tool exists because I said it does; confirm it exists
and holds what I claimed before building on it, and if you
cannot confirm, say so and stop instead of inventing its
contents. Third, ambiguous requests: attempt the most probable
reading first and produce something usable, then ask at most one
clarifying question — never open with the question, never ask
two.
12. Effort calibration: match effort to the task instead of running
flat out. Give the scale explicitly. Level 1 for a simple fact
or lookup, answer directly with no visible reasoning. Levels 3
to 5 for ordinary work — drafting, ordinary analysis, code of
moderate size. Levels 5 to 10 for genuine research, multi-source
comparison, or anything where being wrong is expensive. State
the ceiling rule: do not run at maximum effort by default,
because past a point extra reasoning makes output worse, not
better — the tells are looping over the same consideration,
second-guessing a correct answer into a hedged one, and length
growing while content does not. When you notice any of those
three tells mid-task, stop expanding, commit to the strongest
reading you have, and deliver. State the cost rule too: if a
cheaper path reaches the same answer, take the cheaper path and
say which one you took.
13. Process over horsepower: your value comes from the loop you
run, not from how strong you are. So the loop must be explicit
and repeatable. State how to decompose a large task into steps a
weaker model could each complete, how to hand each step a single
clear objective with its own acceptance test, how to check each
result before passing it on, and how to assemble the parts into
one coherent whole rather than a stack of fragments. State the
rule for choosing depth per step: give the hard step the effort,
not every step. State what to do when a step comes back wrong —
retry once with a tightened objective, and if it fails again,
escalate to me with the specific blocker rather than papering
over it.
End the document with a single final gate: the last check to run
before any response is sent, stated as a fix-and-recheck rule.
Every instruction must be trigger → action. No praise, no preamble,
no restating these requirements back to me. Each procedure gets one
worked example showing it catching a real mistake, and each names
the failure it prevents. Keep the whole document under 1,500 words
— if a rule cannot earn its space, cut it.Why the prompt is shaped like that
Five constraints do most of the work, and they are worth understanding separately from the 13 topics.
It is addressed to the successor, not about it. "Orders. Not advice about good thinking." A document that says "it is important to consider the user's intent" is unusable as a system prompt. One that says "when the request is vague, attempt the most probable reading first, then ask at most one question" is executable.
No vendor names inside. Naming a model dates the document the day you switch. This is the difference between a prompt you rewrite every quarter and one you keep.
Assume the reader is weaker. No large context window, no tools, no memory across sessions, no reliable long reasoning — and "where a rule needs capability the reader may not have, state the cheap fallback in the same rule." The fallback lives beside the rule, not in an appendix nobody reaches.
Trigger → action, with a worked example each. Every procedure has to show itself catching a real mistake and name the failure it prevents. A rule that cannot name its failure is decoration.
A hard word budget. Under 1,500 words, "if a rule cannot earn its space, cut it." Without a ceiling this kind of prompt reliably produces four thousand words of well-meaning mush, and long system prompts compete with the actual task for attention.
Three rules worth stealing on their own
Even if you never run the extraction, three of the 13 are unusually good and you can lift them into any system prompt you already maintain.
#12, the ceiling rule. Most prompt advice pushes for more reasoning. This one argues the opposite past a point, and — importantly — gives three observable tells: looping over the same consideration, second-guessing a correct answer into a hedged one, and length growing while content does not. Tells are what make a rule enforceable.
#11, verify before you rely. "Never assume a file, link, dataset, table, or tool exists because I said it does." Treat memory, resources, and your own summaries as claims. If you cannot confirm, stop rather than invent.
#13, process over horsepower. "Your value comes from the loop you run, not from how strong you are." Give the hard step the effort, not every step. Retry a failed step once with a tightened objective, then escalate with the specific blocker instead of papering over it.
The workflow
- Open a new session on the strongest model you have and select it explicitly.
- Paste the prompt above. Wait — this one takes a while; it is producing a document, not a reply.
- Copy the generated instructions.
- Create a Project (or the equivalent custom-instruction slot) on the cheaper model you actually want to run.
- Paste the document into that project's instructions and save.
- Ask the cheaper model to read its own instructions back and summarise them.
What step 6 actually proves — and what it does not
In the video, the second model reads the instructions back and returns a clean summary of the key areas. It is worth being precise about what that shows.
It shows the document loaded — that it fits, parses, and is visible to the model. That is a real check and it is worth running, because a document that silently blew the instruction limit fails here.
It does not show the document works. A model summarising its own instructions is testing retrieval, not behaviour. It is the same shape of mistake the AI-Engineering Governance session takes apart at length: a green check that measures something adjacent to what you care about. Tests passing is not the system being right, and instructions loading is not the model following them.
To actually measure it, you need the boring version:
- Fix a set of ten tasks representative of your real workload.
- Run each on the cheap model without the instructions. Save the outputs.
- Run the same ten with the instructions.
- Score both sets blind, against criteria you wrote before you looked at any output.
That is more work than the demo, and it is the only thing that turns "the output should be better" into a number. Without it, the honest claim is the one the video itself makes near the end: it will not be identical to the frontier model, but the rules are now explicit rather than absent.
What I take from this
The interesting artefact here is not the 13 rules. It is the realisation that the operating procedure and the model are separable — that most of what makes a strong model pleasant to work with is a loop, and a loop can be written down and handed to something cheaper.
That is also the honest limit. A written loop cannot give a weaker model judgement it does not have. What it can do is stop that model from failing in the ten specific ways it otherwise would, which is a smaller claim and a much more defensible one.
Related
- Claude Fable 5 vs Claude Opus 5: One Prompt, Two Models, One Excel File — the same two model tiers, measured on a single build task instead of a prompt.
- Session 4 — AI-Engineering Governance — why a green check is not evidence, worked through a real failure.
- Session 5 — AI-Driven Workflow — quality gates as sufficient evidence, and where a model's autonomy stops.