The Vibe Father
The July 24, 2026 answer for most coding teams is Claude Opus 5 at high effort, with GPT-5.6 Sol kept alive as a second route. That is not a fan pick. It falls out of three facts. Opus 5 ties GPT-5.6 Sol on the independent Coding Index, it leads the Agentic Index, and it costs $5/$25 per million tokens against Fable 5's $10/$50.
But "which model is best" is the wrong question, and it is the question every launch-day post answers. The right question is which model should own which lane in your stack, and what evidence would make you change that. This guide answers that, benchmark by benchmark, including the places where Opus 5 loses.
Background reading if you need it every Opus 5 benchmark explained, and why multi-model routing beats single-vendor loyalty.
The three contenders, priced
| Model | Input / output per 1M | Positioning |
|---|---|---|
| Claude Opus 5 | $5 / $25 | New flagship, top of Intelligence and Agentic boards |
| Claude Fable 5 | $10 / $50 | Previous Anthropic frontier model |
| GPT-5.6 Sol | Varies by tier | OpenAI frontier, strongest on established SWE benchmarks |
The pricing line is the whole story on the Anthropic side. Opus 5 is not marginally cheaper than Fable 5, it is half the price, at equal or better measured capability. When a vendor does that to its own product two months after shipping it, the previous flagship stops being a reasonable default for anything except the specific domains where it still wins.
Head to head on measured indices
| Index | Opus 5 | GPT-5.6 Sol | Fable 5 |
|---|---|---|---|
| Intelligence Index | 61 | 59 (max) | 60 |
| Coding Index | 78 | 78 (xhigh), 77 (max) | Not published |
| Agentic Index | 55 | 54 (max) | Not published |
Artificial Analysis capability boards, read July 24, 2026.
Two honest observations. First, these margins are tiny — one point, or a tie. If someone tells you Opus 5 "crushes" GPT-5.6 Sol at coding, they have not read the board. Second, Fable 5's coding and agentic index values are not published, so any Opus-5-vs-Fable-5 coding claim rests on the vendor's own comparisons rather than a third-party board. We flag that rather than papering over it.
Where the models genuinely diverge
The interesting separation is not on the coding index. It is on task-shaped benchmarks.
ARC-AGI-3 measures problems with no memorized template. Opus 5 at 30.2%, GPT-5.6 Sol at 7.8%, Opus 4.8 at 1.5%.
| Benchmark | Winner | Numbers | What it predicts |
|---|---|---|---|
| SWE-bench Pro | Opus 5 | 79.2% vs 64.6% | Harder, less-saturated repo tasks |
| DeepSWE v1.1 | GPT-5.6 Sol | 72.7% vs 68.8% | Repo-scale software engineering |
| Frontier-Bench v0.1 | Opus 5 | 43.3% vs 34.4% | Long-horizon agentic coding |
| OSWorld 2.0 | Opus 5 | 70.6% vs 62.6% | Computer use, GUI automation |
| ARC-AGI-3 | Opus 5 | 30.2% vs 7.8% | Genuinely novel debugging |
| GDPval-AA v2 | Opus 5 | 1,861 vs 1,736 Elo | Professional knowledge work |
Read the DeepSWE row again. It is the single benchmark most directly aimed at "can this model do software engineering at repository scale," and GPT-5.6 Sol wins it by four points. If your workload is dominated by large multi-file changes in an established codebase, that result should carry more weight for you than ARC-AGI-3 does.
Meanwhile the Opus 5 wins cluster around a theme, unfamiliar problems, long horizons, tool use, and work that is not purely code. That is the profile of an agent that keeps going when the first three approaches fail — what Anthropic describes as agentic persistence.
A routing table you can actually adopt
Stop asking which model is best. Assign lanes.
| Lane | Default | Why |
|---|---|---|
| Long-horizon agent work, hard debugging | Opus 5 (xhigh) | Frontier-Bench and ARC-AGI-3 leads |
| Routine feature work with tests | Opus 5 (high) or Sonnet 5 | Cost per accepted diff, not peak capability |
| Repo-scale multi-file SWE | GPT-5.6 Sol | Wins DeepSWE v1.1 |
| Computer use / GUI automation | Opus 5 | OSWorld 2.0 70.6% |
| Planning docs, tickets, specs | Opus 5 | GDPval-AA v2 and AA-Briefcase leads |
| Health-adjacent work | Fable 5 | Reported to lead on health tasks |
| Legal analysis | Mythos 5 | Reported to outperform on legal |
| Offensive security tooling | None of these | Opus 5 is deliberately weak on exploit development |
A routing table is only useful if it is enforced somewhere — a config file, a harness policy, a gateway rule. If it lives in a Slack message, it is a wish. Put the model choice next to the task type in code, and make the fallback explicit so a provider incident degrades your throughput instead of stopping it.
The cost argument, done properly
Comparing models on price per million tokens is the most common mistake in this category. A reasoning model that solves a task in one attempt at $25 per million output tokens is cheaper than a weaker model that needs four attempts at $10.
The metric that survives contact with reality is cost per accepted change, total tokens spent on a task, including retries and the human review round-trip, divided by changes that actually merged. Measure it for two weeks. It will not match the leaderboard order, and that is the point.
| What you measure | What it tells you | Trap |
|---|---|---|
| Price per 1M tokens | Vendor list price | Ignores retries entirely |
| Tokens per task | Verbosity and effort cost | Rewards models that give up early |
| Cost per accepted change | The real number | Needs two weeks of data |
| Repair time after merge | Hidden cost of fluent wrong code | Most teams never track it |
Artificial Analysis frames the Opus 5 result as comparable intelligence to Fable 5 at roughly 26% lower cost per task — note that this is cost per task, not per token, because Opus 5's effort ladder changes how many tokens a task consumes. That is the right unit.
"Agentic persistence" and what it costs you
The behavioural claim Anthropic makes about Opus 5 is persistence, the model keeps working until a task actually succeeds rather than returning a plausible partial answer. Coverage of the launch repeats this framing, and the Frontier-Bench and OSWorld results are consistent with it — both reward not giving up.
Persistence is genuinely useful and it has a bill attached. A model that retries its own approach three times before reporting success consumes more tokens than one that returns after the first attempt, and it occupies a queue slot for longer. If your agent runs against a task list overnight, that is a good trade. If it runs inside a CI job with a ten-minute budget, persistence turns into timeouts.
| Harness setting | Why it matters more with Opus 5 |
|---|---|
| Wall-clock timeout per task | A persistent model will use every second you give it |
| Token ceiling per task | The only hard stop on a self-retrying loop |
| Explicit success criteria | Persistence needs a definition of done, or it optimises the wrong thing |
| Test gate before merge | Persistence produces confident output — verify it mechanically |
The practical takeaway is that Opus 5 rewards a stricter harness than a weaker model does. Give it a clear finish line, a token budget, and a test suite that decides whether it succeeded, and the persistence works for you. Give it a vague prompt and unlimited retries, and you have built an expensive way to generate confident nonsense.
The safety and alignment delta
Anthropic reports an alignment score of 2.30 on its misaligned-behaviour measure for Opus 5 — lower, meaning better, than both Fable 5 and Opus 4.8. It also reports that cyber classifiers trigger roughly 85% less often than on Fable 5, with blocked requests falling back to Opus 4.8.
For teams doing defensive security work, that combination is the meaningful change. Vulnerability research that previously tripped a refusal is more likely to go through, and Opus 5 is reported to be close to Mythos 5 on identifying vulnerabilities in OSS-Fuzz. Exploit development remains substantially weaker, which is a deliberate design position rather than a capability gap you should expect to close.
| Security task | Opus 5 posture |
|---|---|
| Reading code for vulnerabilities | Strong — close to Mythos 5 on OSS-Fuzz identification |
| Explaining a CVE and its blast radius | Strong |
| Writing a patch for a known flaw | Strong |
| Developing working exploits | Substantially behind Mythos 5 by design |
| Penetration-testing automation | Blocked, falls back to Opus 4.8 |
Fewer false refusals matters practically. A security team that spent last quarter rephrasing prompts to get past a classifier was paying a real productivity tax. If that is you, this is the part of the release worth testing first.
Do not forget the cheap lane
Every model-comparison article implicitly assumes the frontier model should do the work. For most teams, a meaningful share of agent tasks — renames, formatting, mechanical migrations, classification, test scaffolding — do not need a frontier model at all.
Sonnet 5 sits at $2/$10 per million tokens on Anthropic's introductory rate through August 31, 2026, moving to $3/$15 after that, and handles that lane at a fraction of the cost and a fraction of the latency. One caveat before you model the saving. Sonnet 5 uses a newer tokenizer that counts roughly 30% more tokens for the same text, so per-token parity is not per-request parity. Measure it on your own prompts. The correct architecture is not "pick the best model." It is "send each task to the cheapest model that reliably completes it, and escalate on failure." Escalation is the pattern that gets you frontier quality on the tasks that need it and cheap throughput on the tasks that do not.
Latency changes the answer for interactive tools
Opus 5 at max effort measures around 52.8 output tokens per second with roughly 62.7 seconds to first token. That is fine for a background agent. It is disqualifying for anything a human waits on.
If you are building an interactive assistant, either drop to a lower effort tier, use fast mode — about 2.5x the default speed at twice the base rate — or route interactive turns to Sonnet 5 and reserve Opus 5 for the queue. Do not ship a chat surface backed by max-effort Opus 5 and then wonder why engagement fell.
What would change our recommendation
- DeepSWE-shaped evidence. If independent reproductions show GPT-5.6 Sol's repo-scale lead is larger than four points on realistic codebases, the default flips for teams doing mostly maintenance work.
- Arena human-preference votes. Elo from real developer comparisons has repeatedly disagreed with static benchmarks. We blend it at a fixed weight for exactly that reason.
- Fable 5 coding index publication. Right now the Opus-5-beats-Fable-5 coding story rests on vendor comparisons. A third-party number would settle it.
- Your own twenty tickets. This outranks everything above. Public benchmarks tell you which models to test. They do not tell you which model works on your codebase.
A two-week evaluation plan
- Pick twenty real tickets from your backlog spanning bug fix, feature, refactor, and migration.
- Run each through Opus 5 at high effort and your current default, same harness, same tests, same review process.
- Record, accepted diff yes/no, tokens spent, wall-clock to merge, and whether the change needed repair within a week.
- Compute cost per accepted change for both. Compare that, not vibes.
- If the delta is under 10%, keep your current default — migration has a cost too.
- If Opus 5 wins clearly, switch, pin the revision, and keep a working GPT-5.6 Sol route.
The pinning step matters more than people expect. Model behaviour shifts between revisions, and an agent that silently changes personality mid-sprint is a debugging nightmare. Pin the revision, upgrade deliberately, and re-run your twenty tickets when you do.
Common questions
Is Opus 5 better than Fable 5?
On the published Intelligence Index, yes — 61 to 60 — at half the price. Fable 5 still reportedly leads on health tasks, and its coding and agentic index values are not independently published, so the coding comparison relies on vendor figures.
Is Opus 5 better than GPT-5.6 Sol for coding?
They tie at 78 on the Artificial Analysis Coding Index. Opus 5 wins SWE-bench Pro, OSWorld 2.0, and knowledge-work benchmarks, GPT-5.6 Sol wins DeepSWE v1.1. Pick by workload shape, and keep both routes available.
Should we drop our other providers?
No. Single-vendor dependency is a business risk. The cost of keeping a second route warm is a config file and an occasional smoke test. The cost of not having one is measured in outage hours.
Which effort level should we default to?
High for most agent work, xhigh for hard debugging. Max is a benchmark setting and occasionally underperforms xhigh while costing more.
Sources and further reading
- Anthropic. Introducing Claude Opus 5
- Artificial Analysis Coding Index
- Artificial Analysis Agentic Index
- DataCamp. Claude Opus 5 explained
- Claude Opus 5 scorecard on this site
- Open-weight models as vendor-thrash insurance
One last framing that helps in meetings. Frontier launches feel like they demand a decision, and they mostly do not. What they demand is a scheduled re-evaluation. Put a recurring thirty-minute slot on the calendar where whoever owns the platform reads the new numbers, runs the twenty tickets if anything looks material, and reports one sentence, default stays, or default moves. That converts a permanent state of low-grade anxiety into a routine, and it is the single highest-leverage process change most teams can make in this cycle.
