How Claude Fable 5.2 thinks

Claude Fable 5.2 solved all 115 of its VulcanBench Frontier v4 runs: 23 tasks at each of five effort levels. This report is about how. Its traces show a model that goes straight to the machine code, reads it, thinks once at length and writes a rewrite, then checks that rewrite against the original program. Turning up the effort setting barely changes what it ships. It changes how hard Fable 5.2 works to prove the rewrite is right.

The task in one paragraph

Each Frontier v4 task hands the model a small repository: a module that is supposed to reproduce a retired program, a written specification, and the retired program itself as compiled binaries for macOS and Linux. The module is wrong in ways the issue only hints at, and the specification may have drifted from what the program really does. Hidden tests compare the repaired module with the binary, byte for byte, on inputs the model never sees. The binary is the ground truth; everything else is a claim about it. (Methodology has the full design.)

Anatomy of a solve

Every Fable 5.2 run follows the same arc. The phases stretch or shrink with effort, but they come in this order at every level:

1. SurveyOne or a few commands that list the repository and print the specification, the module and the file types.
2. Read the machine codeStrings, symbols, then a full disassembly of the reference, read end to end. Median: its 2nd tool call at Low, its 7th at Max.
3. ThinkA long burst of reasoning that turns the disassembly into a model of the program. At Low this one burst holds 62% of a run's thinking.
4. RewriteThe module is rewritten from that model: by a script run in the shell at Low and Medium, with the Edit and Write tools at Max.
5. Check against the referenceGenerated inputs go to both the binary and the rewrite, and the outputs are compared byte for byte. Mismatches are shrunk and fixed.
6. Clean upScratch files stay outside the repository; the final diff is the module alone in all 115 runs.

The chart below lays one task, blendcore, end to end at each level. At Max, blendcore took Fable 5.2 40.2 minutes, close to its median Max solve time of 39.0. Each tick is a tool call, coloured by what it did; each bar above the line is the thinking that came before it.

Reading code and binaryProbing the binaryEditing the moduleTestingWrap-up

Ticks: tool calls, coloured by activity. Bars above the line: thinking tokens spent before that call (height is the square root, so small bursts stay visible). The short bar under each label is the run's wall-clock length, on one scale for all six runs.

At Low and Medium the whole run is a handful of calls with one tall bar in the middle: read, think, write, check. High adds a little probing and checking; from Extra-high the right half of each run fills with testing, and at Max the thinking breaks into dozens of smaller bursts spread across the checking work. The last row is Claude Opus 5.5 on the same task at Low, for contrast; more on that below.

Walkthrough: four minutes at Low

Blendcore at Low took Fable 5.2 4.3 minutes, 9 tool calls and about 7,700 thinking tokens. The run, step by step, with times from the start:

• 0.0 min · surveyOne command lists the repository and prints the specification, the module and the types of the two binaries.
• 0.1 min · read the binaryIt reads the legacy notes and dumps the binary's strings and symbol table. Its first thinking summary frames the job as reverse engineering a black box, with disassembly as the most reliable route.
• 0.2 to 0.5 min · read the binaryIt disassembles the whole macOS build and reads the listing in two passes.
• 0.5 to 1.8 min · think, then rewriteThe run's longest stretch of thinking, more than half of all its thinking, comes here, and ends in a single script that rewrites the module.
• 2.1 to 2.4 min · checkIt writes a differential fuzzer (random command streams sent to the binary and to the rewrite, outputs compared byte for byte) and a second script that shrinks any failing stream to a minimal case.
• 4.0 min · fixOne small correction to the module, then a final fuzz with thousands of random streams and no mismatches. Done.

This is Fable 5.2's Low pattern across all 23 tasks: a mean of 10.7 tool calls, about 2 edits and 3 test runs, with the first edit at a median of 2.2 minutes, 60% of the way through the run. The single biggest burst of thinking follows a binary inspection in 21 of 23 runs and comes right before the rewrite in 17.

Walkthrough: forty minutes at Max

The same task at Max took 40.2 minutes, 56 tool calls, 62 thinking summaries and about 96,000 thinking tokens, twelve times the Low run. The rewrite it shipped is about the same size. Here is where the extra work went:

