29 How Cursor Knew Claude Fable 5 Was Ready

Originally published July 17, 2026.

29.1 The Frontier Model Evaluation Problem

When a new frontier model is released, the question every AI-powered product faces is: is it actually better? General benchmarks — MMLU, HumanEval, GSM8K — have largely saturated. When every top model scores above 90%, the benchmark can’t tell you which one will perform better on your specific, messy, real-world workload.

This is the story of how Cursor, the AI-native code editor, evaluated Claude Fable 5 — and the insights that emerged about what makes a frontier model “ready” for production.

29.2 Cursor and Frontier Models

Cursor sits at a unique vantage point in the AI ecosystem. As a code editor built entirely around AI assistance, the quality of its underlying model directly determines the quality of its product. When Anthropic releases a new frontier model, Cursor’s team needs to know: should we switch?

Nate Schmidt, the engineer at Cursor responsible for model evaluation, has developed a rigorous process for answering this question. His approach offers lessons for any team evaluating frontier models.

29.3 CursorBench: Real-World Messiness

Standard benchmarks use clean, well-defined problems. Real users don’t. They paste in error messages, describe bugs imprecisely, reference files that don’t exist yet, and ask for things that require understanding an entire codebase.

CursorBench was built to capture this messiness. It consists of real prompts harvested from actual Cursor users — anonymized, curated, and categorized by difficulty and type.

Category	Description	Example
Bug fix	User reports a bug, agent must diagnose and fix	“The login button doesn’t work on mobile”
Feature request	User describes a feature, agent implements it	“Add a dark mode toggle to settings”
Refactor	Restructure existing code	“Extract the validation logic into a separate module”
Multi-file	Changes span multiple files	“Update the API to support pagination everywhere”
Exploration	Understand existing code	“How does the authentication flow work?”
Integration	Connect to external services	“Add Stripe payment processing”
Migration	Update to new framework/version	“Migrate from Express to Fastify”

Note

The key insight behind CursorBench is that real-world prompts are messy. They contain ambiguity, missing context, and implicit assumptions that clean benchmarks don’t capture. A model that scores 95% on HumanEval might struggle with “it’s broken, fix it” — and that’s what real users actually type.

29.3.1 Fable 5 Performance on CursorBench

Model	CursorBench Score	Effort Level
Opus 4.7	61.2%	Max
Sonnet 5	54.8%	Max
Fable 5	72.9%	Max
Fable 5	67.1%	High
Fable 5	58.3%	Medium

Fable 5 at Max effort scored 72.9% — a significant jump over Opus 4.7’s 61.2%. But the raw score only tells part of the story. The more interesting findings came from analyzing how Fable 5 approached problems differently.

29.4 The Key Insight: Global vs. Local Reasoning

The most important finding from Cursor’s evaluation was the distinction between global reasoning and local reasoning.

29.4.1 Local Reasoning

Local reasoning is step-by-step, incremental problem-solving. You look at the immediate problem, determine the next step, execute it, and move on. It’s efficient and effective when the path from A to B is clear.

Most models — including Opus and Sonnet — are excellent at local reasoning. Given a clear sequence of steps, they execute them reliably.

29.4.2 Global Reasoning

Global reasoning is holistic, top-down problem-solving. Before taking any action, you understand the entire problem space, identify the goal, and plan a path that considers the full context — even parts that aren’t immediately relevant.

Fable 5 excels at global reasoning. It doesn’t just solve the immediate problem; it understands where the problem fits in the larger system and plans accordingly.

29.4.3 Why This Matters

Consider a refactoring task: “Rename the User class to Account throughout the codebase.”

Local reasoning: Find all references to User and rename them. This works but might miss nuances — comments, documentation, variable names that reference the concept rather than the class.
Global reasoning: Understand the semantic meaning of User in this codebase, distinguish between references to the class and references to the concept, update all relevant locations including documentation and comments, and verify that the change doesn’t break any implicit assumptions.

The global approach produces a better result because it understands the intent behind the change, not just the mechanical transformation.

29.5 The Moon Landing Experiment

The most striking illustration of the global vs. local reasoning difference came from what the Cursor team called the “moon landing” experiment.

The task was ambitious: “Land on the moon” — a metaphorical challenge representing a complex, multi-step engineering problem where the path to the goal is not clear at the outset.

29.5.1 Opus 4.7’s Approach

Opus attacked the problem directly. It tried to build a complete moon-landing solution in one shot — designing the architecture, writing the code, and testing it all at once.

The result: Opus worked for 12+ hours and never produced a working solution. It kept getting stuck in local optima — solutions that looked reasonable at each step but didn’t add up to a working whole. It would fix one problem, introduce another, and cycle without converging.

29.5.2 Fable 5’s Approach

Fable 5 took a fundamentally different approach. Instead of going straight for the moon landing, it started with an initial orbit mission — a simpler version of the problem that could be solved quickly and verified.

Fable 5's Plan:
1. First, achieve orbit (simpler, verifiable)
   → Build a minimal system that "orbits" the problem
   → Verify it works
2. Then, modify for landing
   → Extend the orbiting system to land
   → Verify each modification
3. Then, optimize
   → Refine the landed solution

By starting with a simpler, achievable sub-goal, Fable established a foundation. Each subsequent step built on verified progress. The result: Fable completed the task in hours, not days.

Tip

This is the essence of global reasoning: understanding where the goal is and planning a path to get there, even when the direct path is blocked. Fable didn’t try to solve the hard problem directly. It identified a simpler version of the problem that would teach it something, solved that, and then extended.

29.6 The Rule

Nate Schmidt distilled the lesson into a memorable rule:

“If you know the path from A to B, you don’t need Fable. If you don’t know where B is, Fable is excellent.”

This is the clearest articulation of when to use a frontier model:

