Claude Fable 5.2 vs Opus 5.5: Coding and Agent Tasks

On these four small coding and tool tasks, the Fable 5.2 premium is not worth paying: Claude Fable 5.2 and Claude Opus 5.5 both passed all 29 code checks, while Opus's standard-rate estimate was $0.031 for the set against $0.146 for Fable. Consider Fable for harder reasoning or long agent runs after Opus at higher effort falls short.

Fable 5.2 vs Opus 5.5 at a glance

Fable 5.2 is newer, but both models share the same 1M-token context and 128K-token output. The practical difference on this test was token use rather than code correctness.

Anthropic's Fable 5.2 model page and Opus 5.5 model page list both as active, with text and image input. Fable shipped on November 9, 2026; Opus shipped on September 22, 2026. Their default effort levels differ, so set medium on both when you compare them.

Anthropic's models overview recommends Opus 5.5 for most tasks. It positions Fable 5.2 for demanding reasoning and long-horizon agent work, or for cases where higher-effort Opus 5.5 evals still fall short. That is vendor positioning; this test covers four small tasks.

For release changes, see what changed in Fable 5.2. For a single-model write-up, see the Opus 5.5 review.

What the four tasks cost

Anthropic's official pricing page lists $8 input and $40 output per million tokens for Fable 5.2, against $4 and $20 for Opus 5.5 (checked November 12, 2026). Batch halves both pairs; fast mode doubles them.

Across the four scored tasks, Fable used 3,439 input and 2,954 output tokens. Opus used 2,421 and 1,065. At standard rates, that works out to:

• Fable: (3,439 × $8 + 2,954 × $40) ÷ 1,000,000 = $0.1457
• Opus: (2,421 × $4 + 1,065 × $20) ÷ 1,000,000 = $0.0310

These are standard-rate estimates from observed tokens, not invoices or OmniaKey charges. Opus's response reported fast speed, while Fable's reported standard; Anthropic lists fast input and output at double the standard rates. We normalize both to standard rates here, so the figures are not a controlled timing or billing comparison.

Standard-rate estimates in USD:

Averaged over the four tested tasks, Fable was $0.0364 and Opus $0.0077; Fable's standard-rate estimate was $0.1147 higher across the set. The practical rule is cost per usable task: API spend plus retry and review time. Move up when failed real cases justify that extra spend; these four small tasks do not.

Wall-clock totals were 27.8 s for Fable and 43.6 s for Opus. Fable's responses reported standard speed, Opus's reported fast, and we set neither; read these as observations rather than a speed ranking.

Two Python fixes: 22/22 checks on both

Both fixes are short, and both models returned working functions. The failures are worth reusing because they test revision handling and pagination edge cases rather than library knowledge.

Usage totals: a newer failure must erase an older success

The old function summed every complete event. It ignored revision and status, so a retry double-counted tokens and a newer failed revision could not cancel an older complete one.

The prompt's core rule:

Keep only the highest revision for each event_id, and on equal revisions keep the last occurrence in the input. A newer failed revision supersedes an older complete one and contributes nothing.

The smallest reproduction is event x at revision 1, complete, 10 tokens, followed by x at revision 2, failed, 10 tokens. The right total is nothing; the old function returns 10.

Both models kept the highest revision, used input order for equal revisions, skipped failed winners, kept zero-token users, and left the input unchanged. Result: 8/8 checks each, with equivalent functions.

Cursor pagination: ties must neither repeat nor skip

The old version sorted only by ts, sliced the first page before applying the cursor, accepted equal timestamps with <=, never validated limit, and always returned a next cursor. With two rows at ts=4, that repeats or skips an ID.

The prompt's core rules:

Sort descending by (ts,id). Select rows strictly LESS than the cursor tuple, so tied timestamps neither repeat nor skip IDs. Return next_cursor only if MORE eligible rows remain. Raise ValueError unless limit is an integer from 1 through 100; bool is invalid.

Both fixed all of it: tuple sort, strict less-than, filtering the full list before the slice, a next cursor only when rows remain, and validation that rejects True, False, 0, 101, 1.5, '2' and None. Result: 14/14 checks each, including a one-row walk over tied timestamps.

The async ledger: same numbers, different JSON

Both models got the reconciliation right: $0.93 net reserved, t3 pending, t1 and t5 completed, and poll_existing for t3.

The supplied synthetic fixture uses illustrative amounts, not OmniaKey prices. Its key lines:

POST key=a => 201 task=t1 quote=0.40

POST key=a, identical body => 200 task=t1

GET t1 => SUCCEEDED

POST key=b => 201 task=t2 quote=0.40

GET t2 => FAILED

POST key=c => 201 task=t3 quote=0.13

Client stopped polling t3 after 120 seconds; last status PROCESSING

POST key=d => 201 task=t4 quote=0.13

GET t4 => CANCELED

POST key=e => 201 task=t5 quote=0.40

GET t5 => SUCCEEDED

The arithmetic is 0.40 + 0.13 + 0.40 = 0.93. t2 and t4 refund; t1 and t5 consume; t3 keeps its reserve because the client stopped polling, not because the task failed.

