Claude Fable 5 vs GPT-5.6 Sol: What a Real Production Test Found

Claude Fable 5 vs GPT-5.6 Sol production benchmark

A lot of people want one clean answer in August 2026: Claude or Codex? More precisely, Claude Code running Fable 5 or Codex running GPT-5.6 Sol?

The public benchmark tables are useful, but they do not answer the question most engineering teams actually have: what happens when both agents receive the same messy, connected production problem inside a real repository?

So we ran that test. Not a landing page, a game, or several unrelated coding puzzles. Both agents had to repair and complete a durable webhook outbox where idempotency, concurrency, retries, legacy data, API behavior and an operator interface all touched the same state.

The short answer: both passed every hidden test. Codex finished 36 seconds faster. Fable won 99.6 to 99.0 because it enforced payload privacy at the server boundary.

The result in one table

Category	Weight	Fable 5	GPT-5.6 Sol
Hidden correctness	45	45	45
Idempotency and concurrency design	20	20	20
Verification discipline	15	15	15
Implementation and UI quality	10	10	9
Autonomous completion and time	10	9.6	10
Total	100	99.6	99.0

This is a close result, and it should be read as one. Fable did not expose a hidden correctness failure in Codex. Codex did not take a shortcut through the hard state-management work. Both implementations passed 12 out of 12 unseen tests.

The difference was one defense-in-depth decision: Codex’s operator interface did not display webhook payloads, but its list API still sent the raw payload to the browser. Fable removed that data at the server boundary. In a production operations surface, not sending sensitive data is stronger than sending it and trusting the client not to render it.

What we actually asked them to build

The repository was a small Node.js application with an incomplete webhook outbox. The finished system had to satisfy six connected requirements:

Idempotent event creation. The same semantic request must create one event, including when nested object keys arrive in a different order. Reusing an idempotency key with different content must return a conflict without mutating the original event.
Concurrency-safe worker claims. Two overlapping worker invocations must not deliver the same event twice. The claim has to become visible synchronously, before asynchronous delivery begins.
Exact retry transitions. Failures must move through the correct attempt counts, timestamps and scheduled retry times before reaching a terminal state.
Legacy-record compatibility. Older persisted records with missing fields must remain readable and recoverable without losing the values they already contain.
A usable product surface. The task included JSON endpoints and an accessible operator interface, not only an internal function that could satisfy unit tests.
Verification. The agent had to add focused tests and run the public suite before reporting completion.

This matters because independent micro-tests can flatter an agent. A model may solve idempotency in one file and retries in another while still producing a system whose transitions conflict when the pieces run together. One connected task forces those local decisions to meet.

How we controlled the comparison

A model comparison is easy to stage and surprisingly hard to make fair. We fixed the protocol before the second result was known.

Both agents ran separately on the same Lenovo machine from byte-identical repositories at Git commit 63c52a708ef249613b6ee8763065b4b7b41c1de1. They received the same task text, had the same tool access and could not see the hidden test suite. The runs were isolated rather than simultaneous so resource and network contention could not affect one side.

The configurations were:

Claude Code 2.1.235 with claude-fable-5, maximum effort, safe mode
Codex CLI 0.148.0 with gpt-5.6-sol, maximum reasoning, ephemeral mode

Anthropic documents Fable 5 as a selectable Claude Code model through /model or claude --model claude-fable-5. OpenAI describes Sol as the flagship GPT-5.6 tier and makes it available in Codex with configurable reasoning effort. Those are the products we tested, not bare API calls in a custom harness.

The 100-point score was also locked in advance:

45 points for 12 hidden correctness tests
20 for idempotency and concurrency design
15 for verification discipline
10 for implementation and interface quality
10 for autonomous completion and elapsed time

Speed could contribute only six of the final ten points. A fast wrong answer could not beat a slower correct one.

What Fable did

Fable took 605 seconds. It added 19 focused tests, ran 21 tests in total, and then exercised the live API with create, replay, conflict, validation and redacted-list requests.

