Which AI coding model finishes your task for the least money?

A coding score from independent benchmarks

Each model gets a coding score from 0 to 100, measured independently by Artificial Analysis:

Effort level: more thinking isn't always worth it

Many models have an effort setting (low, medium, high, xhigh, max). It controls how long the model thinks before it answers. The price per token doesn't change, but a higher level uses more tokens, takes longer, and usually gets a somewhat higher success rate. For strong models the gain shrinks fast: some score best at medium, and a few get slightly worse at the top level.

So each model is ranked once, at the level with the lowest cost per finished task: past that point, the extra thinking costs more than it saves in fixes. Tap "Use at" in the table to see every level.

How much a level thinks: Artificial Analysis times every level (seconds until the answer starts × tokens per second ≈ thinking tokens). Where a model has that for two or more levels, we use the measured gap (square-rooted, since those test prompts are short). Otherwise a level gets a typical ratio: low 0.35×, medium 0.6×, high 1×, xhigh 1.7×, max 2.5× the thinking of high.

• Token use can differ up to 23× between the lowest and highest effort of the same model. Artificial Analysis
• At max effort, GPT-6 Astra uses about 27K output tokens per task and Claude Fable 5.1 about 78K, for the same score. Artificial Analysis
• Extra effort barely helps strong models (+0.6 points for GPT-5.5 from low to xhigh) but lifts weak ones much more. Digital Applied
• Claude Opus 5 scores highest on FrontierCode at medium effort. SitePoint

A coding score from benchmarks that are still being run

Artificial Analysis stopped publishing its Coding Index for new models in September 2026. It still runs the two benchmarks the index was made of: Terminal-Bench, now in its much harder version 4.0, and SciCode, at every effort level. So for a model without a published Coding Index we rebuild it the way AA built it (about ⅔ Terminal-Bench, ⅓ SciCode), on the same scale (marked ^◇):

• Terminal-Bench 4.0 is put on the old 2.1 scale, using the models AA ran on both (a harder test lowers every model's odds of passing, so the conversion is on the odds). Checked by hiding each model's published Coding Index and rebuilding it: typically within about 1.5 points.
• An effort level AA didn't run Terminal-Bench at is inferred from a higher level of the same model, by how much lower its Intelligence Index is (SciCode is still measured at that level): typically within about 3.5 points.
• No AA run at all: Vals AI's Terminal-Bench 4 run, put on AA's scale, stands in.

A rebuilt score counts as measured: it comes from the model's own benchmark results, not from other models. If AA publishes a Coding Index again, it replaces ours automatically.

Brand-new models don't wait

In a model's first days AA may not have run Terminal-Bench on it yet, though its general Intelligence Index usually appears within a day. A model released in the last 60 days with nothing to rebuild from gets a provisional estimate (marked ^*). If the release right before it in the same line was measured at the same effort level (GPT-5.6 Sol for GPT-6 Sol, say), the estimate starts from that score and adds ¾ of the coding gain that's typical for its rise in Intelligence Index. So a newer model that's at least as smart is never placed below the one it replaces, and one that's measured weaker comes out lower. We only go one step back: if that release isn't measured yet either, the estimate comes from the models with the most similar Intelligence Index. Tested the same way, by hiding recent models' real scores, it misses by about 3 to 4 points. It's replaced automatically once there's something to rebuild from, and it never sets the quality bar.

Our pick is always measured. A model whose score is still an estimate can rank by cost like any other, and it's drawn as an outline in the chart, but the wise pick is always the cheapest model whose score was actually measured. A cheaper model that's only estimated is named right under the pick, so you can try it knowing what's known and what isn't.

Except where the data is thin. When the benchmarks for a kind of work have measured fewer than 60% of the ranked models (today: production investigation, run only on ITBench), the same one or two measured models would win whatever you choose. There the cheapest model can be the pick even if its score for that work is an estimate. The card says so, with how far past estimates for that work have missed, and names the other contenders, measured or not.

And one you can get. The pick must also be on Cursor's model list or on OpenRouter. A model in neither (often a new one its maker offers only on its own API, sometimes in limited access) still ranks by cost and is marked in the table, but it is never the pick.

Your kind of work

Reading a repo, building a new API service, changing legacy code and chasing a production bug through logs and traces are different jobs. Developers spend about 58% of their time understanding code, not writing it. At Anthropic, the daily uses are debugging (55%), code understanding (42%) and new features (37%). Pick your kinds of work under "Coding tasks" and each model is scored on the benchmarks built for that work, run independently by Artificial Analysis, Vals AI, Epoch AI (data under CC BY 4.0), Scale AI and LMArena:

These benchmarks measure a success rate on that kind of task: the share of codebase questions answered correctly, of real incidents diagnosed, of repo changes that pass the hidden tests. That rate replaces the general coding score as the chance a model gets your task right first time. For LMArena WebDev, which is a rating, it's the chance developers prefer the model's web app over an average model's. When a kind of work has several benchmarks, each is put on the scale of the first one (same average and spread over the models measured on both), so a model measured only on the harder benchmark isn't penalised; its score is the mean of the benchmarks it was measured on. When several publishers run the same benchmark, the most trusted one's numbers are used as published (the benchmark's authors, or an independent lab that runs every model the same way), and another only fills in models it hasn't run, put on its scale first; a model they disagree on more than usual is flagged. A maker's own reported result is used only until an independent one exists. A model that isn't on any benchmark for that work yet is estimated, and marked "estimated" in the table (tap the mark to see what it was estimated from). If the release right before it in the same line has its own result (Claude Opus 5 for Claude Opus 5.5, say), the estimate starts from that result and adds ¾ of the model's general improvement over it, comparing each model's best coding score. So a newer, stronger model never lands below the one it improves on, and stays a little conservative until it's measured. Models of one line are trained the same way and track each other closely. We only ever go one step back: an estimate is never built on another estimate. Without a measured result right before it, the estimate comes from the fit of the benchmark on the coding score across the measured models, never above the best measured result. Whenever an estimate is later replaced by a real result, we record how far off it was, and the table shows the average miss per kind of work. When the top pick for your work is still estimated, the best measured pick is shown next to it. With nothing picked, the general coding score is used.

