Fable vs Opus vs Sonnet: Which Claude Model Built the Best Web Portal?

2026-08-10

Maestro's take

Use Fable first for a serious, ordinary coding job.

In our two-run portal test, Fable was the only Claude tier to pass every independent check twice. It also finished in less reported wall time than Opus.

Opus wrote more tests. It used safer deployment defaults. It behaved like the developer who checks the locks twice and then writes a memo about the locks.

Sonnet was not simply cheaper intelligence. Each Sonnet run left a different real defect that its own green test suite missed.

The simple lesson: more self-written tests did not guarantee a more complete result. Independent tests mattered more.

Three routes through the same assignment. Original Maestro Brief illustration.

TL;DR

We gave Claude Fable 5, Opus 5, and Sonnet 5 the same Django portal specification.

Each tier ran twice from a clean repository. All six builds ran concurrently on one machine. We then scored the delivered ZIP files sequentially with the same frozen 23-test suite used for our Codex experiment.

Fable: 46/46 independent checks across two runs. About 12 minutes and 13.5 minutes. One clean run reported 128,497 agent tokens.
Opus: 45/46 raw. About 21.7 minutes and 18.3 minutes. The runs reported 158,284 and 146,001 agent tokens.
Sonnet: 43/46. About 13.9 minutes and 14.9 minutes. The runs reported 131,523 and 132,496 agent tokens.

The Opus miss was peculiar but real. Its own health test contained the literal word TODO because that test searched the repository for unfinished markers. Our frozen hygiene check found the literal. The portal behavior still passed.

The Sonnet misses were product behavior. One run failed to record staff assignment and status changes. The other left the benchmark administrator out of the seeded request ownership.

We do not have clean per-run fresh-input, cached-input, and output receipts for Claude. So this article does not declare a cost winner.

Anthropic's published API sticker prices make the tradeoff sharper. Fable is $10 per million input tokens and $50 per million output tokens. Opus is $5 and $25. Sonnet is temporarily $2 and $10 through August 31, 2026, then $3 and $15.

Those are API rates. They are not measured Claude Code charges for these jobs. Without matching per-run billing receipts, multiplying our aggregate agent-token numbers by those rates would create fake precision.

Acceptance is objective. Reported wall time is directional because all six Claude builds shared one machine.

How did Claude compare with Codex?

On the requested portal features, Fable did not beat Codex Sol or Terra.

All three passed every independent check across both runs.

Opus also passed every portal behavior check. Its one raw miss was the TODO collision described above.

The full two-run scoreboard was:

Fable: 46/46
Opus: 45/46 raw; all portal behavior passed
Sonnet: 43/46
Sol: 46/46
Terra: 46/46
Luna: 45/46

The supplied Fable and Opus ZIPs were tidier than the Codex folders we inspected after testing. But the delivery workflow was different, so we cannot say the model alone caused that difference.

Codex also gave us complete cost receipts. Claude did not. The timing setups were different too.

So this benchmark does not say Claude beat Codex.

It says Fable was the most dependable Claude choice. It also says Sol and Terra built the same requested portal features.

If you already use Codex, this is not a reason to switch.

If you use Claude, it is a reason to pick Fable over Sonnet when a small missed requirement would be expensive.

Why Maestro users care

Claude Code lets developers choose among models that promise different balances of capability, speed, and price.

The picker makes the decision look simple. The finished repositories were not.

Fable and Opus both produced strong handoffs. Sonnet looked successful until independent checks asked questions its own tests had not asked.

That is the practical risk in model selection. The cheaper run may save tokens. A missed audit trail can give the savings back during review.

What they built

The assignment was an ordinary customer-request portal.

Login. Dashboard counts. Request creation and editing. Staff assignment. Status changes. Search. Filters. Pagination. Activity history. One hundred repeatable seed records. A usable 390-pixel layout.

The permission boundary mattered most.

Normal users could see only their own requests. Staff could see everything. Only staff could assign work or change status. The server had to enforce those rules.

