Short version: Kimi K3 is the cheapest and the only open weight of the three, and it genuinely topped one coding leaderboard. Claude Opus 4.8 still wins the hardest real-repository test. GPT-5.6 Sol owns terminal-driven work. So the move isn't to crown one model — it's to route each kind of task to the model that's cheapest for the quality you need. Here's the math.
The three models, on one price card#
On July 16, Moonshot AI shipped Kimi K3 — a ~2.8-trillion-parameter open-weight mixture-of-experts model (896 experts, 16 active per token, 1M-token context). It took #1 on LMArena's Frontend Code leaderboard at 1,679 points, ahead of Claude Fable 5, in blind developer voting. Full open weights are slated for July 27, which makes it the only one of these three you can eventually self-host.
The two closed incumbents haven't moved on price. Here's the whole decision on one card:
| Kimi K3 | Claude Opus 4.8 | GPT-5.6 Sol | |
|---|---|---|---|
| Weights | Open — full drop July 27 | Closed | Closed |
| Input $/M | $3.00 ($0.30 cache-hit) | $5.00 | $5.00 |
| Output $/M | $15.00 | $25.00 | $30.00 |
| Frontend Code Arena | #1 · 1,679 | behind K3 | behind K3 |
| SWE-bench Pro (real repos) | trails* | 69.2% | 64.6% |
| Terminal-Bench 2.1 | — | 78.9% | 88.8% |
\On Moonshot's own evaluation suite, K3 tops GPT-5.5 and Opus 4.8 across coding/agentic benchmarks, but Moonshot concedes it still sits behind Fable 5 and GPT-5.6 Sol on overall performance. Independent SWE-bench Pro numbers for K3 weren't published at press time.*
Why output price is the number that matters#
Coding agents are output-heavy. A single task reads a few files and writes diffs, tests, explanations, retries — the bill is dominated by output tokens, not input. That's exactly where Kimi K3 is cheapest: $15/M output vs Opus 4.8's $25 and GPT-5.6 Sol's $30. On a token-heavy generation task, K3 lands roughly 40-60% cheaper per completed task than either closed frontier model, before you even count its $0.30/M cache-hit input rate.
What it means: if your agent is grinding through frontend components, boilerplate, refactors, and codegen where the output is large and the problem isn't at the frontier of difficulty, K3 is the obvious router target. The savings compound with volume.
Where the closed frontier still earns its price#
The Frontend Arena win is real but narrow — it's blind preference voting on frontend code, not a rigorous fix-the-bug harness. On SWE-bench Pro, which grades whether a model actually resolves real issues in real repositories, Claude Opus 4.8 leads at 69.2% versus GPT-5.6 Sol's 64.6%, and Moonshot itself places K3 behind the closed frontier on overall performance.
For terminal-driven agentic work — an agent living in a shell, running commands, reading output, iterating — GPT-5.6 Sol tops Terminal-Bench 2.1 at 88.8% against Opus's 78.9%. Different job, different leader.
What it means: the hard, expensive-to-get-wrong tasks — multi-file bug fixes on a production repo, long terminal loops — are exactly where paying $25-30/M output buys you fewer failed attempts. A cheaper model that needs three tries to land a fix isn't cheaper.
The actual decision: a router, not a winner#
Don't switch your whole agent to any one of these. Route by task:
- Frontend + high-output-token bulk → Kimi K3. Take the 40-60% output-cost cut where the difficulty is moderate and the volume is high.
- Hard repo-level fixes → Claude Opus 4.8. Top SWE-bench Pro; fewer retries on the tasks you can't afford to get wrong.
- Terminal / multi-agent orchestration → GPT-5.6 Sol. Top Terminal-Bench; best in a shell loop.
The prerequisite is architectural: make your coding pipeline model-swappable now, before K3's weights drop on July 27 and the price gap widens further with self-hosting. If your agent is hardcoded to one vendor's SDK and prompt format, you can't cost-route — and you'll leave the biggest savings of the quarter on the table. This is the same lesson the coding-agent market has been teaching all month: standardize on the stack, not the tool.
What to do this week#
- Instrument your token bill by task type. You can't route what you can't measure. Split input vs output tokens per task class.
- Pilot Kimi K3 on your highest-output, lowest-risk task class — frontend or boilerplate — and compare cost-per-completed-task, not cost-per-token.
- Keep your hardest eval set on Opus 4.8 as the quality floor, and re-test K3 against it after the July 27 weights drop and independent SWE-bench Pro numbers land.
- Abstract the model behind a router so swapping is a config change, not a refactor.
