Claude Fable 5.1: the reasoning dial has a cliff, not a slope

Claude Fable 5.1 shipped on 1 September 2026 with five reasoning effort levels, and Simon Willison pointed all five of them at a drawing of a pelican riding a bicycle. His writeup is here. But the pelican isn't the story.

The cost table underneath it is. Same prompt, same model: $0.10 at the lowest setting, $3.30 at the highest. Thirty-three times the price for one SVG of a bird. If you pay for API calls yourself, that ratio is the whole post.

---

🔍 The five runs, side by side

These are the numbers from the writeup, one prompt, one model, five settings:

Effort	Output tokens	Wall clock	Cost
low	1,998	23.8s	$0.10
medium	1,977	23.0s	$0.10
high	2,612	29.6s	$0.13
xhigh	36,767	7m 51s	$1.83
max	65,927	13m 54s	$3.30

Read the top three rows again. Medium produced fewer output tokens than low and finished slightly faster. That's not a tuning insight, that's noise. For this prompt, low, medium and high are effectively one tier that costs between ten and thirteen cents and answers in under half a minute.

Then the floor drops out.

---

💰 The cliff sits between high and xhigh

Everyone talks about reasoning effort as a slope you slide along, trading money for quality in smooth increments. It isn't. On these numbers it's a step function with one enormous step in it:

• low → high: 1.3× the cost, 1.3× the tokens, 1.2× the time
• high → xhigh: 14× the cost, 14× the tokens, 16× the time
• xhigh → max: 1.8× the cost on top of that

So there are really two products here wearing one name. There's a cheap fast model that costs cents, and there's an expensive slow one that costs dollars, and the boundary between them is a single string in your config file.

Key takeaway: Going from low to high costs you three cents. Going from high to xhigh costs you $1.70. If you're going to be careless with one of those decisions, be careless with the first one.

The practical version: default your calls to high and treat xhigh/max as something you opt into per-task, deliberately, with a comment explaining why. Not a global setting. Not a "let's just crank it and see."

For the budgeting side of that, price it in rupees before you commit, not after the invoice lands. A hundred max-effort calls a day is a genuinely serious monthly number for a side project, and the USD figure hides how serious. Our LKR exchange rate page has today's rate if you want to do that conversion honestly rather than from the number you memorised six months ago.

---

⏱️ Max isn't a mode you can put in front of a user

The cost is the part people notice. The latency is the part that actually breaks things.

13 minutes 54 seconds. That's 834 seconds for one response. Think about where that number has to live:

Where the call runs	Typical ceiling	Does max fit?
Serverless function (common default)	10–60s	No
Long-running Node/Next server route	Minutes, if you configure it	Barely, and your user left
Background job + polling or webhook	No practical limit	Yes

Even low at 23.8 seconds is too slow for anything a person is sitting and watching without a progress indicator. xhigh at nearly eight minutes and max at nearly fourteen are not request handlers at all. They're batch jobs. If you want them in a product, you need a queue, a job table, and some way to tell the user "we'll email you," before you need better prompts.

This is the mistake I'd expect to see most often in small-team builds: someone tests max in a terminal where waiting fourteen minutes feels fine, ships it into a web route, and discovers the timeout in production.

---

🧪 The pelican has quietly stopped being a benchmark

The thing I found most useful in the post is an admission rather than a result. The author says he's lost faith in how well the pelican-on-a-bicycle test correlates with overall model quality, while noting it's still useful for comparing reasoning levels within one model family.

That's an important distinction, and it generalises:

1. Cross-model comparisons from a single cute prompt are close to worthless. Models get tuned on the famous tests, deliberately or not.
2. Same-model, same-prompt, different-knob comparisons are still valid. Everything except the knob is held constant. That's what makes the table above trustworthy.
3. Your workload is not a pelican. Whatever you're actually building, that's your benchmark.

If you're a student or a solo builder deciding which model to pay for, the cheapest useful thing you can do is write ten prompts from your real use case, run them at high and at xhigh, and look at whether the 14× spend changed any answer you cared about. That costs a couple of dollars and tells you more than any leaderboard will.

One more detail worth flagging: animating the max-effort pelican was done at high effort and cost $1.37, roughly ten times what high effort cost on the original prompt. The dial wasn't the variable there. The input was, because the thing being animated was already large. Reasoning effort is one cost lever. Context size is another, and it's the one people forget when they start piping generated output back into the next call.

---

💡 What this means for you

If you're building on LLM APIs from Sri Lanka on a learning budget, or running a small team where the API bill comes out of real revenue:

• Default to high. On this evidence it's ~30% more than low and reliably at least as good. It's the free upgrade.
• Treat xhigh and max as a separate budget line. They are a 14–33× multiplier, not a nudge. Gate them behind an explicit flag.
• Never put multi-minute effort levels on a synchronous route. Queue them, or don't offer them.
• Watch your input tokens as hard as your effort setting. Feeding a model's own long output back in is a stealth cost multiplier.
• Build a ten-prompt eval for your own task before trusting anyone's benchmark, including this one.

Bottom line: the interesting news in Fable 5.1 isn't that it can draw a pelican. It's that a single config string can move your per-request cost by 33× and your latency by 35×, and nothing in the API will warn you before it does.

Facts and figures above come from Simon Willison's post linked at the top. I haven't independently re-run the benchmark, and I'd expect the exact numbers to move between prompts.