Its implementation canonicalized nested idempotency content, made worker claims synchronously, preserved the required retry transitions and normalized legacy records. It also treated the operator endpoint as a security boundary: payloads were removed before the response left the server.

That last decision earned the one-point implementation advantage. It was not required for the hidden correctness suite, which is precisely why it is interesting. The agent carried a production concern beyond the minimum behavior needed to pass.

What Codex did

Codex took 569 seconds, 36 seconds less than Fable. It added two focused test files, made a corrective second pass, ran the full public suite, checked JavaScript syntax and finished with git diff --check.

Its implementation solved the same hard state problems. It canonicalized nested keys, avoided double claims under overlapping workers and completed the exact success, retry and terminal-failure transitions. It passed all 12 hidden tests.

The operator UI did not render payloads. However, the list endpoint still returned them to the browser. That is not the same as displaying sensitive information, but it expands the amount of client-side code and tooling that can see it. We deducted one point because the stronger boundary is to avoid transmitting the field at all.

Codex was otherwise the faster successful implementation. Calling this a loss without that context would misstate what happened.

The hidden test we corrected

One part of the hidden suite initially rejected Codex for adding a harmless normalized field, deliveredAt: null, to a legacy record. The written task required existing values to survive; it did not forbid additional defaults.

That assertion was testing a preference we had not specified. We corrected it to preserve every explicitly stored field while allowing extra normalized fields, then ran the same corrected suite against both candidates.

This is an important part of agent evaluation: a hidden test is not automatically ground truth. If the test enforces behavior that the task never required, the test is wrong. Quietly keeping the failure because it changes the winner would make the benchmark less rigorous, not more.

Why vendor benchmarks do not settle this choice

OpenAI reports strong GPT-5.6 Sol results across coding-agent evaluations, including Terminal-Bench and its comparison with Fable 5. Anthropic positions Fable 5 as a frontier model available in Claude Code and on its platform.

Those evaluations answer broad questions across many tasks. Our run answers a narrow one: how did these two agent-and-model combinations behave on a durable-outbox task with hidden production checks?

Neither answer should be stretched beyond its scope.

One repository cannot establish that Fable is universally safer or that Codex is universally faster. Agent behavior changes with task shape, repository conventions, tool access, context quality and the failure modes your tests reward. Even repeating the same task can produce a different path.

The useful conclusion is not “Fable always wins by 0.6.” It is that the frontier is close enough that your evaluation design may matter more than the model ranking.

Which one should you choose?

For this exact task, we would choose Fable 5, narrowly. Both implementations were correct, but server-side redaction is the production boundary we would want to ship.

If iteration speed were the primary constraint and the returned payload were not sensitive, this run gives a strong case for GPT-5.6 Sol in Codex. It reached the same hidden-test result faster and finished with disciplined repository checks.

For an engineering team choosing a default agent, the better process is:

Pick one connected task from your real backlog.
Write hidden checks around the failures that would actually hurt in production.
Lock the weights before either agent runs.
Start from identical commits and isolate the runs.
Retain the tool log, diff, tests and elapsed time.
Review boundary decisions the tests may not capture: privacy, authorization, observability and recovery.
Repeat across several task types before standardizing.

Do not average together toy tasks and call the result a production benchmark. A frontend polish task, a state-machine repair and a repository migration stress different parts of an agent. Your task mix should resemble the work your team will delegate.

The real takeaway

Claude Fable 5 and GPT-5.6 Sol both completed a task that would have been easy to get almost right. They handled the hard concurrency and state transitions, verified their work and exited without human correction.

Codex was faster. Fable made one stronger privacy decision. The margin was 0.6 points.

That is less satisfying than declaring one model the new king, but it is more useful. At this capability level, the winner may be decided by the boundary condition your generic benchmark forgot to test.

So test the work, not the logo. Make the failure conditions visible. Keep speed in the score, but never let it outweigh correctness. And when one agent wins by a detail, inspect the detail before you repeat the headline.

If your development team wants to establish this kind of shared task, test, review and merge loop on a real repository, see the AI Engineering Working Day.