Research

Fable 5.2 vs Fable 5.1: Coding Benchmark Results

Fable 5.2 pass@1 score lands at 71% compared to Fable 5.1 score of 53% on a set of 26 frontier coding tasks. The mid-run terminal failures that appeared in the analysis of Fable 5.1 nearly disappear when examining Fable 5.2. The challenges that remain are concentrated in planning and reasoning.

In a previous evaluation of Fable 5.1, the model was fast and token-efficient on the runs it completed, but it lost many attempts to terminal failures such as fragile large-file writes, malformed outputs, and failed tool calls, often with the work close to correct when the run died.

To measure how Fable 5.2 compares, it was run through the same expert-created frontier task set, with 30 tasks, five attempts per task, and 150 trials per model. To do a fair comparison, the two models were evaluated on a matched set of tasks, where both models had at least three clean rollouts. This ensured that every task in the comparison carried enough valid attempts from each model to support a side-by-side comparison.

That requirement was met for 26 of the 30 tasks. Across those 26 tasks, the comparison covered 106 trials from Fable 5.1 and 121 from Fable 5.2. The values reported within this analysis are computed from those matched trials.

Figure 1Headline results on the matched set of 26 tasks; trials lost to environment or endpoint errors are excluded.
Matched set (26 tasks)Fable 5.1Fable 5.2Change
pass@153.1%71.4%+18.3 pts
pass@368.8%80.4%+11.6 pts
Trial-level pass rate54.7%58 of 106 trials70.2%85 of 121 trials+15.5 pts
Tasks solved at least once69%18 of 26 tasks81%21 of 26 tasks+3 tasks

Results on the matched set

Fable 5.2 leads on every measure in the analysis. It solved 71.4% of tasks on a single attempt, 18 points above Fable 5.1, and held a smaller but clear lead when each model was given three attempts per task. The task-level results showed the source of that gap. Both models solved 16 of the 26 tasks at least once, Fable 5.2 alone solved another 5, Fable 5.1 alone solved 2, and 3 went unsolved by both. The five tasks Fable 5.2 newly cleared were not near-misses for its predecessor. Fable 5.1 passed zero attempts on all five, and Fable 5.2 passed two of them on every attempt.

The pass rates also understate one of the clearest changes, which was reliability. Fable 5.1 passed every trial on only 6 of the 26 matched tasks. Even on tasks it usually solved, it tended to lose at least one attempt to a mid-run failure. Fable 5.2 passed every trial on 15 of the 26. A model that passes a task on some rollouts and loses others forces the user to run it several times and hope for a better outcome. When Fable 5.2 was able to solve a task, it usually did so on a single attempt.

Figure 2Tasks each model passed on every clean trial, on some trials, or on none, across the 26 matched tasks.
Fable 5.1
6 tasks
12 tasks
8 tasks
Fable 5.2
15 tasks
6 tasks
5 tasks
Passed every trialPassed some trialsPassed none

Where Fable 5.2 performed well

Beyond the pass rates, every trial was also reviewed for the skills it demonstrated, with each skill rated on quality. Verification stood out as Fable 5.2’s most frequent and highest-rated skill, with 302 recorded instances and 71% of them rated as strong. This shows that the model checked its own work without being prompted. Across the run, it built adversarial test fixtures with malformed inputs and corrupted archives, hand-counted expected results before comparing them against its output, and reran finished steps to confirm the results were identical. This is a clear change from Fable 5.1, where the analysis showed the model claiming verification steps it had never actually run.

Fable 5.2 also recovered well from its own mistakes. The reviews recorded 90 recovery episodes across the run, and the model recovered successfully in 77 of them (86%). Most recoveries were quick. The median recovery took a single step, and 62 of the 77 were resolved within two steps. A failed command often started a run-ending cascade for Fable 5.1. For Fable 5.2, a failed command was usually corrected on the next step.

Execution quality held up even in failing trials. Across those trials, 96% of the 295 skill ratings were adequate or strong, and only 10 were rated weak. The failing runs rarely stumbled on execution. More often they carried out a flawed plan competently, which matches the failure profile seen throughout the evaluation of the model.

Two failure signatures

Figure 3Share of each model’s own failing runs attributed to each root cause, grouped into mechanical and planning-and-reasoning causes.
Fable 5.1
Fable 5.2
Mechanical
Premature termination
42%
0%
Wrong output format
25%
0%
Wrong tool arguments
26%
3%
Planning & reasoning
Wrong strategy
3%
35%
Faulty inference
18%
28%
Misunderstood task
9%
23%
Fable 5.1 shares are of its 97 failing trajectories, which can carry more than one root cause. Fable 5.2 shares are of its 40 root-caused trials, one cause each. Environment failures excluded from both.

Fable 5.1’s failures were mechanical. Premature termination was the most frequent root cause. In the typical case, the model had written most of a correct solution, attempted a large file write through the terminal, corrupted the session, and could not recover the state it had built. The wrong-format and wrong-argument failures had the same character. The solution existed, and the step that delivered it failed.

