Choosing a Coding-Agent Model in 2026

The question most engineering leaders ask — "which coding model is best?" — has no answer in mid-2026, and asking it is the first mistake. There is no single best. Claude Opus 4.7 leads most software-engineering benchmarks, GPT-5.5 is strongest on long-horizon reasoning and open-ended research, Gemini 3.1 leads multimodal and very long context, and open-weight models such as DeepSeek's latest now land close enough to the frontier that, for a large share of real work, the remaining quality gap no longer justifies the cost. The useful question is narrower: which model, for which workload, inside which harness, measured against your own tasks.

The most expensive error is optimizing the wrong number. Per-token price is printed on the pricing page, so it anchors the conversation — and it is nearly irrelevant. You do not buy tokens; you buy completed tasks. A pricier model that one-shots a multi-file change is routinely cheaper per outcome than a cheap model that loops, backtracks, and fails.

The second error is standardizing on one model and forgetting. Coding work is not one distribution. Hard multi-file changes and a long tail of mechanical edits belong on different models, routed by workload, with cascades and fallbacks rather than a single corporate standard.

The third error is trusting public leaderboards. They are contaminated, mismatched to your codebase, and computed under someone else's harness. The only number that should drive the decision is performance on an internal eval set drawn from your real backlog.

This paper lays out the dimensions that actually decide model selection, why per-outcome cost beats per-token price, how to route by workload, why a model-agnostic harness is the asset worth owning, when open weights are the right call, and a scorecard engineering leaders can apply at every release.