July 19, 2026
I stopped choosing between Fable and Sol
Claude Fable 5 in one cmux pane, GPT-5.6 Sol in another. One works, the other reviews, and I keep the final call.

The launch-week question is always the same: which model wins?
I have mostly stopped caring.
My current setup has Claude Fable 5 and GPT-5.6 Sol open next to each other in cmux. They can read the same repo, inspect each other’s output and pass work back and forth. I still decide what ships.
Both models were behind gates in June: Fable was pulled days after release and Sol sat behind a partner list. Access opened up since, which is exactly why the scoreboard question aged badly.
That combination has been more useful than trying to make either model handle the whole job alone.
Two different defaults
Anthropic describes Fable 5 as a model for long-running coding and knowledge work: planning across stages, delegating and checking its own work. OpenAI positions GPT-5.6 Sol around coding, tool use, computer use and getting more work from fewer model round trips.
Vendor descriptions are vendor descriptions. I do not treat them as independent evidence. But the models do feel different in daily use.
Fable tends to hold more of the problem in view. I like it for reading the wider context, challenging a plan and pointing at assumptions I have stopped seeing.
Sol is the one I reach for when I want the work turned into something concrete: reproduce the failure, make the smallest change, run the checks and show me what happened.
Those are tendencies, not permanent job titles. Sometimes Sol finds the architectural problem and Fable writes the cleaner patch. The point is not which model gets which chair. The point is that they do not arrive with exactly the same habits.
cmux makes the review cheap
I run the models in separate cmux panes. One can keep working while the other reviews. I can see both surfaces, send context between them and interrupt when the conversation starts drifting.

The useful handoff is not “what do you think?” It is an artifact:
- the plan and its assumptions
- the diff and the files it touched
- the failed test or screenshot
- the acceptance criteria
- what has already been tried

That gives the second model something falsifiable. It can point at a line, run a check or produce a counterexample. A vague conversation between agents mostly creates polite agreement. A diff creates work.
My usual loop is simple:
- Give one model the outcome and constraints.
- Let it produce a plan or implementation.
- Send the actual artifact to the other model with one instruction: try to break this.
- Return the findings to the first model.
- Run the checks and make the final call myself.
Agreement is not the goal
Two models agreeing does not make something true. They share training data, common coding conventions and plenty of the same blind spots. They can also reinforce a bad premise with impressive confidence.
The disagreement is often more useful.
If Fable says the architecture is wrong and Sol says the tests pass, I have learned that the tests may not cover the architectural risk. If Sol reproduces a bug that Fable dismissed, the reproduction wins. If both models make claims without pointing to code or output, neither has earned the decision.
Tests beat consensus. A browser screenshot beats a description of the UI. A traced request beats a theory about the API. The second model is there to produce another angle and more evidence, not a second vote.
The part I would keep if the models changed tomorrow
Fable and Sol are the best pairing I have used so far. That will probably change. Model rankings do that every few weeks.
The durable part is the workspace:
- separate surfaces instead of one endless chat
- explicit handoffs instead of copied summaries
- different model families reviewing the same artifact
- checks visible next to the work
- one human gate before anything public or irreversible
cmux is useful because it does not try to become the orchestration philosophy. It gives me panes, a browser, notifications and a CLI. I decide how the models work together.
I no longer need one model to be right all day. I need one to do the work and another to disagree usefully before I ship it.