29.6.1 When You Don’t Need Fable

The task is well-defined with a clear solution path
You know what the output should look like
The steps are sequential and each depends on the previous
Standard patterns and best practices exist

For these tasks, Opus or Sonnet are faster, cheaper, and equally effective. Fable’s global reasoning provides no advantage when the path is already clear.

29.6.2 When Fable Excels

The goal is clear but the path is unknown
Multiple valid approaches exist and you need to explore
The problem requires understanding the entire system, not just a local part
You’re doing something ambitious — a rewrite, a new architecture, a novel feature

For these tasks, Fable’s ability to plan globally, explore alternatives, and build incrementally makes it dramatically more effective.

29.7 Lowering Activation Energy for Ambitious Rewrites

One of the most consequential effects of Fable 5 at Cursor was cultural, not technical.

Before Fable, the Cursor team had a mental list of “someday” projects — major refactors and architectural improvements that everyone agreed would be valuable but were too risky and time-consuming to attempt. The activation energy required to start them was too high. What if they spent two weeks on a rewrite and it didn’t work?

With Fable, that calculus changed. Because Fable excels at ambitious, exploratory work, the cost of attempting a major rewrite dropped dramatically. Projects that were “someday” became “this sprint.”

# Before Fable: "We should rewrite the indexing system someday"
# After Fable: "Let's have Fable take a pass at rewriting the indexing system"

result = fable.generate("""
Rewrite the file indexing system to support
incremental updates. The current system re-indexes
the entire project on every change, which is slow
for large projects.

Design the new system, implement it, and ensure
backward compatibility with the existing API.
""")

Note

The cultural shift is perhaps Fable’s most important impact. When the cost of attempting ambitious work drops, teams do more ambitious work. This compounds — each successful ambitious project builds confidence and capability for the next one.

29.8 Practical Evaluation Advice

Based on Cursor’s experience, here’s how to evaluate a frontier model for your use case:

29.8.1 1. Build Your Own CursorBench

Collect 50-100 real tasks from your actual workload. Don’t use synthetic benchmarks — use the messy, ambiguous, real prompts that your users or team actually produce.

29.8.2 2. Test at Multiple Effort Levels

A model’s performance varies dramatically with effort level. Test at Low, Medium, High, and Max to understand the quality-cost-latency tradeoff.

29.8.3 3. Look at How, Not Just What

Don’t just check whether the model produced the right answer. Look at how it got there:

Did it plan before acting?
Did it verify its work?
Did it explore alternatives?
Did it recover from errors?

29.8.4 4. Test the Hard Cases

Easy cases don’t differentiate models. Focus your evaluation on the hardest 20% of your tasks — the ones where your current model struggles. That’s where a frontier model will show its value (or not).

29.8.5 5. Trust but Verify

Even when a model scores well on your eval, spot-check the results manually. Models can produce plausible-looking but subtly wrong output. Human review of a sample of results catches issues that automated grading misses.

29.9 The Broader Lesson

The Cursor-Fable story illustrates a broader truth about AI in 2026: the frontier is no longer about raw scores on standard benchmarks. It’s about qualitative differences in how models approach problems.

Fable 5 doesn’t score dramatically higher than Opus 4.7 on MMLU or HumanEval. But it approaches problems differently — with global reasoning, incremental verification, and a willingness to explore. For the tasks where that approach matters, the difference is transformative.

This is why custom evaluations are essential. The benchmark that matters is the one that reflects your actual work, with all its messiness and ambiguity. CursorBench works for Cursor. Your benchmark needs to work for you.

29.10 Implications for the Industry

The Cursor-Fable evaluation has implications beyond Cursor itself. It suggests that the AI industry is entering a phase where model differentiation is qualitative, not just quantitative.

29.10.1 What This Means for Model Developers

Benchmarks need to evolve: Standard benchmarks that have saturated are no longer useful differentiators. The industry needs harder, more realistic evaluation sets.
Reasoning patterns matter: Models that can plan globally and verify incrementally will outperform models that only excel at local step-by-step reasoning, even if benchmark scores look similar.
Evaluation is product-critical: Companies that build rigorous, custom evaluations will make better model decisions than those that rely on public benchmarks.

29.10.2 What This Means for AI-Powered Products

Test before you commit: Don’t switch models based on benchmark scores. Test on your real workload.
Look at the process, not just the output: A model that produces the same answer via a better process (planning, verifying, exploring) may be more reliable in production.
Embrace ambition: When the cost of attempting hard problems drops, the competitive advantage goes to teams that attempt them.

Note

The broader lesson of the Cursor-Fable story is that we are leaving the era where “bigger is better” was the only model selection criterion. We’re entering an era where how a model thinks matters as much as how well it scores. Understanding the difference — and building evaluations that capture it — is the new core competency for AI engineering teams.

29.11 Key Takeaways

CursorBench captures messy real-world prompts — the kind users actually write, not clean synthetic problems. Fable 5 scored 72.9% at Max effort, a significant jump over Opus 4.7’s 61.2%.
The key insight is global vs. local reasoning: most models excel at local, step-by-step problem-solving. Fable 5 excels at global, holistic planning that considers the entire problem space.
The moon landing experiment: Opus failed for 12+ hours trying to solve a complex problem directly. Fable succeeded in hours by first solving a simpler version (orbit), then extending.
The rule: “If you know the path from A→B, you don’t need Fable. If you don’t know where B is, Fable is excellent.”
Fable lowers activation energy for ambitious work — projects that were “someday” become “this sprint” when the cost of attempting them drops.
Build your own evaluation set of 50-100 real tasks, test at multiple effort levels, and look at how the model works, not just what it produces.
The frontier is no longer about benchmark scores — it’s about qualitative differences in problem-solving approach that only custom evaluations can reveal.