July 9, 2026 · Thoughts

Sol vs. Fable: Stop Asking Which Model Is Best

OpenAI has GPT-5.6 Sol. Anthropic has Claude Fable 5. Both companies describe models that can plan, use tools, write tests, and stay with difficult work longer than the previous generation.

Naturally, everyone wants one winner.

That is the wrong question.

OpenAI's own GPT-5.6 results show a mixed picture across coding evaluations, and Anthropic positions Fable 5 around ambitious, asynchronous projects. Different harnesses, reasoning settings, tools, and task sets can move the outcome. Your codebase adds another universe of variables.

Compare Jobs, Not Personalities

“Which model feels smarter?” is an entertaining conversation and a weak procurement method.

Create a small evaluation set from work you actually do:

Fix a real bug with a known cause.
Add a feature that crosses two layers.
Reproduce a design from a screenshot.
Review a pull request containing seeded issues.
Refactor a module while keeping tests green.
Investigate an unfamiliar failure and write a diagnosis.

Give both models the same repository state, instructions, tool access, time limit, and acceptance tests.

Measure the Whole Outcome

Do not score only whether the final build passed. Track:

Correctness: Did it satisfy the acceptance criteria?
Regression safety: Did unrelated behavior remain intact?
Reviewability: Is the patch focused and understandable?
Intervention: How often did a human need to redirect it?
Recovery: Did it learn from failed tests?
Cost: What was the total model spend?
Cleanup: How much human time was needed after the run?

The winning model is the one that produces the best accepted change, not the most impressive transcript.

Architecture and Execution May Need Different Models

There is no rule that one model must own the whole task.

You might use one model to challenge the architecture and another to execute the checklist. You might let a cheaper tier implement conventional pieces and reserve Sol or Fable for the difficult decisions. You might ask one provider to review the other's patch.

This separation reduces correlated mistakes. A model reviewing its own assumptions may preserve them. A second model approaches the diff with different instincts.

Beware Benchmark Theater

Benchmarks are useful when they reveal task shape. A terminal benchmark tells us something about tool coordination. A software-engineering benchmark tells us something about repository work. Neither tells us whether a model understands your peculiar legacy billing service.

Also read every table's footnotes. Reasoning level, token budget, retries, scaffold, and tool access can matter as much as the model name.

Treat vendor benchmarks as a reason to test, not a reason to migrate.

Build a Routing Policy

After a few trials, write down what you learned:

Use Model A for architecture and difficult debugging.
Use Model B for UI work and visual iteration.
Use a balanced tier for routine implementation.
Escalate after two failed attempts.
Require human review for auth, payments, privacy, and migrations.

Now the model picker becomes infrastructure instead of mood.

The Takeaway

Sol versus Fable is not a heavyweight fight with one permanent champion. It is a changing set of tools with different prices, behaviors, and strengths.

Run your own tasks. Keep the harness fair. Measure the patch after the excitement fades.

The best model is the one that helps your code abide.