Model behavior demo
The Effort Dial Reveal
Run one ambiguous task at low and high thinking effort, then read the two answers side by side to show what deliberation actually buys.
"adaptive thinking"
Casting: which model to run
Claude Fable 5.1 and Claude Opus 5 both use adaptive thinking, and Fable 5.1 defaults to high effort in Claude Code and medium on Claude.ai and Cowork. Those defaults are the reason the same prompt can feel like a different model on two surfaces, which is the whole demo.
See the casting page for the full current lineup and API IDs. MagicClaude does not score models; Claude Reports covers benchmark comparisons and pricing analysis.
Setup: what the audience sees
The audience expects a bigger answer at higher effort. What they usually get is a different answer: the careful run questions the premise, names the missing dependency, or refuses to proceed on an underspecified requirement. Watching a model find the trap you planted is more convincing than watching it write more words.
The setup matters because Claude demos fail when the prompt hides the goal, mixes private data into a public reveal, or asks for a finished answer without giving the model a way to expose assumptions.
- Use a surface where you can set effort explicitly: the API, or Claude Code where Fable 5.1 defaults to high.
- Pick a task with a hidden trap rather than a hard task: an underspecified requirement, a subtly wrong premise, or a plan with a missing dependency.
- Write down what you expect a careful answer to catch, before you run anything.
- Run the identical prompt at each setting. Changing the prompt between runs destroys the comparison.
What this does not prove
Two runs of one prompt prove nothing about either model in general, and higher effort is not reliably better. This is a demonstration that the dial exists and changes behavior, not a measurement of how much. Scored model comparisons belong on Claude Reports.
<task>
Review this plan and tell me whether to approve it.
</task>
<plan>
We will migrate the billing service to the new pricing table on the 1st.
The migration script backfills historical invoices, then flips the feature flag.
Rollback is: flip the flag back.
</plan>
<instructions>
- State your recommendation first: approve, approve with conditions, or do not approve.
- List every assumption the plan makes that it does not state.
- Identify anything in the plan that cannot be undone by the stated rollback.
- If you cannot judge the plan without more information, say exactly what you need.
</instructions>The reveal: what should happen
- A careful run should notice that flipping a flag back does not undo a historical-invoice backfill, so the stated rollback is incomplete.
- The higher-effort run tends to surface unstated assumptions and ask for missing information instead of producing a confident approval.
- Both runs are often well written. The difference shows up in what they question, which is why you write down the trap beforehand.
- Sometimes the low-effort run catches it too. Say so when it happens; a demo that only works when the model underperforms is not a demo.
Verification steps
A demo becomes useful when the audience can inspect it. Use the steps below to turn the reveal from theater into a repeatable workflow.
- Diff the two answers and mark which of your pre-written expected catches each one found.
- Re-run each setting at least twice, because a single pair can differ by sampling rather than by effort.
- Note the latency difference alongside the quality difference, since that tradeoff is the actual decision a team makes.
- Check the model ID and effort setting in the response metadata rather than trusting your own memory of what you configured.
Guardrails
- Do not present the result as a benchmark, a percentage, or a general claim about either model.
- Report the runs where higher effort did not help. Selective reporting is how honest demos become marketing.
- Use a synthetic plan rather than a real internal migration document.
- Higher effort costs more and takes longer. Say that out loud when someone asks why it is not the default everywhere.
Variations
- A code review where the diff compiles but breaks a documented invariant.
- A data question where the obvious aggregation is the wrong one.
- A requirements document with two sections that quietly contradict each other.
FAQ
Where can I actually change the effort level?
Anthropic documents a default effort level per surface: high in Claude Code and medium on Claude.ai and Cowork for Claude Fable 5.1. Check the Fable 5.1 overview for the current list of ways to set it, including the per-message beta, since that surface area is still changing.
Is more thinking always better?
No, and the demo is more credible when you show a case where it was not. Higher effort costs more and takes longer, which is why Anthropic ships different defaults on different surfaces rather than maximizing everywhere.
Does this belong on a benchmark site instead?
The scored version does. MagicClaude shows that the dial changes behavior in a way a room can watch; Claude Reports is where comparisons get numbers and methodology.
Primary Sources
These demos cite official Anthropic docs or help-center pages for capability claims. They do not claim identical output across accounts, plans, models, or dates.
Claude Platform Docs
Claude Fable 5.1 overview
Claude Fable 5.1 (`claude-fable-5-1`) has a 1M-token context window, 128K max output, always-on adaptive thinking, and a default effort level of high in Claude Code and medium on Claude.ai and Cowork.
Claude Platform Docs
Claude Opus 5 overview
Claude Opus 5 (`claude-opus-5`) launched July 24, 2026 with a 1M-token context window, 128K max output, adaptive thinking, and an optional fast mode.
Claude Platform Docs
Choosing a model
Anthropic guidance is to start with Claude Opus 5 for most work, move to Claude Fable 5.1 for demanding reasoning and long-horizon agentic tasks, use Sonnet 5 for the speed/intelligence balance, and Haiku 4.5 for the fastest and cheapest runs.
Claude Platform Docs
Prompting best practices
Anthropic guidance emphasizes explicit instructions, output formats, tool-use direction, and model-specific prompt updates.