• 0.0 to 0.4 min · surveyA wider survey than at Low: the file tree, the commit history, five files read in full, the issue, the ignore rules, and checks of which tools and Python version the machine has.
• 0.5 min · set upIt copies the binary into a scratch directory outside the repository, so the repository's file modes stay untouched, and runs a smoke test.
• 0.6 to 0.9 min · read the binaryStrings, symbols and section sizes, then a full disassembly saved to the scratch directory and read in three passes.
• 0.9 to 9.7 min · think, then probeAbout six minutes of thinking before the next tool call, including its longest summary of the run (about 20,000 characters, reconstructing the program's logic as pseudo-code). Then hand-built probes to confirm that model, one mismatch it traces to its own shell quoting rather than to the program, and a check of how the old module and the binary each treat unusual bytes.
• 10.4 min · rewriteIt writes the new module in one go with the Write tool.
• 11 to 25 min · check, and check the checksA differential harness in scratch space; a mutation tester that plants bugs in copies of the module to see whether the harness notices; a corpus of hand-picked edge cases; tens of thousands of random streams. Then it builds a throwaway Linux container to run the Linux build of the reference, so three implementations are compared at once.
• 28 to 30 min · auditIt lists every constant in the disassembly and matches each one to the module, reviews the module for readability, and tests the module's programmatic interface as well as its command line.
• 30 to 37 min · widenIt finds a second Python version on the machine and runs the full check under it too.
• 37 to 40 min · clean up and finishIt removes the container and its image, confirms the diff touches only the module, compares throughput with the reference, and reports.

Most of the forty minutes went into checking a rewrite it had finished at minute ten. That is the Max pattern across all 23 tasks: the first edit lands a median 30% of the way in, against 60% at Low, and nearly half of all thinking comes before test runs.

Where the extra thinking goes

Fable 5.2's output per task grows 8.7 times from Low to Max and its time 8 times, while thinking grows from 48% of output to 67%. To see what that thinking is for, each burst is credited to the action that followed it: reading, probing the binary by hand, editing the module, testing, or wrapping up.

Reading code and binaryProbing the binaryEditing the moduleTestingWrap-up

At Low and Medium, 44% of Fable 5.2's thinking leads straight into an edit: it reasons its way to the whole rewrite before writing any of it. At Max that share falls to 19% and testing takes 46%. The total also grows twelvefold, so Max still spends about 18,000 thinking tokens a task on edits, more than an entire Low run, but the new effort goes overwhelmingly to verification. Extra-high is a halfway house where probing the binary by hand peaks at 27%.

The thinking also changes shape. A Low run has a mean of 9 thinking summaries and its single biggest burst holds 62% of the run's thinking. A Max run has 58, and the biggest burst holds 25%. Over the wall clock, Max front-loads: 40% of its thinking falls in the 10 to 30% slice of the run, where it reads the disassembly and builds its model, and the rest is spread thinly across the checking.

Claude Fable 5.2: share of each level's thinking in each tenth of the run

The checking itself gets more sophisticated, not just longer. Counted from the commands each run actually executed: mutation testing plants deliberate bugs in copies of the module to see whether its checks catch them; the Linux build in a container runs the reference's second binary so the rewrite is compared with both builds; a throughput check times the rewrite against the reference; a second Python version reruns the checks under another interpreter.

Opus 5.5 counts use its runs without refusal fallback, so n varies; see methods.

Its thinking summaries show the same widening. Keyword counts over the summaries (rough, from the results analysis) find differential checking against the binary in every run at every level, while other themes climb with effort. Doubt about the written specification appears in 3 Low runs and 22 Max runs. Explicitly keeping the change minimal: 4 to 23. Forming and testing named hypotheses: 11 to 23. Cleaning up scratch files: 2 to 23. At higher effort it is not only checking more; it is more suspicious of the specification and more deliberate about the size of its change.

All of Fable 5.2's per-level means in one place:

Against GPT-6 Astra

GPT-6 Astra, in OpenAI's Codex, came closest to a clean sweep of Frontier v4 before Fable 5.2, solving 114 of its 115 runs. Its raw Codex streams did not survive a host reset in September, so it cannot be compared call by call. What survives for every model is the same pair of records: the run's token and time receipts, and the patch it left. Those already show two very different ways of working.

Claude Fable 5.2Claude Opus 5.5Claude Fable 5.1GPT-6 Astra

The difference that stands out is where each model puts its checking. None of the task statements asks for tests. Astra writes a regression test file anyway, in all 115 runs, and as effort rises the file doubles in length while the module change hardly moves. Fable 5.2 runs its checks in scratch space and leaves nothing behind but the module. With more effort, Astra leaves more tests in the repository; Fable 5.2 runs more checks and thinks more, and leaves no trace of either in the diff.

Claude Fable 5.2Claude Opus 5.5Claude Fable 5.1GPT-6 Astra

Runs whose patch adds a test file, of 23 at each level

At Low the two are close on the wall clock (4.6 against 4.2 minutes), so Fable 5.2's extra thinking costs little time there. The gap opens with effort: at Max Fable 5.2 runs 3.6 times as long. Which habit is better depends on what you want from a patch. A committed test file documents the behaviour and guards it later; a module-only diff is smaller to review. Muse Spark 1.3, the one judge that reviewed both models, rates Fable 5.2's code 6.6 to 9.0 points higher than Astra's at every level, but that verdict covers the whole patch, not the test habit alone (see methods).

Module only: runs whose patch changes exactly one file. Module and test lines: median lines added to non-test and test files. Comment share counts comment lines among lines added to non-test files. Fable 5.1's and Astra's figures come from the frozen v3.4 Code quality population, Opus 5.5's from v3.15 (22 High runs) and Fable 5.2's from v3.30 and v3.30.1, all parsed the same way.

Against Claude Opus 5.5

Opus 5.5 ran in the same harness, Claude Code, and its full streams survive in the private backup, so it can be compared call by call. (Opus 5.5's thinking was not recorded as text, only as token counts, which is all this comparison needs.) The sharpest difference is at Low.

At Low, Opus 5.5 often treats the program as a black box: it feeds it inputs, compares outputs with the module, edits, and repeats, building its picture of the program by trial. Hedgecore shows the difference at its widest. Opus 5.5 never disassembled the binary, and took 30.1 minutes and 53 tool calls, with 11 edits and 24 test runs, to solve it. Fable 5.2 inspected the binary at its second call, spent 79% of its thinking in one burst, made one edit and one check, and was done in 3.3 minutes.

The black-box route also failed more often. At Low, Opus 5.5 solved 11 of the 12 runs in which it inspected the binary before editing, and 6 of the 11 in which it edited first. With samples this small that is a pattern worth noting, not proof that the order caused the outcome; harder tasks may invite both the guessing and the failure.

From Medium up, Opus 5.5 inspects the binary first almost every time, and by Max the two models look alike on the surface: about 37 minutes and 50 to 60 tool calls a task, with more than a third of thinking going to testing for both. The difference left is in the checking. At Max Fable 5.2 mutation-tested its checks in 21 of 23 runs and ran the Linux build in a container in 19; in Opus 5.5's 11 Max runs without fallback the counts were 4 and 0. Opus 5.5 also keeps more of its thinking on reading: 37% at Max, against Fable 5.2's 22%.

Opus 5.5 tokens come from its runs without refusal fallback (n: Low 23, Medium 20, High 15, Extra-high 15, Max 11); its minutes, like every other model's, cover all published runs (22 at High). Fable 5.1 left no thinking count.

Against Claude Fable 5.1

Fable 5.1's raw streams were lost in the same September host reset, and it was not rerun, so it is compared through receipts and patches only. Two things changed between versions.

The effort dial works now. Fable 5.1's output barely moved with effort, from 86k tokens a task at Low to 101k at Max with a peak of 145k at Extra-high, and it spent 27 to 39 minutes a task at every level. Fable 5.2 uses 19% of that output at Low, at 17% of the time, and solves 23 tasks to Fable 5.1's 19. Its output then scales 8.7 times by Max.

The patch stopped growing. Fable 5.1's median patch grew from 112 to 190 lines with effort, it committed test files in 5 to 11 runs per level, and a few patches ran to thousands of lines (13,978 at most). Fable 5.2's patch stays at about 100 lines and one file at every level. Fable 5.1's refusal fallback also answered part of 11 runs, and 6 of those failed; Fable 5.2 never needed it, although every one of its runs disassembled the binary.

What it adds up to

1. It starts from the ground truth. In all 115 runs Fable 5.2 inspected the binary before its first edit, usually by its second tool call. It does not guess at the program's behaviour from the specification and refine by trial; it reads the program.
2. At low effort it thinks once and well. A Low run is one long burst of reasoning between reading the disassembly and writing the rewrite, then a short differential check. That is enough to solve every task, in under five minutes on average.
3. Effort buys proof, not a different answer. From Low to Max the patch stays one file of about 100 lines. The extra twelvefold thinking goes into checking: differential fuzzing at scale, mutation testing of the checks themselves, the second build of the reference, other interpreter versions and throughput.
4. It keeps its scaffolding out of the diff. Unlike GPT-6 Astra, which commits a growing regression test file, and Fable 5.1, which sometimes committed tests and huge patches, Fable 5.2 leaves only the module behind.

Methods and caveats

Runs. Claude Fable 5.2 (claude-fable-5-2) in Claude Code 2.1.321, November 9 to 11, 2026, run with summarized thinking display; the published results and judging are in the Fable 5.2 results. Claude Opus 5.5 in Claude Code 2.1.280, GPT-6 Astra in Codex CLI 0.153.4 and Claude Fable 5.1 in Claude Code 2.1.259 to 2.1.261, all in September 2026. One run per task per level for every model.

Sources. Fable 5.2's 115 raw streams and tool-call logs; Opus 5.5's raw streams, restored from the private backup; and, for all four models, the run receipts and candidate patches frozen in the Code quality populations (v3.4 for Fable 5.1 and Astra, v3.15 for Opus 5.5, v3.30 and v3.30.1 for Fable 5.2). Astra's and Fable 5.1's raw streams did not survive the September host reset, so neither has a tool-call or timing comparison here; in particular we cannot say when Astra first looked at the binary.

Activities. Each tool call is put in one class by rules over its tool name, command and file paths: reading the repository or the binary, running the binary by hand, building a harness, testing, editing the module, and review. Commands that do two things get one label. In a hand check of 40 randomly chosen calls, about 33 were clearly labelled right; most misses were scripts run without a recognisable name, since fixed, and mixed commands. Treat the shares as approximate. Binary inspection before the first edit agrees with the stricter check in the results analysis (115 of 115).

Thinking. Claude Code streams a running estimate of thinking tokens. Estimates between two tool calls are credited to the second call's class, then scaled so each run's total matches its billed thinking tokens (the raw estimates run at about 70% of the billed figure). Thinking summaries are summaries, not the raw reasoning, and their counts and lengths are counted only as structure. Theme counts are keyword matches from the results analysis and are rough.

Opus 5.5 fallback. Claude Code's refusal fallback answered part of 30 Opus 5.5 runs (0, 3, 7, 8 and 12 from Low to Max). Those streams mix two models, so every trace measure for Opus 5.5 uses only the runs it served alone: 23, 20, 15, 15 and 11. Its minutes, solve counts and patch shapes cover every published run; one High run has no record in the frozen population, so High has 22.

Harnesses differ. Claude Code and Codex count thinking differently: Claude Code reports thinking tokens per response, and Codex reports reasoning output tokens, which may not capture every token of hidden compute. Compare Astra's reasoning with Fable 5.2's thinking as an order of magnitude, not a precise ratio. The harnesses also offer different tools, so tool-call counts are not compared across them.

Scores. This report is about how the models work, not how they rank. Fable 5.2's combined score runs from 91.92 at Low to 93.85 at Max, with Code quality judged by Muse Spark 1.3 and GPT-6.1 Sol. Sol has since reviewed Fable 5.1's and Opus 5.5's frozen patches beside Muse (rounds v3.30.4 and v3.30.5), so the three Claude columns share one panel: on it Fable 5.2 leads at every level, only narrowly at Medium (0.08 ahead of Opus 5.5, inside the standard error), and its Code quality is within 1.5 points of Fable 5.1's at every level. Sol cannot judge another OpenAI model, so Astra keeps its Muse Spark 1.3 and Grok 4.6 panel, and Muse alone is the only like-for-like judge across all four; the Astra comparison above uses Muse's scores. The board keeps each model's published scores. Full tables are in the Fable 5.2 results.

Data. summary.json (every figure on this page), runs-traces.csv (one row per Claude Code run) and runs-records.csv (one row per run, all four models). They are built by scripts/build_report01_data.py from the private run records and drawn by scripts/build_report01_charts.py. Neither file contains thinking text or task content.