How to Pick the Best LLM for Coding Without a Leaderboard

There is no best LLM for coding, and any page that answers the question with one model name is selling something. What exists is a small set of columns that decide the answer for your workload, and a much larger set of columns that look decisive and are not. This piece is about telling them apart, using numbers pulled from the vendors' own pages on 29 July 2026.

Every figure below carries the date it was read, because these change monthly and a table without a date is a table you cannot audit, the same discipline behind our datestamped decision grid comparing Claude and ChatGPT. If you are reading this later, re-check the two price columns first. They move most.

What does the table look like today?

Here is the comparison, assembled on 29 July 2026 from each vendor's published pricing. Prices are per million tokens, standard tier, no batch discount applied.

The Claude figures come from Anthropic's pricing documentation, which also states the Sonnet 5 introductory rate of $2 and $10 runs through 31 August 2026 before standard pricing of $3 and $15 takes effect. Gemini numbers are from Google's Gemini API pricing page. DeepSeek's cache hit and miss split is published on its own pricing docs, and GLM-5.2 sits at $1.40 and $4.40 on the Z.ai pricing overview. For GPT-5.6 Sol, OpenAI's own pricing page returned an error both times we tried it on 29 July 2026, so the $5 and $30 figures come from the OpenRouter model page, which also records a 9 July 2026 release date and a 1M context window. Treat that row as one step further from the source than the others.

Why do the leaderboard and your own experience disagree?

Because the leaderboard is not measuring the model on its own. It is measuring the model plus the scaffolding around it, and the scaffolding is doing more work than most readers assume.

The clearest statement of this comes from a June 2026 position paper by Maria I. Gorinova and colleagues, revised on 18 July 2026, arguing that coding benchmarks are misaligned with agentic software engineering. Their central claim is that benchmark scores conflate the model with the rest of the harness, and that components other than the language model can shift performance by amounts equivalent to the progress between model generations. If that is true, then a two point gap between two models on a leaderboard tells you nothing at all unless both ran inside the same harness, which is why our guide to choosing an AI coding assistant weighs where a tool runs and whether it executes what it wrote ahead of any leaderboard row.

How much variation is there between harnesses? Benjamin Rombaut's April 2026 source code survey of thirteen open source coding agent scaffolds gives a sense of the spread. Tool counts range from zero to thirty seven. Seven distinct context compaction strategies appear across the thirteen. Eleven of the thirteen combine more than one control primitive rather than running a single loop. Those are not cosmetic differences. A model handed thirty seven tools and one handed four are doing different jobs.

The second problem is who produced the number. The SWE-bench leaderboard runs on submissions: teams evaluate their own system, then open a pull request to the SWE-bench experiments repository with predictions, metadata and reasoning traces. The verified designation is a separate, optional step where maintainers re-run the submitted system on a random subset. So the default state of a leaderboard row is self reported, and the badge tells you a spot check happened, not that the full run was reproduced.

None of this means the benchmarks are worthless. It means the benchmark column belongs at the right hand edge of your table, read as a rough tier signal, and never used to separate two models that landed within a few points of each other. If you want the longer version of that argument, we walked through what the SWE-bench Verified subset actually measures and where it stops in a separate piece.

Is a cheaper price per token actually cheaper?

Not reliably, and the reason is buried in a footnote on Anthropic's pricing page rather than in anyone's comparison table.

That page states that Claude 4.7 and later models, along with Claude Mythos Preview, use a newer tokenizer which produces approximately 30% more tokens for the same text than the previous one. Claude Sonnet 4.6 and earlier use the old tokenizer. The exact increase depends on the content.

Sit with what that means for a price comparison. Claude Opus 5 and GPT-5.6 Sol both list $5 per million input tokens. If you paste the same 400 line TypeScript file into each, the Anthropic model may count meaningfully more tokens for that identical file. The per token price is equal. The per file price is not. Every table on the internet that ranks models by dollars per million tokens, including the one above, is quietly assuming a token is a token across vendors, and the vendor's own documentation says otherwise.

The fix is not complicated, it is just work: run your actual prompt through each vendor's tokenizer and compare token counts, not prices, then multiply. For a code assistant where the prompt is dominated by file contents, this correction can flip the ranking of two adjacent rows.

Where does the context window stop being free?

Three of the models in the table treat long context differently, and the difference is worth more than a dollar of headline rate.

Anthropic's page says Claude 4.6 and later include the full 1M token context window at standard pricing, and spells out the consequence: a 900k token request is billed at the same per token rate as a 9k token request. Google's page prices Gemini 3.1 Pro Preview at $2 input and $12 output up to 200k tokens, then $4 and $18 above it. Reporting on GPT-5.6 Sol describes a similar step, from $5 and $30 to a higher tier once input passes roughly 272k tokens.

For a coding agent this is not an edge case, it is the normal case. Long sessions accumulate. A repository map, a few large files and forty turns of history will cross 200k tokens on any real codebase before lunch. If your workload lives above the threshold, a model that looked 60% cheaper on the headline row can end up more expensive than the one that did not have a cliff at all.