With only last-observed SUCCEEDED tasks counted, both returned the same values. Fable returned raw JSON. Opus wrapped the JSON in a JSON code fence. The prompt said "Return ONLY JSON", so a strict json.loads on Opus's reply fails until the fence is stripped. That is a prompt-only format miss: the request asked for plain JSON text, without a JSON schema or structured-output mode. Result: values pass in both; for automation, validate the raw reply with a strict parser or use structured output. This was one observed miss, not a general pattern.

The two-turn file task: one read, one patch

The fixture's old remaining_quota subtracted every event's units. It ignored the last state for each id and the max(0, ...) clamp, so failed or canceled tasks still consumed quota, and repeated events double-charged.

The task:

Use read_file once to inspect quota.py, then return one Python code block containing only a corrected remaining_quota(limit, events) function.

Both models made exactly one read_file call for quota.py. After the fixture came back, both returned the same patch logic: keep the last event per id, sum units only for reserved or succeeded, and return max(0, limit - consumed). Result: 7/7 checks each, including failed-then-reserved and over-limit cases.

This is two turns and one fixture. It shows the models ask for the right file and patch it; it does not cover a long agent run.

How we tested

On November 12, 2026 we sent four tasks to claude-fable-5-2 and claude-opus-5-5 through OmniaKey's Messages endpoint. Each model/task pair used a fresh conversation and a cold cache, with effort medium, max_tokens 4096 per request, no system prompt, no temperature or top_p, and one trial. We alternated which model went first by task.

The agent task used one strict read_file tool with tool_choice: auto; everything else was a single user message. The grader AST-screened each Python answer, then ran it in an isolated process with a 3-second timeout against 8 usage, 14 cursor and 7 agent cases: 29 code cases per model. Every request ran once.

The first ledger prompt left open whether FAILED/CANCELED tasks belong in completed_task_ids. We replaced that ambiguous round with one clarified rerun per model, counting only last-observed SUCCEEDED tasks; the original outputs are excluded from the scored four-task totals.

All 12 requests returned HTTP 200 with the requested model ID and ended at end_turn, or tool_use then end_turn, with no truncation. Both reported service tier standard. Fable reported speed standard and separate thinking-token counts; Opus reported speed fast and omitted the thinking-token field. We left speed unset, and output tokens already include billed thinking, so the missing Opus field says nothing about zero thinking.

The same effort string is a setting, not a matched compute budget. This run holds effort at medium; for your own work, sweep the effort levels your task needs. This is a small fixture test, not a full repository or long-running agent benchmark. It does not predict pass rates on other tasks. OmniaKey sells access to both models; the prices above are Anthropic's official list prices.

When to evaluate Fable

Start with Opus 5.5 for short, well-specified work. It matched Fable on all 29 code checks, and Fable's standard-rate estimate was 4.7 times Opus's.

Treat Fable 5.2 as the next candidate for demanding reasoning or long tool loops after higher-effort Opus fails your own real cases. That is Anthropic's positioning; this run covers only the four small tasks. Test 10–20 real failures before switching.

Anthropic's Fable 5.2 launch post adds a vendor-reported data point: Fable 5.2 at High scored 45.3% on FrontierCode 2.0 against 45.5% for Opus 5.5 at Max, at roughly half the cost per task. The post also says Fable 5.2 at Xhigh reached 49.1%, the highest score of any released model tested. That pairs Fable High with Opus Max, a different comparison from our same-medium test.

For a real project, compare API spend with retry and review time per usable task. On small, already-passing work, Opus is the cheaper default.

To use either model in Claude Code, the Claude Code setup guide has the base URL and key settings. Model pages: Claude Fable 5.2 and Claude Opus 5.5.

Frequently asked questions

Is Fable 5.2 worth the price over Opus 5.5?

Consider Fable after higher-effort Opus fails your own cases, then verify Fable improves them; this run gives no hard-task verdict. On our four small tasks both passed 29/29 code checks; Fable's standard-rate estimate was $0.1457 against $0.0310 for Opus.

Did Fable 5.2 and Opus 5.5 pass the same coding tests?

Yes. Both passed 8/8 usage cases, 14/14 cursor cases and 7/7 file-patch cases. The ledger answer was also correct in both, with one formatting difference: Opus added a JSON code fence.

Which is cheaper for coding, Fable 5.2 or Opus 5.5?

At Anthropic's standard list prices, Opus 5.5: $4 input and $20 output per million tokens against $8 and $40. Our tokens put Fable's standard-rate estimate at 4.7 times Opus's: $0.1457 versus $0.0310 across four tasks.

Is Fable 5.2 faster than Opus 5.5?

Our run leaves that open. The observed totals were 27.8 s for Fable and 43.6 s for Opus, but Fable's responses reported standard speed and Opus's fast, and we left speed unset. Compare them again with the same speed setting.

Can I use both models in Claude Code through OmniaKey?

Yes. We called both model IDs through OmniaKey in this run, and the Claude Code setup guide shows the base URL and key. Check the model name in your client after you connect.

Sources checked

• Anthropic: Claude Fable 5.2 model overview
• Anthropic: Introducing Claude Fable 5.2 and Mythos 5.2
• Anthropic: Claude Opus 5.5 model overview
• Anthropic: Models overview
• Anthropic: Pricing

All checked November 12, 2026.