Here is the line that reframes the effort parameter for me. From Anthropic's Fable 5 docs, on setting max_tokens:
it is a hard limit on total output, thinking plus response text.
Thinking is output. On Fable 5 the thinking process is billed as output tokens — usage.output_tokens is "the inclusive, authoritative total used for billing," and it includes reasoning you never see. And you can't turn thinking off: adaptive thinking is always on, thinking: {type: "disabled"} is rejected, and effort is what controls thinking depth. Put those together and effort stops being a quality slider. It's the throttle on how many of the most expensive tokens the model spends before answering.
The price is why that matters. Fable 5 is $10 per million input tokens and $50 per million output — output is 5x input, and thinking lands entirely on the output side. So the effort level you pick is, directly, the dial on the pricier half of the bill. Note it's not a price multiplier: the rate is $10/$50 at every level. What changes is token volume. max costs more because the model spends more of them, not more per token.
Two things from the effort docs surprised me. First, high is the default: "Setting effort to "high" produces exactly the same behavior as omitting the effort parameter entirely." If you never set it, you're on high. Second, effort is "a behavioral signal, not a strict token budget" — it shapes all tokens, not just reasoning. With tools, lower effort makes fewer tool calls and skips the preamble; higher effort explains the plan first and writes fuller summaries. It's a disposition, not a cap.
Anthropic's Fable 5 guidance: "Start with high, the default, for most tasks," reach for xhigh on "the most capability-sensitive workloads," and "step down to medium or low for routine work." The line that makes stepping down easy: "Lower effort settings on Claude Fable 5 still perform well and often exceed xhigh performance on prior models."
Measure the cost yourself
I wanted to hand you a table — low costs X, high costs 3X — and I can't, because there are no published per-effort-level token multipliers for Fable 5. I looked. Repeating a hypothetical as fact is exactly the invented number this blog won't print.
But there's something better than a table: a field that lets you build your own on your own workload. The response now breaks out billed reasoning:
{
"usage": {
"input_tokens": 25,
"output_tokens": 348,
"output_tokens_details": {
"thinking_tokens": 312
}
}
}
Per the docs, usage.output_tokens_details.thinking_tokens "reflects the raw reasoning the model generated (not the summarized text returned in the body) and is always less than or equal to output_tokens. Subtract it from output_tokens to approximate the non-reasoning portion." Send your real prompt five times at low/medium/high/xhigh/max, read that field each time, and you have the actual cost curve for your task — no one else's benchmark required.
One knob that isn't cost: thinking.display. It defaults to "omitted" on Fable 5, and the docs are blunt — "You're still charged for the full thinking tokens. Omitting reduces latency, not cost." Display changes what you see; effort changes what you pay. Don't confuse them.
So the model I'm walking away with: treat effort as the price-and-latency dial for the whole model, start at the default high, and step down for routine work rather than reflexively reaching up. The token you don't spend on thinking is the cheapest optimization there is — and now there's a field to prove it.