Little of that profile was seen in the Fable 5.2 run. Across the set of trials there were no premature terminations, no format failures, and only a single wrong-arguments trace. The failures that remained were in planning and reasoning, led by wrong strategy (35% of its root-caused trials), faulty inference (28%), and misreading the task (23%).

These Fable 5.2 challenges were repeatable rather than random. The faulty-inference failures concentrated on two tasks, where every attempt independently reached the same wrong conclusion about the expected behavior. This suggested a stable misreading rather than sampling variance. These failures indicate that the model succeeds in executing its plan but that it may sometimes choose the wrong plan.

Where Fable 5.2 gave ground

The gains were not uniform. Two tasks that Fable 5.1 passed reliably now fail on every attempt, and a third fell from five of five to two of five. The traces show strategic causes rather than mechanical ones. In one task, every failing attempt commits to the same faulty inference about the expected behavior and then verifies its work against that incorrect reading, so its own checks pass while the verifier’s fail. In another, the model misreads what the task asks and plans against that reading from the first step. These regressions match the failure profile that reveal the model’s ceiling. A stable misreading fails five of five attempts the same way the previous terminal crashes did, and extra sampling does not recover it.

The takeaway

Fable 5.1’s weak spots were mechanical and last-mile. Work was substantially complete and then lost to the terminal, to an unparsed output, or to a check that was asserted rather than run. The Fable 5.2 run shows that gap largely closed. Terminal-interaction failures are near zero, timeouts preserve work, and 15 of the 26 matched tasks pass on every clean trial.

The remaining failures sit in strategy and task understanding, the same class that defined Opus 5 on this task set. That class is harder to fix with scaffolding, because the failing runs execute cleanly and verify against their own misreading. Whether the pattern holds across future generations remains untested. On this task set, the mechanical failures receded and the reasoning failures remained.

Share this article

Jonathan Schlosser is an AI Advocate at Snorkel.ai. He has previously worked as an AI Engineer, an Educator, and Founder. He has taught graduate-level AI and Data Science courses at UNC Chapel Hill for the last few years, and has taught hundreds of data science professionals through programs with Correlation One, Amazon, Google, and others. With 10+ years across the data and AI spectrum, from data science roles to building AI-driven applications, he writes about deep learning, LLMs, and AI agents with a direct and simplified instructional approach.

ankit-aich
Ankit Aich
Senior Research Scientist

Ankit Aich is a senior research scientist at Snorkel AI. He focuses on frontier model benchmarking, data curation, failure point analysis, and research.

He finished his PhD and MS in computer science from UIC-CS. His research aims to improve patient health outcomes by working towards collaborative-AI technology. He has worked at multiple places including the National Institutes of Health, the University of Pennsylvania, Scale AI, and FINRA. Language modeling stands as a cornerstone of my work, serving as a powerful tool to decode and comprehend the complexities of our world. He believes language offers a unique lens through which we can observe and understand our surroundings.

Recommended articles

View all articles
Image
Terminal-Bench 4.1 hardens the verifiers behind the scores
Terminal-Bench 4.1 is now available. Snorkel AI contributes to Terminal-Bench as a task author, a data partner, and a supporter through the Open Benchmarks Grants program. The release keeps the same 66 tasks, with verifier fixes, reproducibility improvements, hardening against reward hacking, and a new 63-task CPU-only dataset. Terminal-Bench and real terminal work Terminal-Bench measures whether an AI agent can
November 9, 2026
•
Jonathan Schlosser
Snorkel AI Reading Group, San Francisco: Intelligence per Watt with speakers Jon Saad-Falcon and Avanika Narayan
Intelligence per Watt: Measuring Local AI Efficiency
Jon Saad-Falcon and Avanika Narayan (Stanford, Hazy Research) present Intelligence per Watt, a metric that divides task accuracy by power draw to compare local AI models and hardware, and show it improved 5.3x from 2023 to 2025.
November 5, 2026
•
Snorkel Team
Simplified diagram of the Ping or Peek experiment: a coding agent can ask the simulated user which CSV to update, or read the scorer.py grader in the workspace and edit the file it names.
Ping or Peek: When agents prefer to peek at rewards over asking users for help
The field of AI continues to suffer from two ongoing trends that we demonstrate here may be directly linked: (1) agents do not consistently ask users for clarification when tasks are ambiguous, and (2) agents sometimes inspect accessible reward-function code to infer the answer expected by a benchmark. Our hypothesis: pressure towards autonomous task completion incentivizes agents to bypass users
November 5, 2026
•
Chris Glaze
,
Bhavishya Pohani
Image

Join our newsletter

For expert advice, the latest research, and exclusive events.
By submitting this form, I acknowledge I will receive email updates from Snorkel AI, and I agree to the Terms of Use and acknowledge that my information will be used in accordance with the Privacy Policy.