Routing AI models by coding task means matching the model to the shape of the work, which is why the best AI for code review is not the best AI for SQL, and neither is the best model for agentic multi-step work. Four properties of the task decide it: how much context it needs, whether a plan has to survive many steps, whether being wrong is cheap, and what it costs to find out you were wrong.
The most expensive model I used last quarter was the cheap one. Not on any invoice line. It was a schema-heavy query I sent to the fast tier, and it came back plausible. It ran. It returned rows. The join fanned out on a one-to-many I had forgotten about, and the number went into a document other people read for a week before anyone checked it.
The separate "best AI for X" pages this one replaces never explain why that happens, because each answers its question by restating a general capability ranking. The property that decided that query was not reasoning depth or context length. It was that a wrong answer looked exactly like a right one.
Four Properties, Not One Ranking
There are live, well-defended rankings of raw model capability, and this is not one. Artificial Analysis maintains an intelligence index across nine evaluations; LLM Stats tracks a few hundred models with hourly pricing refreshes. Use those for which model is smarter. They will not tell you where to send a code review, because smarter is not the axis. Four properties are, and they belong to the task, not the model.
Context appetite
How much surrounding code has to be in the window before the first token is worth anything. A diff review needs the diff and the call sites it touches. A utility function needs the function.
Plan persistence
Whether an intention has to survive many steps. Most coding tasks are one shot: you get an answer, you judge it. Agentic work is not, and it is the only row where this is high.
First-try pressure
What it costs to be wrong once. If a failing test tells you immediately, being wrong is nearly free. If a human already read the output and moved on, being wrong once is the whole cost.
Verification cost
How expensive it is to find out the output was wrong. This is the one nobody writes about and the one that actually decides the routing. Where errors announce themselves, route down and iterate. Where a wrong answer is indistinguishable from a right one, route up, because you have no cheap detector and you are paying the model to be it.
Those last two look like one property and they are opposites: debugging has near-zero verification cost, code review has the reverse.
Verification cost is also the only one of the four you can move. Context appetite and plan persistence belong to the task, and first-try pressure is set by who reads the output. But a task with no cheap detector can be given one, which is the premise Autonoma is built on: end-to-end tests derived from your codebase and run against the running application turn a silent failure into a failing check. Build that layer and rows start migrating down a band, which is a cheaper win than any model upgrade on this page.
Tiers, not versions, because names age out and the grid does not. Two rows are all-high and route to the flagship without argument. The interesting rows are the split ones, where first-try pressure and verification cost disagree.
The Routing Matrix
Tiers rather than product names, on purpose: names change monthly, the grid does not, and the current names sit in one dated block near the end so only one part of this page can rot. Four bands, by input price per million tokens: budget under $1, cheap $1 to $2, mid $2 to $5, flagship $5 and up. Where the prose below says cheap tier, it means the bottom two together.
| Task | Route to | Why the task forces it | Cost tier |
|---|---|---|---|
| Code review | Flagship reasoning | No cheap detector for a missed bug | High, small volume |
| Debugging | Any tier, better evidence | The failing test is a free oracle | Low, many runs |
| SQL and data work | Mid tier, large window | Schema volume, not reasoning depth | Mid, input-heavy |
| Python feature code | Mid tier | No compiler to catch model errors | Low |
| JavaScript and TypeScript | Cheap tier if typed | The type checker verifies for free | Low |
| RAG and retrieval | Cheap tier | Retrieval quality dominates the model | Low per call, high volume |
| Agentic multi-step | Flagship reasoning | Per-step errors compound | Highest, and worth it |
The rest of this article is the "why" column at full length, because a matrix whose reasons are adjectives is just a horoscope with a table border.
Why the Best AI for Code Review Is Never Your Cheapest Model
The best AI for code review is the most capable model you have access to, and not because review is intellectually harder than writing code. It is because review is the only task on the matrix carrying high verification cost and high first-try pressure at once.
A clean review looks like this: the model reads a diff and reports nothing. A lazy review looks identical. No failing test, no red squiggle, no stack trace, so the absence of a finding says nothing about whether the model looked.
That asymmetry inverts the cost math. Review is cheap in tokens: a diff plus the call sites it touches, once per pull request. You are not buying throughput, you are buying the one shot. Flagship rates on a 400-line diff cost cents; missing a transaction that opens on the happy path and never commits on the error path costs an incident. The failure mode on cheaper review runs is confident silence on the interesting part of the diff, paired with three notes about naming.
This is also the row where a second detector pays for itself fastest. A review that missed the transaction opening on the happy path stays silent. A test that walks the error path does not. Autonoma covers that second half by exercising the running application instead of reading the diff, which is why routing review to the flagship tier and verifying behavior afterward are not competing choices.
One boundary: this row is which model to point at a review, not which review product to buy. For the tooling layer that files comments on your pull requests, see AI code review tools. The routing advice holds there too, since most of those products let you pick the model underneath.
Debugging Is the One Task With a Free Oracle
The best AI for debugging is whichever tier you already pay for, because debugging is the one task that ships with a free verifier. Being wrong costs nearly nothing, so route it to the cheap tier and iterate.
So the honest answer here is not a model at all. Most bad debugging sessions are input problems wearing a model costume: people paste the file and ask what is wrong with it. The file is not the evidence. The evidence is the stack trace, the failing assertion with actual and expected side by side, the last commit that passed, and the environment variable that differs between your machine and CI. Hand a cheap model that package and it usually beats a flagship handed the file alone.
The exception is the class of bug that made you search in the first place. When the failure is a cross-file interaction (a race, an ordering assumption, a stale cache, a non-idempotent retry) the evidence is scattered across files that do not mention each other. Context appetite is high there and reasoning depth genuinely helps. Route those up, expect two or three runs, and notice how small a share of your real bugs they are.
The Best AI for SQL Is a Context Decision in a Reasoning Costume
The best AI for SQL is a mid-tier model with a large context window, because the binding constraint on a schema-heavy prompt is how much schema you can afford to pass, not reasoning depth. A two-hundred-table warehouse is tens of thousands of tokens of DDL and almost none of it touches your query, so the highest-leverage move is passing less schema, not buying a better model. Ten relevant tables with real column comments beat the whole catalog on any tier.
Then SQL splits in two, with opposite routing. This is the part that cost me the week I opened with.
Exploratory queries have a free oracle. Run it on a replica with a LIMIT, read the EXPLAIN, sanity-check the row count. Wrong answers announce themselves. Iterate on the cheap tier, cheerfully.
Queries whose result a human will act on do not. A join that silently fans out on a one-to-many returns a number, not an error. Same shape as the review problem: plausible and wrong is indistinguishable from plausible and right until someone recomputes it. Anything headed for a dashboard or a billing calculation belongs on the flagship tier, with an instruction to state its grain assumptions so you have something to check.
Same dialect, opposite routing. The dividing line is who reads the output, which is why the best LLM for SQL is really two answers wearing one name.
The Best AI for Python and the Best AI for JavaScript Are the Same Model
Language moves the routing less than anything else here, and where it does, the mechanism is not the one people expect.
Python has the densest representation in every model's training data and the loosest verification story in your repo. Models write fluent, idiomatic Python and nothing checks them until runtime, so a wrong type flows three functions before it raises. The best AI for Python is therefore a mid-tier model plus tests, and if the choice is a bigger model or an hour on the test that would have caught it, spend the hour.
TypeScript is the mirror image: slightly thinner training representation, and a compiler that catches a whole category of model error before you run anything. Wrong shape, missing field, nullable dereference, all free and instant. That is a verification-cost collapse, so you can route TypeScript down a tier and let tsc do the first review pass. Untyped JavaScript loses that and sits with Python.
A repo with strict types and fast tests runs one tier cheaper than a repo without them, in any language. Investing in your verification layer is a model-routing decision.
That is the movable property from the properties section, applied. Every oracle you add pulls a row down a band, and behavioral end-to-end tests are the one that reaches the rows a compiler cannot: the wrong-looking-right feature change, the query that returns a plausible number.
Your Retrieval Matters More Than the Best LLM for RAG
The best LLM for RAG is usually the cheapest one that reliably follows a grounding instruction. This row is about picking a model to build a retrieval feature, not to test one, and within that pipeline the model is the last and cheapest lever: hand it the wrong five chunks and no model saves you, hand it the right five and a cheap model reads them fine.
The economics agree. RAG is a per-request cost at production volume with a long stuffed prompt, so input price dominates in a way it never does inside an editor. Reserve the flagship tier for a synthesis or judging step, where one output gets read once and trusted.
Agentic Work Is the Only Row Where Paying Up Is Obvious
The best model for agentic coding is the flagship tier, and this is the one row where that is arithmetic rather than a judgment call.
The model holds an intention across many steps while its own earlier output becomes its input, and per-step errors do not average out: they compound. A three percent chance of going wrong on any single step, over twenty steps, is a forty-six percent chance the run is wrong somewhere. Halving the per-step error rate roughly halves the chance of a wasted run, worth far more than the token gap between tiers.
The cheap-model-is-expensive dynamic is at its most brutal here. A model that loses the plan on step twelve does not cost you step twelve. It costs the twelve steps you already paid for, the time to find where it drifted, and a diff you now read with suspicion. I have paid for a cheap agentic run four times and then paid for the flagship anyway.
So: flagship tier, largest context you can feed it, stop optimizing this row. The same reasoning picks the best LLM for agents generally, not just coding agents, since anything chaining tool calls pays the same compounding penalty. Which model inside a given harness is tool-specific: Copilot's dropdown is in GitHub Copilot models, Cursor's in best model for Cursor. Still choosing a harness? Start with AI coding agents.
Where the Task Matters Less Than the Context Handling
Past a certain point, how your tool assembles and truncates context matters more than which model sits behind it. That is the part those pages will never tell you, because it undercuts the premise of having a separate page per task.
Every flagship and mid-tier model now advertises roughly a million tokens. Nobody feeds them a million tokens. The tool decides what enters the window: which files it retrieves, what it summarizes, what it drops when it compacts a long session. Point two tools at the same model and the same repo and you get different answers, a gap routinely wider than the one between two models in the same tier.
The horizontal axis is how much of the codebase the task actually needs. Below the crossover, the matrix above is the highest-leverage thing you can change. Above it, you are tuning the wrong knob, and a bigger dropdown will not help.
A large window is also not always a cheap one, and the vendors disagree about this more than anything else on their price lists. OpenAI charges a long-context rate on all three GPT-5.6 variants at double the input price and half again on output, without publishing the token count where it starts. Google is explicit: Gemini 3.1 Pro goes from $2 to $4 input and $12 to $18 output above 200k tokens. Anthropic bills its full 1M window at the standard rate, noting a 900k-token request costs the same per token as a 9k one. So the big window carries a price tag from two vendors and none from the third.
One live example of why everything here is attributed. A popular aggregator lists Gemini 3.5 Flash at $0.75 and $4.50 per million tokens. Google's own page lists $1.50 and $9.00 standard, with $0.75 and $4.50 as the batch rate. The aggregator published the batch price as the standard, so routing on it puts your cost model off by two.
Current Names and Prices, Verified August 5, 2026
The perishable part, quarantined so it is easy to re-check. Every figure comes from a first-party pricing or model page fetched on the date in this heading, and it is a price list, not a capability ranking.
| Band | Models on it | Input / output per 1M | Source |
|---|---|---|---|
| Flagship, $5 and up | Opus 5, GPT-5.6 Sol, Claude Fable 5 | $5 / $25, $5 / $30, $10 / $50 | Anthropic, OpenAI |
| Mid, $2 to $5 | Sonnet 5, GPT-5.6 Terra, Gemini 3.1 Pro | $2 / $10, $2 / $12, $2 / $12 | Anthropic, Google |
| Cheap, $1 to $2 | Haiku 4.5, Gemini 3.5 Flash | $1 / $5 and $1.50 / $9 | Anthropic, Google |
| Budget, under $1 | GPT-5.6 Luna, Gemini 3.5 Flash-Lite | $0.20 / $1.20 and $0.30 / $2.50 | OpenAI, Google |
| Long-context surcharge | GPT-5.6 long context, Gemini over 200k | 2x input, 1.5x output; $4 / $18 | OpenAI, Google |
| No surcharge to 1M | Claude 4.6 and later | Standard rate at any length | Anthropic |
Three caveats. Sonnet 5's $2 is introductory pricing that rises to $3 on September 1, 2026, which means the mid band is a three-way tie at $2 until then and stops being one after. Gemini 3.1 Pro is still labeled a preview, and Gemini 3.5 Pro has no published price or context window at all. And every Claude model above except Haiku 4.5 shares the tokenizer introduced with Opus 4.7, which Anthropic notes produces roughly thirty percent more tokens for the same text. That leaves the Claude rows comparable to each other, and it means a per-token price is not the same unit when you compare them against Haiku 4.5 or against the OpenAI and Google rows.
How to Actually Use This
Do not adopt a winner. People who do this daily keep several models in rotation and switch without ceremony. The matrix describes that habit rather than replacing it. For the general category verdict and why the benchmark numbers disagree with each other, see best LLM for coding.
The rule that survives the next release cycle is short. Flagship tier for code review and agentic runs. Mid tier for SQL and everyday feature code: less schema, more tests. Cheap tier for retrieval-heavy production paths, where retrieval is the lever anyway. Past the crossover, stop shopping for models and go fix how your tool assembles context.
Then the limit of all of it. Routing by task improves the odds on the diff. It says nothing about whether the running application still works, and no model choice ever will, because the model reasons about code while your users experience behavior. That is the layer Autonoma works on: it derives behavioral end-to-end tests from your codebase and runs them against the running app on every pull request. Pick the model for the task. Verify the app regardless of which one you picked.
Frequently Asked Questions
For low-stakes work, yes, and it is a reasonable default for inline completions and quick questions. Auto modes route on cost and load, not on the properties that matter here, so they will not know that your SQL query is headed for a board slide or that this pull request is the one nobody will review twice. Override it manually on the two rows where verification cost is high, code review and agentic multi-step runs, and let Auto handle the rest. That is roughly a handful of deliberate choices a week rather than a decision on every prompt.
Only past the crossover point, and less often than the marketing implies. Every flagship and mid-tier model now advertises around a million tokens, but the tool decides what actually enters the window, so a bigger ceiling does not help if the retrieval step is still handing over the wrong files. It is also not free: OpenAI's own pricing page lists a separate long-context rate for all three GPT-5.6 variants at roughly double the standard rate. Pay for the big window when the task genuinely spans a package or a repository. Below that, fix what you are sending instead.
Yes, and it is the single biggest asymmetry on this matrix. In chat you are the verifier: a bad answer is obvious, you rephrase, and being wrong costs one round trip. In review the model is the verifier, and a review that found nothing looks identical whether the diff was clean or the model was lazy. There is no failing test to tell you. That is why review is worth flagship rates even though it is cheap in tokens, and why chat is perfectly well served by a mid or cheap tier.
When something other than you can catch the mistake. A failing test, a type checker, an EXPLAIN plan, a linter, a query you can run on a replica with a LIMIT: each of those is a free oracle, and each one makes iterating on the cheap tier strictly better economics than one expensive attempt. The inverse is the real rule. When nothing but a human reading carefully will catch the error, the cheap tier is a false saving, because you pay the flagship price anyway on the second attempt plus the cost of the first.
The three modes have completely different context and latency budgets, which is why the same model behaves differently in each. Inline completions need an answer in tens of milliseconds and see a small window around your cursor, so they are the clearest case for the cheap tier regardless of task. Chat sees what you paste plus whatever the tool attaches. Agent mode sees files it fetched itself, over many turns, and it is the only one where an error on an early step corrupts every step after it. Route by mode first and by task second, because a flagship model behind a completions endpoint mostly buys you latency you do not want.
Yes, and it is the highest-leverage move on this matrix. Verification cost decides most of the rows, so anything that gives a task a cheap oracle lets you route it a band down: a type checker does that for TypeScript, a failing test does it for debugging, an EXPLAIN plan does it for exploratory SQL. Behavioral end-to-end tests do it for the rows nothing else reaches, which is feature work and anything whose output a human will act on. That is what Autonoma builds: it derives end-to-end tests from your codebase and runs them against the running application on every pull request, so a task that needed the flagship tier because a wrong answer was undetectable now has something other than you doing the detecting.
It's one that validates the diff the same way no matter which model tier produced it. This article's routing matrix picks a flagship, mid, or cheap model based on the task, but that choice only changes the odds a diff is correct, it never confirms the running feature actually works. Autonoma acts as an AI-native QA layer underneath any routing decision: it reads your codebase, generates behavioral end-to-end tests, and executes them against your live application on every pull request, catching regressions whether the change came from a flagship model handling code review or a cheap model handling a mechanical edit.
