On July 9, OpenAI shipped GPT-5.6 in three sizes. Four weeks before that, on June 12, US export controls took Anthropic’s most capable model offline worldwide for eighteen days, and it came back on July 1. If you pay for both vendors you now have four serious coding models on your desk, and the benchmarks that used to settle this have spent the last five months being retracted by the people who ran them.
The answer is a routing table rather than a ranking, and the model you want changes three or four times inside a single build. Everything below is current as of July 13, 2026, comes from a team that ships with all four, and flags the places where we are out on a limb.
Planning: Opus 4.8 writes it, Codex audits it
The plan is the most consequential artifact in the whole workflow, and it usually gets written by whatever model happened to be loaded.
Planning is a separate skill from implementation, and models are measurably worse at it. SpecBench, released in May, scores agents on finding the flaws in real architecture proposals from Kubernetes, React, Rust, and vLLM, with no code execution at all. The best agent it tested managed 44.4%. Writing the plan down first also improves the code that follows, and by a margin worth having: the peer-reviewed self-planning study in ACM TOSEM found “a relative improvement of up to 25.4% in Pass@1 compared to direct code generation.”
Plan with Opus 4.8 at xhigh. Anthropic agrees with this strongly enough to ship it: Claude Code has a mode called opusplan that “uses opus during plan mode, then switches to sonnet for execution,” and it quietly upgrades the model whenever you enter plan mode.
Not Fable 5, though, and this is a real disagreement with the vendor. Fable 5 makes too many assumptions when it plans, filling gaps confidently instead of surfacing them, which is the worst failure mode a plan can have. That sounds like taste until you look at the research. A study of 4,018 agentic coding runs named “rogue actions” as a distinct failure mode of high-reasoning models. Anthropic’s own docs warn that its highest effort setting “can lead to overthinking.” Simon Willison, who is not careless about this, keeps Fable 5 in the main loop for architecture and judgment calls, and may well be right. We keep Opus 4.8 on the plan anyway, because the failure that costs us most is a plan that reads as finished while quietly deciding things nobody asked it to decide.
The plan file: Claude writes one, Codex is not allowed to
Claude Code writes its plan to a file on disk. Codex, in plan mode, is forbidden from writing files at all.
Both vendors say so in their own material. Anthropic’s hooks documentation states that “Claude writes the plan to a file on disk before calling the tool,” and exposes the path to it. Codex’s plan-mode template, checked into OpenAI’s own repository, lists “Editing or writing files” under the heading Not allowed, so it emits its plan as a block in the conversation, and its update_plan tool is an in-memory checklist that errors if you call it inside plan mode.
That asymmetry is what makes the handoff possible in one direction only. Because Claude’s plan is a file rather than a conversation, you can pass it straight to Codex, running Sol, and have it pull the plan apart before a single line of code exists, which is the cheapest point in a project to catch a bad decision. The reverse does not work: had Codex done the planning, there would be no artifact to hand anywhere.
One catch will cost you an afternoon: Claude’s plan file lands in ~/.claude/plans by default, outside your repository, where the model you want to audit it cannot see it.
// .claude/settings.json
{ "plansDirectory": "./plans" }
If you run both tools, the other piece of shared context worth wiring up is AGENTS.md, now an open standard under the Linux Foundation and read by Codex, Cursor, Copilot, Zed, and about twenty others. Claude Code is not one of them and says so: “Claude Code reads CLAUDE.md, not AGENTS.md.” Anthropic’s documented workaround is a one-line CLAUDE.md containing @AGENTS.md.
Let the planner do the routing
You can also skip looking any of this up. When you open plan mode, hand the planner this article, either as a URL it can fetch or pasted in as text, and give it one more instruction on top of whatever you are building:
Use this article to assign each phase of the plan to the appropriate model and reasoning effort. At the start of each phase, tell me which model and effort to switch to.
The plan that comes back has the routing built into it. The schema phase is marked for Sol, the interface phase for Opus 4.8, the scaffolding for Terra at low, and the review pass for whichever vendor did not write the code. You are still the one switching models between phases, because neither tool can reach across to the other vendor mid-run, but the decision gets made while the work is still cheap to reason about and you have not yet sunk two days into it.
It also gives you something to argue with, which is the part we did not expect. When a planner marks a phase for the frontier model and you were expecting to hand it to the workhorse, the phase is usually under-scoped rather than the planner being wrong, and it is worth going back to read what you actually asked for.
Back end and architecture: Sol
GPT is the better architect. It produces cleaner boundaries and better schemas, and it leaves behind fewer structural decisions you have to undo three weeks later. This is the clearest pattern in our own work, and neither vendor will tell you it, since OpenAI does not market Sol on architecture and Anthropic is hardly going to.
The independent evidence lines up better than we expected. Design Arena runs two evaluations that split along exactly this line. On its automated fullstack backend rubric, GPT sweeps the top four, and Sol scores 9.7 on schema design against Fable 5’s 6.5. On its agentic frontend board the result inverts: Claude sweeps the top four, and no OpenAI model appears in the top fifteen.
So give Sol the schema, the service boundaries, and the data flow, at high. Push it to xhigh once you can name the constraints it has to satisfy: a schema that has to migrate without downtime, a latency budget, an API you are not allowed to break. On a greenfield sketch, where nothing has to be satisfied yet, xhigh buys you a longer wait and a more elaborate answer to a question you have not pinned down.
Ultra is a different question, and the answer is almost always no. Turn it on to audit a design once the design exists, and for very little else.
Those two boards do not measure the same way, and that is the strongest argument against everything we just said. The frontend board is people voting on which result they prefer the look of, while the backend board is a script scoring the structure of what came out. So the split may be telling you something narrower than we are claiming: that GPT wins when a machine is marking and Claude wins when a human is, which has different consequences. We lean the other way, because the same divide shows up in our own code review, where nobody is voting on anything and a schema is either right or it is not. The boards on their own would not settle it.
GPT also ships fewer bugs. Across our projects, Sol’s back-end code comes back from review with fewer defects than the equivalent work from a Claude model, and the gap is large enough that we plan around it. No public study measures defect rates for any of these four models, so nobody can confirm or refute that, including us. Treat it as our finding rather than a fact, and treat anyone who is certain about it with suspicion, because the measurement does not exist.
Front end, UI, and UX: Opus 4.8
Claude is better at anything a human has to look at. Layout, interaction detail, and the way information is arranged on a screen all come out better, and they come out better on the first attempt, which is what saves you the afternoon of iterations.
On this one the boards and the vendor both agree with us. Claude leads WebDev Arena and holds seven of the top ten. Anthropic’s own product page carries a customer quote calling Fable 5 “significantly stronger on the hardest tasks, UI design and game coding,” which is a marketing quote rather than evidence, but it is at least a marketing quote pointing the same way as the independent boards and our own experience.
Start on Opus 4.8 at high, and stay there for ordinary screens, forms, and list views, where Fable 5 costs double for a difference you will struggle to see. Escalate to Fable 5 when the interface is the product: a novel interaction, a dense view someone has to read at a glance, anything where the look and feel is the thing being judged.
Writing the code: follow the layer
The code follows the layer it belongs to. Back-end code, meaning the services, the queries, the migrations, and the business logic behind them, goes to the OpenAI side. Send the routine parts to Terra at medium, its default, and escalate to Sol when Terra stalls on something genuinely hard. Front-end code, meaning components, state, layout, and anything a user will actually touch, goes to Opus 4.8 at high.
Implementation inherits the strengths of design, which is why the same split holds. A model that reasons well about structure writes better structure, and a model that reasons well about what a person sees writes better interfaces. Splitting a feature across two vendors sounds fussy until you have watched one model produce a clean schema and then a genuinely ugly component in the same session.
Raise Terra’s effort, or move up to Sol?
Effort buys depth on a problem the model already understands, and it cannot buy understanding the model does not have. The test-time-compute research found the same thing: more thinking substitutes for a bigger model on easy and intermediate problems, and on the hardest tier “no method makes much meaningful progress.” So the question to ask is how Terra is failing.
If Terra’s answer is thin but pointed in the right direction, meaning it has understood the task and simply not carried it far enough, missing a case, skipping a constraint, stopping short on a fiddly migration, then it is inside its competence and short on depth. Push Terra to high, then xhigh. That is much cheaper than moving to Sol, because you are paying more tokens on a model that costs half as much per token.
If Terra’s answer is confidently in the wrong shape, meaning it has misread the problem, reached for the wrong abstraction, or produced something plausible that does not survive contact with the real constraints, then more thinking will produce a longer wrong answer. Move to Sol at medium and only raise it from there. Raising the effort on a model that has misunderstood the task is the most common way to spend real money on nothing.
Mechanical edits and boilerplate: Terra, at low effort
Terra is the right default for everything routine, and Sol is the escalation. Terra costs $2.50 in and $15 out per million tokens, half of Sol’s $5 and $30, and GitHub’s own release notes call Terra “the balanced default. A strong all-round choice for everyday interactive and agentic coding,” against Sol as “the highest reasoning ceiling in the family.” We will not put a number on the gap between them, because GPT-5.6 is not yet scored on any independent board, and neither should anyone else. Reach for Sol when Terra stalls.
Send it boilerplate, precisely specified edits, scaffolding, and test fixtures, at low. OpenAI’s own guidance is to “use medium as a balanced starting point and low for latency-sensitive workloads,” and mechanical work is exactly that: raising the effort buys no accuracy on a task with no ambiguity in it, and it costs you latency, which is not free. If you drive Codex from the app or the IDE rather than the CLI, this level is labelled Light rather than low, which is the same rung under a different word.
If the bill is what keeps you up rather than the output, that is a different problem with a different playbook, and we wrote it up in how to control AI token costs. Model choice is only one part of that spend, and often not the part doing the damage.
Debugging: whichever model did not write the code
Debugging follows the same rule as review, for the same reason. A model that wrote the code is the worst candidate to find the bug in it, because finding the error is the step it cannot do. Hand a hard bug to whichever frontier model did not write the code, at xhigh.
This is one of the few places the highest effort setting reliably earns its cost. A bug you cannot find sits at the hard end of the difficulty range, which is where more thinking still pays.
Code review: always the other vendor
Fable 5 caught bugs in GPT-5.5’s xhigh output that GPT had not caught itself, and that Opus 4.8 at max also missed. Opus 4.8 is a different vendor from GPT, it was running at the highest setting it has, and it still walked past the same defects, so a change of vendor on its own was not enough to catch them. It took the strongest model we had.
So send the review to the other vendor’s frontier model, and accept that a mid-tier reviewer will miss what a frontier one catches. The honest limit is that we have not run this against GPT-5.6 Sol, so it is one data point rather than a law.
The evidence that a model cannot mark its own work is about as solid as anything in this field. Researchers testing LLMs as secure-code agents found that models repair other models’ insecure code at rates between 33% and 60%. On code they wrote themselves, the same models “perform poorly.” A Google DeepMind paper at ICLR 2024 went further, finding that models “struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction.” Work at ACL the same year located the bottleneck precisely: a model can fix an error once you show it where it is, but it cannot find it. LLM judges also favour their own output, in proportion to how well they recognise it as theirs. Addy Osmani puts the practice plainly in his work on agent harnesses: “separating generation from evaluation into distinct agents outperforms self-evaluation.”
Never let the author grade its own homework.
The “different vendor, different blind spots” story is weaker than it sounds. A Cornell team at ICML 2025 studied errors across more than 350 models and found that “larger and more accurate models have highly correlated errors, even with distinct architectures and providers,” with the correlation increasing as models improve. There is also a simpler explanation for our own result than blind spots, since an ICLR paper on self-repair found the gains come from a stronger reviewer rather than a different one, and OpenAI’s CriticGPT showed a same-family critic works fine once trained for the job.
So: use a second reviewer, always. Prefer the other vendor, because it is the cheapest hedge available against a shared blind spot and costs nothing you were not already paying. But what you are buying is a hedge rather than independence, and it thins as the two frontiers converge on the same mistakes. This is the verifier ceiling again: whatever checks the work sets the limit on how good the work can get, and no amount of compute raises it.
When a phase lands, audit it in parallel
Reviewing one change is a single question, and one reviewer at high settles it. Auditing a phase that has just landed is a hunt for the thing nobody has noticed yet, which is the part models are worst at. The ACL work cited above pinned it down: show a model where an error is and it will fix it, but leave it to find the error on its own and GPT-4 managed that only about half the time. A bigger effort budget buys more thinking, and thinking harder does very little for a search. What a search needs is more searchers, looking in different places.
That is what Ultra does. It runs several copies of the model at once instead of one copy for longer, and despite where it sits in the menu it carries the same reasoning as max rather than more. Anthropic’s ultracode is the same idea resting on xhigh. Both are available on the cheaper model as well, whatever the coverage says: Codex’s own model manifest lists ultra for Terra as well as Sol, and Luna is the one that goes without.
The obvious objection is that copies of one model share one set of blind spots, so running five of them just gets you the same miss five times over. The sampling literature says otherwise. A Stanford group took DeepSeek-Coder from solving 15.9% of SWE-bench Lite issues on a single attempt to 56% across 250 attempts on identical weights, because a model draws differently every time you ask it, and the copies turn out to be poor at agreeing rather than poor at seeing. On MATH the same paper found a correct answer sitting somewhere in the samples 98.44% of the time, while majority voting could only convert that into a right answer 41.41% of the time. So the findings will be there, and the work is deciding which of them are real, which the setting will not do for you.
Whether the panel earns its cost comes down to whether the agents are looking at different things. ChatEval, presented at ICLR in 2024, ran that test on a judging task rather than a solving one, which is the closest analogue to a code review the literature offers. Two agents of the same model, the same number of calls, the same protocol: given identical role prompts they scored 53.8%, exactly what one agent scored working alone, and given different roles they scored 60.0%. A second opinion bought nothing, and a second perspective bought six points. MAGIS, at NeurIPS the same year, is the version that runs on real software, splitting one GPT-4 into a manager, a repository custodian, a developer and a QA engineer and taking it from resolving 1.74% of SWE-bench issues to 13.94%.
That leaves the lenses to you, because neither harness assigns them. Codex’s spawn_agent has no role parameter, and the entire instruction Ultra injects when it turns on proactive delegation is that the model should “use sub-agents when parallel work would materially improve speed or quality.” Its own /review command goes the other way and disables multi-agent before it runs. Anthropic does not assign perspectives automatically either, although it at least documents the pattern, and the code-review plugin it publishes puts five agents on a pull request with a different lens each and scores every finding for confidence before it reports anything. The five lenses that have caught real things in our work are the data model, the failure modes, the operational reality of running it, the security surface, and what a new engineer would misread.
The version of this that circulates has the agents debate each other, and that part does not survive the evidence. A Google DeepMind team rebuilt the original debate result at ICLR 2024 on the full GSM8K test set with the budgets matched, and at nine responses the debate scored 83.0 while plain majority voting over nine independent samples scored 88.2. Debate got worse between rounds while voting got better. The reason is not mysterious, since agents that read each other’s answers are sampling dependently, so the diversity that made the panel worth running collapses round over round and the group tunnels toward one shared wrong answer. Researchers have watched debates vote away a correct answer that was already sitting in the pool. Run the agents independently and have them report back separately.
Then something has to decide which of the findings are real, and that agent is your verifier ceiling made concrete. Princeton work on the limits of resampling explains why it caps everything above it: an imperfect checker has a false-positive rate that no amount of extra compute reduces, so the ceiling belongs to the checker rather than to the budget. Berkeley’s post-mortem of 1,642 multi-agent runs found that reviewer agents in real systems “perform only superficial checks, despite being prompted to perform thorough verification,” and that incorrect verification accounted for 9.1% of failures on its own. Code review has one advantage over almost everything else in that literature, which is that a claimed bug can be made to fail a test, so insist on exactly that and have the reconciling agent reproduce each finding or drop it. A panel that hands you fifteen plausible concerns has spent your money and given you homework.
None of it is cheap, and the rate card will not tell you so. Anthropic, describing its own multi-agent system, reports that multi-agent runs use roughly fifteen times the tokens of a chat, and cautions in the same post that “most coding tasks involve fewer truly parallelizable tasks than research,” which is a company that sells tokens advising you to buy fewer of them. Our own bill turned up as a rate limit instead: on a $100-a-month OpenAI plan, starting from a full usage reset, Ultra on one project emptied a five-hour window in about two hours. That is one project on one day and not a measurement, but the direction is not subtle, and the Codex CLI now warns you about concurrency the moment you select Ultra.
So spend it where the surface actually divides: a finished phase, a plan with real blast radius, a migration, an auth rewrite. The four-hundred-line diff you are shipping on Tuesday does not divide, and one reviewer at high will handle it for a fraction of the price. Keep the two uses of Ultra apart as well, because they want different models. For parallel work, run it on Terra, since the parallelism is the whole point and Terra costs half of Sol. For a parallel audit, run the frontier model, since the entire purpose is catching the subtle thing and Terra will not: Sol under ultra if Claude wrote the code, Opus 4.8 under ultracode if GPT did. The vendor rule survives all of this, because it is the only part that buys genuinely uncorrelated errors, and Cornell’s 350-model result says even that is thinning.
The effort setting: what almost everyone gets wrong
The two vendors do not share an effort scale, do not share a default, and neither one shows you the same list in its API and in its editor. Developers quietly leave quality and money on the table here more than anywhere else in the stack. The whole surface, verified against both vendors’ documentation and Codex’s own source on July 13, 2026:
| Levels | Default | |
|---|---|---|
| Anthropic API | low medium high xhigh max |
high |
| Claude Code | the same five, plus ultracode |
high |
| OpenAI API | none low medium high xhigh max |
medium |
| Codex (CLI, app, IDE) | low medium high xhigh max ultra |
varies by model |
The traps in the setting itself
There is a low, and in the app it is called Light. OpenAI’s guidance is to “use medium as a balanced starting point and low for latency-sensitive workloads,” and almost every write-up quotes only the first half of that sentence, which is how low gets forgotten and how mechanical work ends up running at medium for no benefit. The naming compounds it, because the Codex app, ChatGPT Work, and the IDE extension all display that level as Light while the CLI calls it Low. They are the same rung, and “light” is not a value you can send to the API.
max is probably hidden in your editor. Open the reasoning menu in the Codex IDE extension and you will most likely see five options: Light, Medium, High, Extra High, and Ultra, with no Max anywhere. It is easy to conclude, as we briefly did, that Codex has no max at all. It has one, and OpenAI’s documentation says so in a single line that is very easy to miss: “If you don’t see Max in your options, you’ll have to enable it in your app settings.” The setting ships switched off, so if you have never once used max in Codex, someone else made that decision for you.
ultra and max send the model the same thing. You can read this in Codex’s own source. When you select Ultra, Codex rewrites it to max before the request leaves your machine, and separately switches on proactive multi-agent mode. The API has no ultra at all, and sending it one sends an invalid value. So Ultra sits beside Max rather than above it, carrying the same amount of thinking, and the only difference is that Ultra spawns subagents on its own initiative while Max waits until you ask. Anyone picking Ultra for a smarter answer has been paying for parallelism they did not want. Anthropic has the mirror image, and its docs say so plainly: ultracode “pairs the xhigh effort level with standing permission for Claude Code to launch multi-agent workflows.” Anthropic’s composite sits on xhigh, which leaves max a genuinely higher pure-thinking setting than ultracode, while OpenAI’s sits on max, so Ultra is the ceiling. (ultrathink is a prompt keyword and changes the effort level not at all.)
Every level is calibrated per model. Anthropic’s wording: “the effort scale is calibrated per model, so the same level name does not represent the same underlying value across models.” A level you carried over from the other vendor is carrying no information at all.
max_tokens is what caps your output. Effort is “a behavioral signal, not a strict token budget,” so the two settings do different jobs, and on Opus 4.8 at xhigh or max Anthropic suggests “starting at 64k tokens and tuning from there.” Set that too low and the model runs out of room mid-thought, handing you a truncated answer that reads like a bad one.
The top of the scale can make things worse. Anthropic warns that “on some structured-output or less intelligence-sensitive tasks it can lead to overthinking,” and OpenAI tells you to “reserve max for the hardest quality-first workloads.”
When to raise it, and when not to
Two research results explain that warning. Berkeley and DeepMind researchers found test-time compute could beat a model fourteen times larger. But that holds only on easy and intermediate problems; on the hardest tier, “no method makes much meaningful progress.” Pushing the other way, a study of 4,018 agentic coding trajectories found that simply picking the least-overthought solution improved performance by about 30%, while cutting compute by 43%.
So more effort is not monotonically better, and where it turns depends on the task. On work the model can reach, it keeps helping while the price climbs steeply. On trivial or format-bound work it degrades the answer outright. The rule we use is the failure tax applied to the setting:
Raise the effort when (the cost of a silent failure) > (extra wait + extra tokens) ÷ (the accuracy it buys).
In practice that means raising it when you will not be watching. Long agentic runs are the clearest case: Anthropic’s own advice is to “start with Claude Opus 4.8 for complex agentic coding,” at xhigh, precisely because nobody is reading each step as it happens. Leave the setting down when you are sitting there reading the output and can catch a mistake in five seconds.
The wait is a real cost, not a rounding error. A study of 10,000 programming sessions from 86 developers found that only 10% resume programming within a minute of an interruption, so a ninety-second pause does not cost you ninety seconds. It costs you whatever you did instead, plus the climb back.
When max beats xhigh
Both vendors say to “reserve max for the hardest workloads,” which tells you nothing, because you never know a task was hard until it has beaten you. There is a version of the rule you can measure.
max rewards headroom, not difficulty. Where the model is already succeeding, more serial thinking costs a great deal and can make the answer slightly worse. Where the model is currently failing more often than it succeeds, it buys real points, and you can check which of those you are in against your own pass rate.
Artificial Analysis runs its evaluation suite at every effort level and publishes each rung as a separate entry, so GPT-5.6 Sol can be compared against itself at xhigh and at max: same model, same price per token, same tasks.
| Evaluation | Sol is already at | xhigh → max |
|---|---|---|
| Terminal-Bench 2.1 (agentic coding) | ~89% | 89.51% → 88.01% |
| SciCode (coding) | ~56% | 56.02% → 56.13% |
| GPQA Diamond (science) | ~93% | 93.13% → 94.14% |
| Terminal-Bench Hard (agentic coding) | ~61% | 61.36% → 65.91% |
| Humanity’s Last Exam (frontier reasoning) | ~45% | 44.72% → 47.17% |
| CritPt (physics reasoning) | ~29% | 28.57% → 32.29% |
| Cost per task | $0.35 → $0.58, on double the output tokens |
The two Terminal-Bench rows run the same model, in the same domain, through the same harness. On the standard set, where Sol already clears about 89% of tasks, turning the dial to max lost it four tasks out of 267 and doubled the token bill. On the Hard set, where it clears about 61%, the identical change gained it 4.6 points. Nothing changed except how much room there was left to improve. On SciCode it bought one extra task out of 864, which is a rounding error you paid 65% more for.
ARC Prize replicates the pattern with the cost attached. On ARC-AGI-1, where Sol is saturated at 97.5%, max drags it down to 96.5%. On ARC-AGI-2, where it sits at 90%, max lifts it to 92.5%, at $1.04 to $1.44 per task. And the further a model is from the ceiling, the more the same change buys: on ARC-AGI-2, Terra gains 9.7 points and Luna gains 11.9, against Sol’s 2.5.
Check your own pass rate before you turn the dial up.
So the rule runs on numbers you already have. Default to xhigh. Reach for max only where your own evaluation shows the model failing more often than it succeeds. Above roughly 85%, max is a tax and occasionally a regression. Below about 60%, it starts paying for itself. Anthropic says something similar in vaguer words, telling you to step up to max “only when your evals show measurable headroom at xhigh.”
The same board also answers a question the vendors do not. On Terminal-Bench 2.1, turning Sol up to max cost it 1.5 points, while running the identical thinking as Ultra, with parallel agents on top, gained it 3.1 points and took 88.8% to 91.9%. Those are the two ways to spend a bigger budget on a hard coding task, and they point in opposite directions. Extra money on coding buys more as independent attempts than as one longer train of thought, which is what the sampling literature found from the other end, and why our own Ultra spending goes on audits rather than on answers.
When Opus 4.8 at xhigh is being stubborn, max breaks through. No benchmark can see this one, and we hit it constantly. You have asked for something clearly, three times, and it keeps doing an adjacent thing instead: ignoring a constraint you stated, reaching for the pattern it wanted rather than the one you asked for, quietly reverting a decision you already made. Turning it to max gets it unstuck in a way that rephrasing does not. That is our experience rather than a measurement, and Anthropic has published nothing to confirm or deny it, though it is the same rule seen from a different distance: if the model will not do what you asked at xhigh, your pass rate on that task is zero, and zero is the most headroom there is. One published result cuts against us, a study of fifteen models finding that more reasoning “can significantly degrade instruction-following accuracy.” We read that as obedience to format constraints, while what we are describing is a model that has committed to the wrong approach and will not let go of it, but the disagreement is real and you should weigh it.
So which model do you actually run at max?
Terra: only on a task it is failing. Its ARC-AGI-2 jump of nearly ten points is the strongest evidence for max we found anywhere, and it exists precisely because Terra was at 74% and had somewhere to go. On the routine work you actually send Terra, it is at 90-plus and max is a tax.
Opus 4.8: to break a deadlock, not to raise a ceiling. These are two different reasons to turn the dial, and only one of them works. If Opus is producing decent work and you want better work, spend the money on a better model instead: the bugs Fable 5 found in GPT’s output were bugs Opus 4.8 at max had already looked at and missed, so a cheaper model turned all the way up lost to a stronger model sitting at its default. But if Opus is refusing to do what you asked at xhigh, max is the cheapest thing that reliably shifts it, and it is worth trying before you escalate the model.
Sol: on the hard tail. The genuinely novel bug, the algorithm nobody has cracked, the part of your eval suite still failing after everything else passed. Ordinary tickets get high and are none the worse for it.
Fable 5: the same test, but you cannot check it. You are already on the strongest model there is, so the dial is all that is left to turn, and nobody has published what max does to Fable. Run it against your own failures before you believe it.
Security work, and why Fable 5 will fight you
One category behaves differently enough to plan around. Fable 5 runs behind safety classifiers for cybersecurity and biology content, and when one fires, Claude Code silently re-runs your request on Opus 4.8 and notes it in the transcript.
The catch is what trips it. Anthropic is explicit that the fallback “can trigger on the first request of a session, before you send anything unusual, because the first request carries workspace context such as your CLAUDE.md content and git status,” and that “a repository that contains security or biology material can trip the classifier on that context alone.” So on a security codebase you are not choosing Fable 5 at all: you are being moved off it, at unpredictable moments, mid-session.
So skip the fight and use Opus 4.8 at high for security and CTF work. It is where you were going to be rerouted anyway, and at least you will know which model wrote the code.
The cheat sheet
Every verdict above fits on two printable pages: the full decision table with the reasoning for each row, the four models with their prices, every effort scale side by side, what the data says about max, and the gotchas. Pin it next to your desk, or hand it to whoever on the team is about to pick a model.
The advice itself is free either way, and the whole short answer sits in the summary at the top of this page. The cheat sheet is the printable version of it.
The gotchas that will bite you
- Fable 5 comes off your Pro plan on July 19, 2026. Anthropic includes it for up to 50% of your weekly usage limit until then, after which it runs on usage credits at API rates. The cutoff has already slipped once, from July 7, so treat the current date as provisional and budget for the credits rather than for another extension.
- Fable 5 is never the default on any account type, and Claude Code on a Pro plan defaults to Sonnet 5, not Opus 4.8. If you assumed you were getting the best model, check. Selecting Fable with
/model fablealso persists into later sessions, which is a quiet way to spend credits you did not mean to. - Fable 5 tokenizes text into roughly 30% more tokens than the pre-4.7 models. Its $10 and $50 are already double Opus 4.8’s, and the real gap on the same input is wider than the rate card implies.
- Fast mode on Opus 4.8 costs $10 and $50, which is exactly what standard Fable 5 costs. And
/fastbills usage credits, in Anthropic’s words, “even if you have remaining usage on your plan.” Fast mode on Opus 4.7 is removed on July 24, 2026. - Your plan file is not in your repository unless you set
plansDirectory. - Safety classifiers can reroute Fable 5 on the very first request of a session, before you have asked it anything, because that request carries your
CLAUDE.mdand git status. Anthropic is explicit that “a repository that contains security or biology material can trip the classifier on that context alone.”claude --safe-modeis a diagnostic for finding which customization tripped it, not a workaround: it disablesCLAUDE.md, skills, and MCP servers, but git status and directory names still reach the classifier. The actual switch is in/config. - Organizations with zero data retention cannot use Fable 5 at all. Both Fable 5 and Mythos 5 are designated Covered Models with 30-day retention.
- Fable 5 refuses with an HTTP 200, not an error, carrying
stop_reason: "refusal". Code that reads the first content block without checkingstop_reasonwill hand you an empty string and no explanation.
Why the benchmarks could not have told you this
Everything above is task-level because the aggregate scores no longer separate these models.
The leaders are tied, and the harness matters more than the model. On the official Terminal-Bench 2.1 board, GPT-5.5 running in Codex scores 83.4% and Fable 5 running in Claude Code scores 83.1%, with margins of about two points either way. That is a tie. But run the same Fable 5 through a different harness and it drops to 80.4%, and the same GPT-5.5 drops to 78.2%. Changing the scaffolding around a model moves it about five points. Changing the model moves it three tenths of one. Almost every comparison you will read holds the harness constant without saying so, and then attributes the difference to the model.
The two benchmarks everyone quoted have been withdrawn. OpenAI retracted SWE-bench Verified in February, having found material flaws in 59.4% of the problems it sampled, and retracted SWE-bench Pro on July 8, estimating roughly 30% of its tasks are broken. OpenAI wrote both debunkings, and both concern benchmarks where Claude led, which is worth holding in mind even though the audits themselves look serious.
Even a clean score flatters the model. When METR had maintainers from scikit-learn, Sphinx, and pytest review 296 AI-generated pull requests, merge rates came in about 24 points below the benchmark scores, and roughly half the PRs that passed the tests would not have been merged. The leaderboard measures whether the tests go green, and a maintainer is asking a harder question than that.
The model is also rarely the thing that breaks. When we ran a twenty-agent team for three weeks and logged all 942 runs, about 99% of the failures were operational: bad configuration, timeouts, malformed parameters, abandoned tool calls. Fewer than one in a hundred was the model reasoning wrong.
Do not standardize on one model
From June 12 to June 30, Fable 5 was switched off worldwide under a US export-control directive, and it came back on July 1. For eighteen days there was no degraded tier to fall back to and no rate-limited version to wait out.
If your build pipeline had been standardized on a single vendor’s frontier model, you spent eighteen days finding out exactly what that dependency was worth. That is not a hypothetical for a risk register. It happened last month, and nothing about how it happened suggests it was the last time.
Keeping a second vendor’s model wired into your workflow costs nothing extra, because the review habit above already requires one, and the redundancy arrives as a side effect of reviewing properly.
The only benchmark that matters
METR ran a randomized controlled trial with 16 experienced open-source developers on 246 real tasks, in repositories they already knew well. With AI tools they worked 19% slower, and came away believing they had worked 20% faster. Economists asked to forecast the result predicted 39% faster; machine-learning experts predicted 38%. Everyone was wrong in the same direction, including the people who had just done the work and could have looked at the clock.
So your own sense of which model is helping is not evidence, and neither is ours. Everything here is what we have found and what the evidence currently supports, dated and sourced so you can check it rather than take it on trust. The only way to know which of these models is right for your codebase is to run them against your codebase, with a test you actually trust, and count.
ideius takes no referral fees, reseller margin, or partner money from OpenAI or Anthropic, and earns exactly the same whichever one you pick. A table that tells you to buy from two vendors is only worth reading from someone who sells neither.
If you want a second opinion on how your team is using these tools, that is a conversation we are happy to have.