Most of us learned to prompt against models that lost the plot. So we compensated. We wrote long numbered instructions, stacked example after example, repeated our constraints every turn, and told the model to think step by step as if it might forget how. That was rational for the Opus era. On Claude Fable 5, a good chunk of it is now wasted motion, and some of it actively makes the output worse.
This is a technique guide, not a spec sheet. The claims about model behavior below are things to try and measure on your own code, not benchmarks. What I can say with confidence is the shape of the shift: as the model gets more capable, prompting moves from dictation toward delegation. You spend fewer words telling it how and more words telling it what and why, then you verify hard.
STATE INTENT, NOT STEPS
The single biggest change is to stop writing the model's to-do list for it. When you hand a strong model a ten-step script, you cap it at your own plan, including your mistakes. State the outcome you want, the constraints that are non-negotiable, and let it sequence the work.
Here is a typical Opus-era prompt, over-scaffolded:
Add caching to the weather API.
Step 1: create a new file called cache.ts
Step 2: import the redis client from lib/redis.ts
Step 3: write a function getCached that takes a key
Step 4: check if the key exists in redis
Step 5: if it exists, parse the JSON and return it
Step 6: if not, call the API, store the result with a 300 second TTL
Step 7: wire it into the getWeather function in weather.ts
Step 8: make sure you handle the case where redis is down
The same task, stated as intent:
Cache the weather API responses to cut redundant upstream calls.
Constraints: reuse the existing redis client in lib/redis.ts, 5 minute TTL,
and fail open if redis is unavailable (never block a weather lookup on cache).
Show me your plan before editing, then implement it.
The second version is shorter, and it lets the model choose the file layout, the function shape, and the failure handling. You have told it the two things it cannot guess: reuse the existing client, and fail open. Everything else is implementation, which is exactly what you are paying it to do.
STOP FEW-SHOTTING BEHAVIOR (KEEP IT FOR FORMAT)
Few-shot examples do two different jobs, and it is worth separating them. One job is teaching a format: "output looks like this." The other is teaching behavior: "here is how to reason about the task." Format examples are still useful. Behavior examples, in bulk, increasingly backfire, because the model anchors to your samples instead of generalizing to the real task.
If you were doing this to classify support tickets:
Classify the ticket. Here are examples:
Ticket: "I can't log in" -> category: auth, priority: high
Ticket: "How do I export CSV?" -> category: docs, priority: low
Ticket: "Charged twice this month" -> category: billing, priority: high
Ticket: "Dark mode please" -> category: feature-request, priority: low
Ticket: "App crashes on upload" -> category: bug, priority: high
Ticket: "Can I change my email?" -> category: account, priority: medium
[... eight more examples ...]
Try trimming to a format anchor plus the actual decision rules:
Classify the ticket into one category (auth, billing, bug, docs,
feature-request, account) and a priority (high, medium, low).
Priority is high when the user is blocked or losing money, low when it is
a nice-to-have. Return JSON: {"category": ..., "priority": ...}.
Ticket: "I can't log in"
One example fixes the shape. The rules carry the reasoning. This tends to generalize better to tickets that look nothing like your samples, which is the whole point of a classifier. Test both on a held-out set and keep whichever wins.
LET IT PLAN, THEN APPROVE THE PLAN
On hard tasks, the highest-value prompt is often not the task itself but a request for a plan. A capable model can decompose a fuzzy goal into a real sequence, surface the risky decisions, and let you course-correct before a single file changes. This is cheap insurance against a confident wrong turn.
I want to migrate our auth from session cookies to JWTs without logging
everyone out. Don't write code yet. Give me a migration plan: the phases,
what breaks between phases, how existing sessions keep working during the
transition, and the riskiest step. Then wait for me to pick an approach.
You read the plan, you catch the assumption you disagree with, and you redirect. This is where Claude Code's plan mode earns its keep on the harder jobs. We covered the workflow in Claude Code plan mode. The stronger the model, the more of the planning you can safely delegate, and the more it costs you to skip the review.
MAKE VERIFICATION PART OF THE PROMPT
Here is the counterintuitive part. As models get more capable, verification asks matter more, not less. The failure mode changes. A weaker model gives up or stalls, which is obvious. A stronger model produces something plausible and confident that is subtly wrong, which is dangerous precisely because it reads as correct.
So build the proof into the request. Do not accept "done" as a claim. Ask for evidence.
Fix the flaky test in checkout.test.ts. When you are done:
1. Run the full test file and paste the output.
2. Run it three more times to show the flake is gone.
3. Explain in two sentences what was actually racing.
Don't tell me it's fixed. Show me the runs.
The same principle scales up to agent loops. A prompt that ends with "and verify it works by running the tests and showing me the result" produces a fundamentally different artifact than one that ends with "implement the feature." The first one has to confront reality. This is the same discipline we mean when we say a prompt is a contract and evidence is done: see Fable returns.
OPUS-ERA HABITS THAT NOW WASTE TOKENS
A few reflexes worth auditing. None of these are absolute, but each is worth an experiment where you remove it and check whether quality actually drops.
"Think step by step." On models with strong built-in reasoning, this instruction is often redundant, and on models where thinking is configured separately it does nothing useful in the prompt body. If you want deeper reasoning, tune the reasoning controls rather than begging in prose. We broke those controls down in adaptive thinking and effort.
The context dump. Pasting three files "just in case" when the task touches one of them. A capable model in an agentic tool can read what it needs. Giant preemptive dumps cost tokens and can bury the signal. Give it a way to find context instead of front-loading all of it.
The reminder preamble. "As a reminder, we are building a task app for freelancers, using Next.js and Convex, and earlier we decided..." on every single turn. If the model is holding the thread, this is pure overhead. Say it once, put durable facts in your project's instructions file, and stop repeating yourself mid-conversation.
Defensive over-constraining. Ten "make sure you don't..." clauses guarding against mistakes the model was not going to make. Each one narrows the solution space and adds noise. State the constraints that genuinely matter and trust the model on the rest, then verify.
Re-prompting instead of correcting. When the output is 80% right, builders often rewrite the whole prompt from scratch. It is usually cheaper and more accurate to point at the specific gap: "This is close. The error handling swallows the exception. Surface it to the caller and keep everything else." Correction preserves the good work; re-prompting rolls the dice again.
A FULL BEFORE-AND-AFTER
Putting it together. Here is a prompt written in full Opus-era defensive style:
I need you to build a contact form. Please follow these steps carefully.
First, think step by step about the requirements. The form should have a
name field, an email field, and a message field. Make sure the email is
validated. Make sure you don't forget to handle errors. Here is an example
of a form we built before: [200 lines pasted]. Please match this style
exactly. Also remember we are using React and Tailwind, and earlier we
decided to use react-hook-form. Make sure the form is accessible. Make sure
you validate on the server too. Please be thorough and don't cut corners.
The delegation version:
Build a contact form: name, email, message. Validate on both client and
server, and make it accessible (labels, error announcements, focus on the
first invalid field).
Match our conventions: React, Tailwind, react-hook-form. Follow the patterns
in components/forms/ rather than a pasted example.
Show me the plan first. When you implement, include the server validation
and show me one happy-path and one invalid-submission test passing.
Shorter, and it carries more information the model cannot guess (where the conventions live, what "accessible" means here, what proof you expect) while dropping everything it can figure out on its own. That trade, fewer instructions and more intent plus verification, is the whole technique in one prompt.
THE MENTAL MODEL
Prompting a more capable model is less like programming and more like handing off to a strong senior engineer. You would not give a senior a ten-step checklist for adding a cache. You would tell them the goal, the constraints they cannot see from the code, and how you want to review it. Then you would check their work, not their keystrokes.
Fable 5 rewards that stance. Say what you want and why, name the constraints it cannot infer, let it plan, and demand evidence instead of claims. Then keep the prompts that worked. A prompt that reliably produces a good artifact is an asset. Save it in Command Center and turn it into a repeatable workflow rather than retyping it from memory next week. If you want the structured path from beginner prompts to this delegation style, start with Boostor University.
SOURCES AND FURTHER READING
- Anthropic: Claude Fable 5 and Mythos 5
- Anthropic: prompt engineering overview
- Boostor: How adaptive thinking and effort work
FAQ
Do I still need few-shot examples with Fable 5? For pinning an output format, yes, one or two help. For teaching behavior, large example sets can anchor the model to your samples and hurt generalization. Trim them and test on held-out cases.
Should I tell Fable 5 to think step by step? Usually not in the prompt body. Reasoning depth is better controlled through the model's thinking and effort settings than by asking in prose. Tune the controls, not the wording.
What is the fastest way to improve my Fable 5 prompts? Add a verification ask. End coding prompts with an instruction to run the tests and show the output. It changes what the model has to confront and catches confident-but-wrong results early.