Why dedicated benchmarks: an earlier version mixed general benchmarks per kind of work. Checked against SWE-Atlas, the mix agreed with real codebase-understanding results at only r = 0.34, worse than the plain coding score (0.61). So each kind of work now uses benchmarks made for it. Agent-run scores (SWE-Atlas, DeepSWE from Artificial Analysis's Coding Agent Index) include the agent harness (Claude Code, Codex, Mini-SWE-Agent). Checked and left out: SWE-bench Pro V2, whose top is saturated (98%) and which, across the same models, doesn't agree with DeepSWE or Code Migration.

Only near-top models qualify

What a finished task costs you

cost per task = (an attempt's tokens + fix cost × failure chance) ÷ success chance

The cheapest model per token isn't the cheapest to work with. A weaker model gets more tasks wrong, and every miss costs you a re-prompt, a review and a fix, plus another run's tokens. We treat the coding score as the chance a model gets a task right first time (81 ⇒ 81%). Dividing by that chance counts the retries.

• What an attempt reads: 1.5M tokens, 90% from cache. An agent sends the same code and context again and again; providers bill those repeats at a cache-read price, usually a tenth of the input price. We use each model's own cache-read price from OpenRouter (10% of its input price when none is listed). Source
• What it writes: 110K tokens at "high". Set so the formula gives what Artificial Analysis measured on real agent tasks at list prices: $4.10 for Claude Opus 4.7 and $4.82 for GPT-5.5 (each alone gives 107K and 113K). What a model writes, its thinking and answer, is the part that grows with the effort level. Source
• Your hour: $93. A US software developer's median wage is about $65 an hour, and wages are about 70% of what an employer pays in total. BLS wages · BLS employer costs
• Minutes per failed attempt: 20. In 20,574 real sessions, 91.5% of problems were fixed only after the developer explicitly corrected the agent: spot it, re-prompt, re-review, about 12 minutes. The rest need hands-on work: METR measured 26 minutes to make even test-passing agent code acceptable, 42 minutes on average. Sessions study · METR
• Why this matters: 66% of developers name "almost right, but not quite" AI code as their top frustration, and 45% say debugging it takes longer. Stack Overflow 2025

Success vs tokens. The same numbers, split in two: how often a model finishes a task, and the tokens a finished task takes at list price. Most model and effort pairs are beaten on both by another one; the few that aren't make up the efficient line (the "Success vs tokens" chart above). "What matters most" picks along that line: fewest tokens, the balanced pick (the lowest cost per finished task, which is the ranking), or the most reliable. We never spend tokens on a gain we can't measure: a rebuilt score is back-tested to miss by about ±1.6 points, so "Most reliable" takes each model at its leanest level within that of the most accurate, and of those the cheapest per finished task (models within it of each other are a tie; below the top, ties go cheapest first too), not the top at any price, and so does the pick in a plan whose tokens are included (there tokens cost $0, and the top effort only uses up the plan sooner). "Fewest tokens" stays above the quality bar for the kind of work shown. The ranking and the table follow your choice too: each model is shown at the level that choice picks for it, in its order, and the pick is the first model you can get.

Cursor models

Who is left out, and why