The habit worth building is to write down where each candidate's price changes and compare at your actual context length, not at zero.

How much do tool calls add?

More than nothing, and the amount changes between models from the same vendor in a way that has nothing to do with capability.

Anthropic publishes the per model token cost of the system prompt that gets injected whenever any tool is present. On Claude Opus 5 it is 286 tokens with a tool choice of auto or none, and 406 with any or tool. On Claude Opus 4.7 the same overhead was 675 and 804. On Opus 4.6 it was 497 and 589. The overhead more than halved between 4.7 and 5, which is a larger relative swing than the gap between several vendors' base rates.

On top of that sits the size of your own tool schemas, every tool result you feed back, and for the bash tool another 325 tokens on Opus 5 just for the definition. None of this is exotic. It is simply input, charged on every turn of the loop, and a table that stops at the base rate never shows it.

If you are wiring tools through a protocol layer rather than hand rolling them, the accounting is the same but the surface is cleaner. We covered the mechanics of that in a walkthrough of standing up a tool server and pointing an assistant at it, and the MaShop MCP server page describes the tools we expose on the same protocol.

What about caching, and why do the discounts differ so much?

Caching is the single largest lever on a coding workload, because a coding agent re-sends an enormous, almost identical prefix on every turn. What differs across vendors is not whether they offer it but how aggressively they price it.

Anthropic uses multipliers relative to the base input rate: a five minute cache write costs 1.25x, a one hour write costs 2x, and a cache read costs 0.1x. The page draws the conclusion for you, noting that the five minute cache pays for itself after a single read and the one hour cache after two.

DeepSeek's structure is far steeper. Its published rate for V4 Pro is $0.435 per million tokens on a cache miss against $0.003625 on a hit. That is roughly a factor of 120, against Anthropic's factor of 10. For a workload where the prefix is stable and reused constantly, that ratio matters more than either vendor's headline number.

Does the output price matter more than the input price?

For coding work, usually yes, and by a wider margin than the ratio in the table suggests.

Every model here charges more for output than input, typically five or six times more. Anthropic's own worked example makes the shape concrete: a one hour session on Claude Opus 5 consuming 50,000 input tokens and 15,000 output tokens bills $0.25 for input and $0.375 for output. The input side is more than three times larger in token count and still costs less than the output side. Turn on caching so that 40,000 of those input tokens become cache reads and the input line drops to $0.07 in total while the output line does not move at all.

That is the whole cost structure of a coding agent in two lines. Input is compressible through caching. Output is not. Anything you can do to make the model write less, tighter diffs instead of whole files, targeted edits instead of rewrites, is a direct saving that no pricing tier will give you.

It also reframes which column to weight when two candidates are close. Between Claude Opus 5 at $5 and $25 and GPT-5.6 Sol at $5 and $30, the input rates are identical and the output rates differ by 20%. On a workload that is mostly generation, that 20% is the entire difference, and it is larger than it looks because output is where the money already sits.

So which one should you actually use?

The honest answer depends on which of four shapes your work has, and none of the four is settled by a leaderboard.

If your workload is long agent sessions over a large repository, the cliff free 1M context and the 10% cache read on Claude Opus 5 or Sonnet 5 are worth more than a lower base rate, and Sonnet 5 at the introductory $2 and $10 is the cheapest capable option in the table until 31 August 2026, a rate that reads differently once you have seen how Sonnet 5 narrows the gap to Opus on agentic work. If your workload is high volume and repetitive with a fixed prefix, DeepSeek V4 Pro's cache economics are hard to argue with. If you need open weights so you can run the thing yourself, GLM-5.2 at $1.40 and $4.40 is the value row, and the reasons to care about weights you can hold are covered in our piece on how open weight models stack up against frontier releases. If you are already inside Google's stack, Gemini's sub 200k pricing is competitive, provided you genuinely stay under 200k.

What no table can tell you is the last variable, and it is the one the research keeps pointing at: how well the model fits the loop you run it in. Two candidates, your real task, your real harness, run twice each. That experiment costs a few dollars and beats every ranking on the internet, because it is the only one measuring the system you are actually going to ship.

How should you keep this table current?

Set a reminder for the first week of September 2026, because Sonnet 5's introductory pricing ends on 31 August and one row in the table above becomes wrong that day. Beyond that, re-read the two price columns and the context cliff each quarter, and treat everything else as stable.

Keep the vendor page as the source, never a secondary tracker, and write the date next to the number. The exercise of maintaining that discipline is roughly the same one we apply to our own credit pricing and what a build actually consumes, and it is the reason we would rather show the arithmetic than a badge. A number without a date is a claim, not a fact.

One last thing worth saying plainly. Model quality on coding tasks is converging fast enough that price, context behaviour and harness fit now decide more real outcomes than raw capability does for most teams. If you are choosing between the top few models in July 2026, you are mostly choosing a billing structure. Pick the one whose billing structure matches the shape of your work, and revisit it when the shape changes.