Every Claude result got that security boundary right. All six used restricted forms, server-side ownership checks, Django sessions, and CSRF-protected POST forms.

That does not make them production-ready. It means the tested boundary held.

Fable was the consistent one

Both Fable runs passed all 23 frozen checks.

They also arrived without a database file or leftover debug records. Both documented the benchmark credentials and the cleanup still required before deployment.

Fable's default settings favored convenience. DEBUG was on unless an environment variable disabled it, and a development secret remained as a fallback. That is acceptable for a local prototype. It is not a safe production default.

The code was compact without being cryptic. Visibility lived in one reusable query helper. Ordinary-user forms never accepted status or assignee fields. Seed data was distributed correctly across all three users and all three statuses.

For this task, Fable was the easiest Claude result to recommend.

Opus was the cautious one

Opus wrote 107 tests in one run and 77 in the other. Fable wrote 62 and 51. Sonnet wrote 52 and 53.

Test volume did not decide the winner.

Opus did make stronger production choices. Both runs defaulted DEBUG to false. One generated and persisted a local development secret instead of shipping a fixed one. The code separated visibility, filtering, and activity logging more deliberately than the other tiers.

The tradeoff was weight.

Opus took the longest reported wall time and used the most reported Claude agent tokens. Its extra work produced the most production-minded repositories, but no extra customer-facing feature passed because of it.

The one raw acceptance miss came from defensive code folding back on itself: a test that searched for TODO contained TODO.

That is not a portal failure. It is still a handoff blemish. A frozen test is allowed to be annoying. Production usually is.

Sonnet proved why green is not done

Both Sonnet runs reported passing their own tests.

Independent checks found something different.

In the first run, Django's ModelForm.is_valid() mutated the bound request object before the view captured its old assignment and status. The comparison saw no change. The portal saved the update but skipped the activity record.

In the second run, the agent caught and fixed that exact class of bug. It still created all 100 seed requests under only Alice and Bob. The specification required distribution across the administrator too.

One Sonnet run also produced an awkward mobile filter form. It did not overflow the page, but oversized flex spacing pushed the first result far below the fold.

Sonnet was not unusable. It was less dependable under the same independent definition of done.

Do

Use Fable for a bounded but serious feature when consistency matters enough to justify the highest sticker price.

Use Opus when deployment posture, documentation, and defensive test coverage matter enough to justify a heavier run.

Give either model acceptance checks it cannot rewrite.

Do not

Do not choose from the number of tests the agent wrote.

Do not call a run complete because its own suite is green.

Do not calculate Claude API cost from one aggregate “agent tokens” number. Input, cached input, output, tool behavior, and harness accounting are different denominators.

Why

The model is both builder and first reviewer.

That is convenient. It is also a conflict of confidence.

Independent checks are the second opinion.

One thing to try

Take one feature your team builds repeatedly.

Write ten acceptance checks before opening Claude Code. Keep them outside the agent's repository.

Run Fable and your usual Claude tier twice. Compare accepted behavior, cleanup, elapsed time, and the actual usage receipt.

The useful question is not “Which model wrote more?”

It is “Which model left less for the next developer to discover?”

Method and limits

This was one Django task with two runs per tier.

The six Claude builds ran concurrently. Shared CPU and I/O probably inflated wall time. The times are useful context, not a controlled latency ranking.

Claude and Codex expose different token accounting. The Claude agent tokens reported here must not be compared directly with Codex fresh, cached, and output totals.

Fable run 1 does not have a clean token receipt. Its parent session included earlier setup and orchestration work. We excluded that mixed number instead of pretending it belonged to one build.

The rubric-based qualitative code and browser review was conducted by AI and frozen before detailed code inspection. It covered correctness, security, maintainability, test quality, mobile behavior, and delivery cleanliness. No human code review is implied. The raw 23-test result remains the objective result.

Sources considered

Maestro Brief performed the independent scoring described above. The six Claude builds were supplied by the benchmark operator. This article is original Maestro analysis.

Maestro's opinions and summaries are AI-generated.