🪜 The 5 effort levels
🧠 Imagine it this way: effort it's not a "dumb/smart" button — it's a control for how much reasoning the model devotes to a problem before answering. Five levels, from fastest to unlimited.
Claude Fable 5 exposes five effort levels that you can configure per call: low, medium, high, xhigh e max. Each level is a behavioral signal—not a hard token limit—that tells the model how much it's worth deliberating before acting or responding.
This is different from simply truncating the response: in low, Fable 5 still thinks enough for genuinely difficult problems—it just thinks less than it would think about the same problem in high or xhigh. The right level depends on the type of task, not on "how much you trust the model".
| Level | Official description | Typical use case |
|---|---|---|
| low | More efficient, significant savings | Simple tasks that need speed/minimal cost, e.g. subagents |
| medium | Balance, moderate savings | Agentic tasks that need a balance of speed/cost/performance |
| high (default) | High capability—equivalent to not setting the parameter | Complex reasoning, difficult coding, agentic tasks |
| xhigh | Extended capacity for long-horizon work | Long-running agentic/coding tasks (>30min), budgets in the millions of tokens |
| max | Absolute maximum capacity, with no token spending limit | Deeper reasoning, more complete analysis |
Source: official doc effort — platform.claude.com/docs/en/build-with-claude/effort
The 5-level ladder: each step increases the allowed capability (dashed cyan line)— high it’s the highlighted step because it’s what you get without setting anything.
In one sentence: 5 levels (low→max), configurable per call, where high is what you already have today if you don’t change anything.
🔌 How to configure via API
The effort level enters the body of the call through output_config, an object that accepts a single field effort with one of the five strings. Omitting the entire field is equivalent to using "high" — it's literally the default.
This means switching levels doesn't require changing models, endpoints, or SDKs: it's one more parameter in the same call you already make today. You can vary the level by call type within the same agent—for example, an orchestrator at high and subagents in low.
medium before assuming you need high.{
"model": "claude-fable-5",
"max_tokens": 4096,
"output_config": { "effort": "medium" },
"messages": [
{ "role": "user", "content": "<isto você troca — descreva a tarefa>" }
]
}
usage (output tokens) and response time against the same task with "effort": "high". In medium, expect fewer reasoning tokens and faster responses—if quality drops for your task, move up a level.💡 Practical tip
The same field output_config works the same with the Claude API, Claude Platform on AWS (Bedrock), and Vertex AI—there’s no different parameter for each cloud provider. This makes it easier to test different levels without rewriting the integration layer.
In one sentence: output_config: {"effort": "..."} in the request body — without a parameter, you're already in high.
🎯 Official recommendation for Fable 5
🧭 The practical scale
For Fable 5, the recommended guideline isn’t “always use the maximum to ensure quality”—it’s to calibrate by task type:
- •high as the default—it covers most agentic work and hard coding, and it's what you already get without changing anything.
- •xhigh for work capability-sensitive — long sessions (>30min), million-token budgets, where reasoning capacity matters more than speed.
- •medium/low for routine tasks—subagents, simple and repetitive tasks, where speed and cost matter more than reasoning depth.
Anthropic’s own documentation is explicit about what the parameter no is a fixed-budget cutter. It’s a behavioral signal that the model interprets on a case-by-case basis.
Effort is a behavioral signal, not a strict token budget. At lower effort levels, Claude will still think on sufficiently difficult problems, but it will think less than it would at higher effort levels for the same problem.
Esforço é um sinal comportamental, não um orçamento rígido de tokens. Em níveis de esforço mais baixos, o Claude ainda vai pensar em problemas suficientemente difíceis, mas vai pensar menos do que pensaria em níveis mais altos para o mesmo problema.
Source: platform.claude.com/docs/en/build-with-claude/effort
Important caveat: low effort in Fable 5 isn't a “dumb downgrade.” It’s a frontier model operating with less deliberation—in practice, it still delivers solid results for tasks within its actual complexity. People coming from Opus 4.8 tend to overestimate the level they need out of habit.
✓ What to DO
- ✓Let
highas the default for hard coding and routine agentic tasks. - ✓Move up to
xhighonly when the task has a long horizon (>30min, millions of tokens of budget). - ✓Scroll down to
medium/lowon subagents, routine work, and simple tasks that just need speed.
✗ What to AVOID
- ✗Assuming that
effortlow gives a "half-baked" answer — Fable 5 still performs well atlow. - ✗Leave everything at
max"just in case," without measuring whether the benefit is worth the cost. - ✗Never compare the same prompt at 2 different levels before setting your app’s standard.
In one sentence: high by default, xhigh for work where capability matters, medium/low for routine tasks—and low effort doesn’t mean weak.
🛡️ The refusal mechanism
⚠️ Attention—this isn’t a mistake
When Fable 5 refuses a request for safety reasons, the HTTP response is 200 — success — with stop_reason: "refusal" in the body. It's not an exception, it's not a 4xx/5xx, and your generic error handling won’t catch this on its own. You need to check stop_reason explicitly.
When this happens, stop_details.category comes filled in with one of four possible categories. None of them means “your request was malicious”—the official texts make it explicit that benign work can also trigger the category.
| category | What it means (official text) |
|---|---|
| cyber | "The request could enable cyber harm, such as malware or exploit development. Benign cybersecurity work can also trigger this category." The request could enable cyber harm (malware/exploit); legitimate cybersecurity work can also trigger it. |
| bio | "The request could enable biological harm, such as dangerous lab methods. Beneficial life sciences work can also trigger this category." The request could enable biological harm; beneficial life sciences work can also trigger it. |
| frontier_llm | "The request could assist the development of competing AI models, which is restricted under Anthropic's commercial terms. Benign machine learning work can also trigger this category." The request could help develop competing AI models (restricted by the commercial terms); benign ML work can also trigger it. |
| reasoning_extraction | "The request asks the model to reproduce its internal reasoning in the response text. To get reasoning in a structured form instead, use adaptive thinking." The request asks the model to reproduce its internal reasoning as text; use adaptive thinking to get this in a structured way. |
Source: official doc refusals-and-fallback — platform.claude.com/docs/en/build-with-claude/refusals-and-fallback
The category reasoning_extraction deserves special attention because it’s the easiest to trigger by accident: all it takes is an old skill or system prompt asking the model to “show its reasoning” in the response. Anthropic itself recommends auditing instructions like this when migrating to Fable 5.
Don't instruct Claude to reproduce its reasoning in the response. Prompts, skills, or harness instructions that tell the model to echo, transcribe, or explain its internal reasoning as response text can trigger the reasoning_extraction refusal category on Claude Fable 5, causing elevated fallbacks to Claude Opus 4.8. Audit existing skills and system prompts for reflection or show-your-thinking instructions when migrating. If your application needs reasoning visibility, read the structured thinking blocks from adaptive thinking instead.
Não instrua o Claude a reproduzir seu raciocínio na resposta. Prompts, skills ou instruções de harness que pedem pro modelo ecoar, transcrever ou explicar seu raciocínio interno como texto de resposta podem disparar a categoria de recusa reasoning_extraction no Claude Fable 5, causando mais fallbacks pro Claude Opus 4.8. Audite skills e system prompts existentes em busca de instruções de reflexão ou de "mostre seu raciocínio" ao migrar. Se sua aplicação precisa de visibilidade do raciocínio, leia os blocos de thinking estruturado do adaptive thinking em vez disso.
How to check: paste the notice (EN or PT-BR, either is fine—it’s for you to read, not the model) as a reminder in your migration process, audit your project’s skills/system prompts for instructions like "explain your reasoning" or "show how you arrived at that answer," and remove them. The sign of success: fewer refusals reasoning_extraction in the logs.
In one sentence: safety refusal is HTTP 200 with stop_reason: "refusal" + 1 of 4 categories — never a network exception.
🧾 Billing for a refusal + how to configure a fallback
📐 Billing rule
- Refusal before any output — is not charged. The field
usageappears in the response, but does not incur a charge or use up the rate limit. - Refusal mid-stream — charges for the input and output already generated up to the refusal point (you pay for what’s already been generated, not the entire request).
To keep end users from running into a refusal, Anthropic offers three ways to route automatically to the Claude Opus 4.8 when Fable 5 refuses — each with a different level of implementation effort.
Server-side fallback
Claude API / Claude Platform on AWS, via beta header
Resolved in one single request — you make the normal call with the beta header enabled, and if Fable 5 refuses, the platform itself reissues it to Opus 4.8 before returning the response to you. No extra logic in your code.
SDK middleware
BetaRefusalFallbackMiddleware — TS/Python/Go/Java/C#
An official SDK middleware intercepts the stop_reason: "refusal" in your own process and automatically resubmits the request to Opus 4.8 — useful when you already orchestrate calls in your backend and want to keep control there.
Manual retry with fallback credit
Raw Ruby/PHP/HTTP — languages without official middleware
You check it yourself stop_reason in the response and, if "refusal", triggers a new call to Opus 4.8 using the fallback credit — the most manual approach, but the only one available outside the official SDK ecosystem.
Cyan marks the detour: request → classifier (focused on glow) → if refused, the category becomes a bridge to Opus 4.8; if approved, it continues through the normal Fable 5 flow.
Look at how we call the Claude API in this codebase (SDK, language, whether we stream responses) and tell me which of the three Fable 5 refusal-fallback options fits best: (1) server-side fallback via the beta header, (2) SDK middleware (BetaRefusalFallbackMiddleware), or (3) manual retry with a fallback credit. Point to the exact file/line where I'd wire it in, and flag if we're on a language (Ruby/PHP/raw HTTP) that only supports the manual-retry path.
Olhe como chamamos a API da Claude neste código (SDK, linguagem, se as respostas são via streaming) e me diga qual das três opções de fallback de recusa do Fable 5 se encaixa melhor: (1) fallback no servidor via beta header, (2) middleware do SDK (BetaRefusalFallbackMiddleware), ou (3) retry manual com fallback credit. Aponte o arquivo/linha exatos onde eu conectaria isso, e avise se estamos numa linguagem (Ruby/PHP/HTTP cru) que só suporta o caminho de retry manual.
In one sentence: refusal before output is not billed; for automatic fallback, choose between server-side, SDK middleware, or manual retry based on your stack.
📊 Cost comparison
Fable 5 costs exactly twice as much for Opus 4.8 per token, for both input and output. At first glance, it always seems more expensive. But price per token and total task cost are different things—and that’s where the practical insight of this topic lies.
| Model | Input | Cache write 5m | Cache write 1h | Cache hit | Output |
|---|---|---|---|---|---|
| Fable 5 / Mythos 5 | $10/MTok | $12.50/MTok | $20/MTok | $1/MTok | $50/MTok |
| Opus 4.8 | $5/MTok | — | — | — | $25/MTok |
| Sonnet 5 (through Aug 31, 2026) | $1/MTok | — | — | — | $5/MTok |
| Haiku 4.5 | $0.50/MTok | — | — | — | $2.50/MTok |
Source: platform.claude.com/docs/en/about-claude/pricing · MTok = million tokens. Batch API (50% off) brings Fable 5 to $5/$25 per MTok — the same list price as synchronous Opus 4.8.
🧮 Illustrative example (hypothetical token counts—not an official benchmark)
Hypothetical coding task: 300k input tokens + 40k output tokens to finish.
- Fable 5 at low effort, gets it right on the first try (1 round): 0.3 × $10 + 0.04 × $50 = $3 + $2 = $5
- Opus 4.8 @ xhigh, needs 3 rounds to get the same result (rereading context with each iteration—900k input + 120k output accumulated): 0.9 × $5 + 0.12 × $25 = $4.5 + $3 = $7.5
Even at twice the cost per token, Fable 5 comes out cheaper overall in this scenario — because "getting it right on the first try in complex systems" (a capability Anthropic itself highlights for Fable 5 vs. Opus 4.8) eliminates entire rounds of iteration, not just reduces the cost per round.
✓ What to DO
- ✓Measure the cost total of the task (input + output through to the final result), not just the $/MTok.
- ✓Use the Batch API (50% off) for asynchronous jobs that don't need an immediate response.
- ✓Take advantage of caching (5min = 1.25x, 1h = 2x, hit = 0.1x) when the same large context is repeated across calls.
✗ What to AVOID
- ✗Conclude that Opus 4.8 is always cheaper just because it costs half as much per token.
- ✗Ignoring how many rounds/iterations the task needs to actually finish.
- ✗Forgetting the multiplier
inference_geo:"us"(1.1x) when budgeting by region.
💡 Extra context: Fable 5 has a 1M-token context window by default and up to 128k tokens of output per request, without price premium for long context — another variable in the "total cost" calculation that you won't see by looking only at the table's $/MTok.
In one sentence: Fable 5 at low effort can cost less overall than Opus 4.8 at xhigh/max—even though it costs twice as much per token—because it makes fewer mistakes.
🧾 Module Summary
high it’s the default, configurable via output_config.effort.high for most people, xhigh only on long tasks, medium/low for routine tasks—and low effort still performs well.stop_reason, not an error — HTTP 200, 4 categories (cyber/bio/frontier_llm/reasoning_extraction); refusals before output aren’t charged.Next module:
1.7 — Bonus: subagents, memory, and send_to_user.
Sources for this module: platform.claude.com/docs/en/build-with-claude/effort · platform.claude.com/docs/en/build-with-claude/refusals-and-fallback · platform.claude.com/docs/en/about-claude/pricing · platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5