“What’s the best AI for coding?” has a real answer, and it changes about once a month as new models ship and the leaderboards reshuffle. Here is what the data shows as of writing, and why the ranking matters less than it looks.
What the data shows right now
The most informative public test we’d point to is DeepSWE, a coding benchmark from Datacurve built to separate frontier models. Its tasks are written from scratch rather than scraped from public GitHub, so a model can’t have trained on the answer; it spans 91 repositories across five languages; and it grades behavior rather than one specific implementation.
As of June 2026, the top of that leaderboard looked like this:
| Model (as of Jun 2026) | DeepSWE pass rate | Cost per task |
|---|---|---|
| claude-fable-5 | ~70% (±4%) | ~$22 |
| gpt-5.5 | ~67% (±6%) | ~$7 |
| claude-opus-4.8 | ~59% (±2%) | ~$13 |
| gpt-5.4 | ~52% (±2%) | ~$6 |
New models land as they ship, so treat this as a snapshot, not a verdict; the current order is on the live leaderboard. The short version: two or three frontier models are out front, and they finish close enough that the gap needs a second look.
The top of the leaderboard is usually a tie
Look at the error bars, not the ranking. The two leaders above, at roughly 70% (±4%) and 67% (±6%), overlap. Statistically that is a tie, not a first and second place. A three-point “lead” inside a five-point band tells you almost nothing, and a benchmark that omits its confidence intervals is closer to marketing than measurement.
This is the whole reason DeepSWE exists. Its authors note that the leading public benchmarks have started to saturate: frontier models bunch up in a narrow band where adjacent models sit inside each other’s intervals. On the older SWE-Bench Pro, the spread from worst to best frontier model was about 30 points; on DeepSWE it is about 70. A benchmark that can’t separate models can’t rank them, however confident the order looks on the page.
The ranking is shakier than it looks
Even the scores that are separated rest on two things people rarely check: whether the model has seen the answer, and whether the grader is right.
Contamination. When a benchmark is adapted from public GitHub issues and pull requests, the fix, its tests, and the discussion are already online, so a high score can reflect recall rather than problem-solving. DeepSWE’s audit of a rival benchmark found this in the wild: some test containers shipped the project’s full git history, and agents ran git show to read the merged fix and paste it in. DeepSWE’s own tasks are written from scratch, never merged upstream, and shipped in shallow clones, with a canary string that should never appear in a training set.
The grader can be wrong. A benchmark is only as good as its verifier, and many reuse the original pull request’s tests as the grader. Those can pass stubbed-out solutions and fail valid alternative ones. When DeepSWE re-judged a rival benchmark’s results with an independent reviewer, it disagreed with the autograder on roughly a third of trials.
One caveat, in fairness: DeepSWE is itself a benchmark, built by a company that competes in this space, so weigh its critique of a rival accordingly. But the failure modes it documents are well known, and the lesson outlives any single leaderboard: a benchmark score is an estimate, with error bars on both the measurement and the grading.
Price doesn’t track skill
Pass rate hides what a model spends to get there. Across these agents, cost, output tokens, and runtime per task each vary by an order of magnitude — and none of them correlates strongly with accuracy. In the snapshot above, the most accurate model also costs roughly three times the runner-up that lands within a few points of it.
That changes the answer to “best.” For a high-stakes, low-volume task, paying for the top model is easy to justify. For a high-volume workflow like triaging tickets or drafting routine changes, a model at a fraction of the cost that scores a few points lower is often the better business decision. What tips the math is the failure tax: a model’s wrong answers cost real time to fix, so a cheaper, less accurate model can quietly cost more than a pricier, reliable one. Putting a number on that is the next piece.
The benchmark still isn’t your codebase
The limit that matters most, which DeepSWE states plainly in its own write-up: it draws from active open-source repositories with at least 500 stars, in five languages, on long-horizon feature work. That is a strong proxy for general capability. It is not your proprietary code, your conventions, your dependencies, your definition of “done,” or the work your team actually hands an agent all day.
A public leaderboard is a screen, never the decision. The only comparison that should pick your model is one you run on your own work — the same principle as evaluating any AI vendor before you buy: don’t trust the demo, run a pilot on your own data.
How to actually compare models for your work
- Shortlist from the leaderboard, then stop trusting it. Take the top two or three and ignore the rest of the ranking.
- Read the error bars. If two models overlap, treat them as tied and decide on other grounds.
- Test on your own tasks. Run the shortlist against your real tickets and your messiest edge cases — not the benchmark’s — and check the failures, not just the pass rate.
- Price the decision. Weigh cost and speed against accuracy for your volume and stakes.
- Re-run it. Model behavior changes with every release and every silent update; a comparison is a snapshot, not a one-time purchase.
Where we stand
We don’t sell models and we take no fees from the labs, so we have no stake in which name leads this month. We build the comparison that actually decides it: a small evaluation harness drawn from a team’s own work, so the choice rests on evidence from your codebase rather than someone else’s leaderboard. That is evidence over enthusiasm applied to the question we get most. The honest answer to “what’s the best AI for coding?” is almost always “the one that wins on your tasks, measured the same way twice.”