Loading benchmark data…
EyesInAI·Loading live benchmark data
“Opus vs Sonnet vs Haiku.” “GPT-5 vs 4o.” Every provider ships a lineup with confident labels and no way to tell which one you actually want for the code in front of you. This page answers two things plainly: which model fits which coding task, and how the frontier models actually score when we take their code and run it — pass-rates over executed test cases, not vendor benchmarks.
The most common mistake is reaching for the largest model by reflex. Cost and latency add up fast, and the biggest model rarely wins a routine edit. Find your task, then pick the tier.
You need: Speed and volume. The shape is known; you just want it typed out.
Reach for: A fast, cheap tier — Haiku 4.5, GPT-4o, or an open model (DeepSeek-V3, Qwen).
Skip: A frontier reasoning model. You’re paying for depth you don’t need.
You need: You know exactly what you want — do it cleanly and quickly.
Reach for: The efficient tier: Sonnet or GPT-4o. Fast, capable, cheap enough to run often.
Skip: Reflexively reaching for the biggest model on a well-scoped change.
You need: Reasoning about state, edge cases, and why the code is actually wrong.
Reach for: A frontier model: Opus 4.8, GPT-5, or Gemini 2.5 Pro. Depth pays for itself here.
Skip: A tiny fast model — it’ll confidently “fix” the wrong line.
You need: Holding a lot of context and not breaking behaviour across many files.
Reach for: A frontier model with a large context window (Opus 4.8 1M, Gemini 2.5 Pro).
Skip: Splitting across a cheap model to save cost — the re-reads cost more.
You need: Tool use, staying on-task over many steps, and grinding without drifting.
Reach for: The top tier: the largest frontier model (Opus 4.8, GPT-5, or Gemini 2.5 Pro); strong tool-use scores matter.
Skip: A model that aces one-shot tests but drops constraints over a long loop.
You need: Careful reading and catching subtle mistakes — not writing new code.
Reach for: A frontier model, or a cheaper one at HIGH reasoning effort as a middle ground.
Skip: Assuming “fast = fine.” Review is where depth quietly earns its keep.
The Claude Code model menu trips people up because the labels describe capability, not job. Here’s the same lineup mapped to when you’d actually pick each — plus effort, a separate dial: pairing HIGH effort with a cheaper model is the middle ground between fast and thorough.
| Model | What it is | Pick it when |
|---|---|---|
| Fable 5 | Most capable, slowest, priciest | Hard AND long-running: big refactors, deep multi-step agent loops. Reach for it only when the task justifies the cost. |
| Opus 4.8 | The everyday workhorse (1M context) | Genuinely complex or ambiguous coding, or when you’re loading a lot of files. The sensible default. |
| Sonnet 5 | The efficiency tier — the deliberate step-down | Routine, well-scoped work: focused edits, boilerplate, high-volume calls. “I know what I want — do it fast and clean.” |
| Haiku 4.5 | Fastest, for quick hits | Trivial edits, quick lookups, tiny functions. Least depth, but excellent when speed is the whole point. |
This is the current model lineup as named in the tools. The measured grid below is the last benchmark run (Jul 4, 2026), so the exact model versions it tested may trail the newest names above — the tier logic (fast/cheap vs. frontier/deep) holds regardless of which point-release is on the shelf.
Guidance is cheap; here are numbers. Each coding test asks a model to write, fix, or refactor a function, then we execute its output against hidden assert cases in a sandbox. A pass means the code actually works — not that the answer looked plausible or arrived fast. Each run is repeated 3× so a lucky pass doesn’t flatter anyone.
| Coding test | GPT-5 | Sonnet | Opus | GPT-4o | DeepSeek-V3.1 | Qwen2.5-72B | Gemini |
|---|---|---|---|---|---|---|---|
Debug: fix a subtly broken function code_fix_bug · code_fix_bug | 3/3 | 3/3 | 3/3 | 2/3 | 3/3 | 3/3 | 2/3 |
Implement from a precise spec code_to_spec · code_to_spec | 3/3 | 3/3 | 3/3 | 3/3 | 1/3 | 3/3 | 1/3 |
Refactor while preserving behaviour code_refactor_preserve · code_refactor_preserve | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 |
Non-trivial algorithm (interval merge) code_algo · code_algo | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 0/3 | 0/3 |
Code generation quality code · code_flatten | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 2/3 |
Sandbox-executed (isolated subprocess, no secrets, 5s timeout). Generated 2026-07-04. Part of the deep suite.
Read this as a signal, not a verdict. It’s a small, deliberately tricky coding suite — a low score on one test is a finding, not proof a model “can’t code.” Real coding work also depends on your harness, context, and prompt. Use the grid to separate the models that reason about code from the ones that pattern-match, then confirm on your own task. Cost matters too: the cheapest model that clears your bar usually wins.