Claude Fable 5.1 Prompting: 5 Things to Change First
Claude Fable 5.1 prompting mostly means taking instructions out. Prompts written for earlier models are often too prescriptive for this one, and they reduce the quality of what comes back. So the scaffolding you built to make a weaker model reliable is now working against you. Below are the 5 prompt changes worth making first, where the effort dial actually lives, and the 3 API settings that stop working the moment you switch the model name.
Key Takeaways
- Prompts tuned for an older model can make this one worse. Take the step by step scaffolding out and state the goal instead.
- Effort is the main dial. Start at high for most work, drop to medium or low for routine tasks, and only go above high when a test shows you need it.
- A single request can run for many minutes. Plan for that before you point it at anything real.
- If you build on the API, 3 things that used to be normal now fail outright: a thinking budget, a forced tool call, and a custom temperature. Editing an earlier turn can fail too.
- It is not the default upgrade. Start with Claude Opus 5 and reach for this one when Opus 5 falls short.
If you want the practical part, jump to the 5 changes. Model behavior and pricing move quickly, so treat everything here as current at the time of writing and check the linked docs before you commit a config.
What Claude Fable 5.1 Prompting Actually Means
Claude Fable 5.1 is Anthropic's most capable widely released model, built for demanding reasoning and work that runs a long time without a person watching. Prompting it well is less about writing more and more about writing less, then being specific about the few things it cannot infer: why the task matters, what it must not touch, and when it is allowed to stop.
That is a real reversal. On earlier models, adding a checking step or a numbered procedure usually bought reliability. Here it costs quality, because the model already does that work and a prescribed path narrows the space it is allowed to search.
The 5 Changes to Make First
Each of these is a short block you paste into a system prompt or a project instruction file. None of them needs an API to use. If you keep a CLAUDE.md file, that is the natural home for all 5.
1. Delete the verification scaffolding
The lines telling the model to double check, re run the tests, or confirm its own output. It verifies on its own, so an instruction to verify buys a second pass you did not need. The same deletion applies to Opus 5 prompting, which is where I would start if you are not on Fable.
Delete first. Only add an instruction back if a real task fails without it.
2. Give the reason, not just the request
This model connects a task to context better when it knows what the output is for. The shape is simple:
I'm working on [the larger task] for [who it's for].
They need [what the output enables].
With that in mind: [request].
3. Say what it should not do
At higher effort it can tidy things you did not ask it to tidy. Name the boundary instead of hoping:
Don't add features, refactor, or introduce abstractions beyond
what the task requires. A bug fix doesn't need surrounding
cleanup. Don't design for hypothetical future requirements.
Don't add error handling for scenarios that cannot happen.
Only validate at system boundaries.
4. Tell it to finish the turn
Deep into a long session it can occasionally end on a statement of intent rather than the work. In a conversation you just say "continue". For anything running unattended, close the door in the prompt:
You are operating autonomously. Nobody is watching in real
time, so asking "shall I proceed?" blocks the work. For
reversible actions that follow from the request, proceed
without asking. Before ending your turn, read your last
paragraph. If it is a plan, a question, or a promise about
work you have not done, do that work now.
That opening sentence does most of the work.
5. Set the communication style
It responds strongly to explicit instructions about how to write, which is cheaper than fixing the output afterwards. This one is worth tuning to your own taste:
Lead with the outcome. Your first sentence should answer
"what happened" or "what did you find". Detail comes after.
Being readable and being concise are different things, and
readability matters more. Keep output short by leaving
things out, not by compressing into fragments or shorthand.
How to Set Effort on Claude Fable 5.1
Effort is the setting that changes the most on this model, and the one worth revisiting most often. There are 5 levels: low, medium, high, xhigh, and max. High is the API default. In the API it sits inside the output configuration rather than at the top level of the request, and each level trades speed against depth differently, set out on the effort page. In Claude Code you set it with the /effort command, and there is no request body to edit.
Which effort level should you start at?
Start at high, then test downward. Low still performs very well on this model, often beating what previous models produced at their top settings, so the cheapest useful setting is usually lower than instinct suggests.
| Level | Reach for it when |
|---|---|
| Low | High volume or routine work, and subagents you run many of at once |
| Medium | Everyday tasks where you want the cost down and the quality held |
| High | The default, and the reference point you measure the others against |
| Xhigh | The most capability sensitive work, once a test shows high leaves something behind |
| Max | Correctness matters more than cost and you have measured the gap |
Does higher effort mean better answers?
Not reliably, and that is the part worth internalizing. At higher effort on routine work it gathers context and deliberates past what the task needs. You wait longer and pay more for an answer that was already available a level down. The flip side is real too: higher effort buys the most rigorous verification behavior, so it earns its keep on genuinely hard problems.
Can you change effort partway through?
Yes. It is new to this tier, though Opus 5 already had it. Effort can be raised for one hard step and dropped again without throwing away the cached conversation, which used to be the reason people left it pinned. That capability is in beta at the time of writing and is an API feature. On a subscription you get most of the way there by switching levels between turns, though that is a different mechanism and the cached conversation does not survive it the same way.
Do effort levels mean the same thing across models?
No. A level tuned on a previous model is not measuring the same amount of thinking here, so a setting carried over is a guess, not a decision. Re run your own comparison rather than porting the old number.
API Settings That Now Return an Error
These are API settings. On a Claude subscription there is nothing here to change, so skip to when not to reach for it unless you also build against the API.
For everyone who does, these are the changes that break code rather than degrade it, and they fail loudly, which is the good case. More changed than these 3. See the migration guide for the rest.
Can you still set a thinking budget?
No. Thinking is always on here and you cannot put a token budget on it or turn it off. Both return an error. Depth is still yours to set, through the effort level rather than a budget, and you can separately choose whether you see any of it. There is no replacement, because effort is an output level control rather than a thinking budget. If your wrapper sets either one, it is already broken.
Can you force a tool call?
No. Forcing the model to call a specific tool, or any tool, now returns an error. If you were doing that to guarantee valid JSON, the replacement is strict tool definitions or a structured output format. If you simply need a tool used, say so in the prompt. It follows an explicit instruction to use a tool reliably.
Can you still set temperature?
No. Custom temperature and the related sampling controls are rejected. A wrapper that sets temperature to 0 out of habit will fail on every request, which is a 5 second fix and an easy one to miss when the failure looks like an outage.
What breaks if you edit an earlier message?
The reasoning attached to that conversation. Editing an earlier turn, or injecting a reminder and deleting it later, invalidates the thinking already recorded, and on API accounts created from 31 August 2026 onward it returns an error. Older accounts are not enforced by default yet, and the plan is to enforce it everywhere on future models, so treat the conversation as append only now. For a reminder that should show up once, there is now a turn scoped system message that clears itself rather than being removed by hand.
When Not to Reach for Claude Fable 5.1
Anthropic's own positioning is to start with Claude Opus 5, and to move up only for demanding reasoning, long horizon agentic work, or when Opus 5 at a higher effort still falls short. That is worth taking at face value.
What does Claude Fable 5.1 cost?
At the time of writing it is 10 dollars per million input tokens and 50 dollars per million output tokens, against 5 and 25 for Claude Opus 5. Exactly double. Cached input reads are much cheaper on this model, at 0.25 dollars per million, which changes the usual habit of trimming a conversation early to save money: keeping more warm context can now cost less than making the model work it out again.
Those are API rates. On a Claude subscription there is no invoice and no per token line item, so the question becomes how fast a model moves your usage limits, not what a run costs in dollars.
Is Claude Opus 5 enough?
For most work, yes, and it is the model I would default to. The pattern worth borrowing instead of switching wholesale is running a cheaper model as the executor in an advisor setup, calling the stronger one only at the decisions that need it. That keeps the capability available at the moments it changes the answer, without paying for it on every turn.