Kimi K3 vs DeepSeek V4 Flash: The Widest Gap in Open Weights

This is the widest spread available in open weights right now. Kimi K3 activates roughly 104B parameters per token and lists at $3 per million input and $15 per million output. DeepSeek V4 Flash activates about 13B and lists around $0.14 and $0.28.

Eight times the active parameters, and a price difference well past an order of magnitude on output. Both ship 1M-token context windows, so this is a pure capability-versus-cost comparison with no confounders.

What the money buys

K3 is the strongest open-weight model available as of August 2026: 88.3 on Terminal-Bench 2.1, 81.2 on FrontierSWE, around 57 on the Artificial Analysis Intelligence Index, and first place on Arena Frontend Code at 1,679 in blind developer voting.

Those measurements share a bias, and naming it is the key to this whole comparison. They mostly evaluate long, unattended, multi-step work. That is where a stronger model compounds, because each step's output becomes the next step's input and per-step error multiplies rather than averages.

On a single bounded question, the gap is much narrower than the price suggests. Ask both to explain a stack trace, write a regex, or convert a schema, and you will often not be able to tell which answered.

What Flash is genuinely for

Work where the difficulty is volume, not depth.

The 1M window at $0.14 per million input tokens makes reading nearly free. Loading an entire subsystem to answer "where is this behaviour implemented" costs cents. Doing the same through K3 costs enough to think about, for an identical answer.

• Repository search and triage. Huge input, shallow reasoning.
• Log analysis. Large windows, pattern spotting. Reduce first — LLM for log analysis covers why you should not feed raw logs to anything.
• Bulk classification and extraction. Thousands of low-difficulty items where the price ratio dominates.
• First-pass filtering. Flash reads everything and decides what deserves K3.

Where Flash falls over

Long agentic runs, and the failure is structural rather than incidental.

A model that is somewhat worse per step is dramatically worse across twenty steps. Multiply a per-step success rate by itself twenty times and small differences become large ones. This is exactly what Terminal-Bench measures and exactly where K3's lead is largest.

The practical warning: Flash can look fine in a short trial and fail badly in production, because trials are short and production is not. Evaluate it on your longest tasks, not your typical ones.

Licence asymmetry

DeepSeek V4 Flash is MIT. Fine-tune, redistribute, sell inference on it, ask nobody.

Kimi K3's weights are published but under Moonshot's own terms, with a separate agreement required for model-as-a-service businesses above a revenue threshold. That gate appears precisely when your product succeeds, which is the worst time to discover it. Open weights vs open source covers the distinction.

The routing case is unusually strong here

When two models differ this much in price, routing between them stops being an optimisation and becomes the obvious architecture.

Default everything to Flash. Escalate to K3 on a mechanical trigger — a failing test, a turn-count ceiling, a schema validation error, an explicit low-confidence signal. On a workload with many easy tasks and a minority of hard ones, which describes most engineering work, this captures most of K3's capability at a small fraction of the spend.

Two things to get right. Make the trigger mechanical rather than a judgement call, because judgement drifts. And instrument the escalation rate from day one — the standard failure is that everything escalates, you pay K3 prices plus Flash latency, and nobody notices for a month.

Model routing and fallbacks covers implementation; agent cost control patterns covers keeping it honest.

Deciding

• Retrieval, triage, bulk work — Flash. The capability gap barely registers and the price gap is enormous.
• Long unattended agents — K3. Completion rate is what you are buying.
• Commercial inference product — Flash, for MIT, unless K3's capability is genuinely load-bearing.
• Mixed workload — both, routed. This is the common answer.

Measure cost per completed task rather than price per token. A model twenty times cheaper that needs three attempts is still far cheaper. A model twenty times cheaper that silently returns a plausible wrong answer is not cheap at all, and the difference between those two cases is whether your pipeline can detect failure.