Kimi K3 vs MiniMax M3: The Top and the Floor

These two models sit at opposite ends of the same field. Kimi K3 is the strongest open-weight model available as of August 2026. MiniMax M3 is among the cheapest that can still be described as capable. Both ship 1M-token context windows.

Comparing them on quality alone answers nothing — K3 wins, obviously. The interesting question is how much of K3's advantage you actually consume, because you are paying for all of it either way.

What separates them

K3 activates roughly 104B parameters per token out of a 2.8T total, scores 88.3 on Terminal-Bench 2.1 and 81.2 on FrontierSWE, and sits around 57 on the Artificial Analysis Intelligence Index. MiniMax M3 sits around 44 on the same index, with a vendor-claimed 59.0 percent on SWE-bench Pro.

On price the direction reverses hard. Moonshot lists K3 at $3 per million input tokens and $15 per million output. M3 is a fraction of that — sources vary on the exact figure, so check the vendor page before budgeting, but the gap is large enough that no plausible reading changes the conclusion.

M3 is natively multimodal, which is not a footnote

MiniMax describes M3 as the first open-weight model combining frontier coding, a 1M window, and native multimodality. That third property narrows the comparison set considerably.

If your workload involves screenshots, design mocks, diagrams or rendered pages, you are no longer choosing among all open-weight models — you are choosing among the few that see. At M3's price point that list is very short.

The practical pattern is a visual feedback loop: screenshot the broken UI, hand it to the model with the component source, get a diff, re-render, repeat. Running that loop through a frontier text model plus a separate vision call costs several times more per iteration, and iterations are the whole point.

Where K3 earns the difference

Long, unattended, multi-step work. K3's benchmark advantages concentrate on exactly the tasks that run for many turns without supervision, and that is not a coincidence — it is what those benchmarks measure.

The mechanism is compounding. In a twenty-step loop, each step's output becomes the next step's input, so a per-step error rate multiplies rather than averages. A model a dozen index points ahead is not a dozen points better at completing a long task; it is disproportionately better, and the gap widens with horizon length.

The flip side, which people underweight: on short bounded tasks the two models are much closer than the index suggests. Ask either to explain a stack trace or convert a schema and you will struggle to tell them apart, while paying many times more for one of them.

The licence is not symmetric

K3's weights are published, but under Moonshot's own terms rather than a permissive licence. Model-as-a-service businesses above a revenue threshold need a separate agreement. If you are building a product whose core is inference, resolve that before you build on it — the gate appears at the moment you succeed. Open weights vs open source covers the pattern.

How to decide

Sort your workload by horizon length, because that is the axis these two models actually differ on.

• Short, bounded, high volume — M3. The quality gap is small here and the price gap is not.
• Multimodal anything — M3, unless you have a specific reason to pay for a frontier model plus separate vision.
• Long unattended agent runs — K3. Completion rate is what you are buying, and it compounds.
• Mixed, which is most teams — both, routed. Default to M3, escalate to K3 on a turn-count ceiling or a failed check.

Model routing and fallbacks covers the mechanics. How to benchmark LLMs on your own work covers finding your own escalation threshold, which matters more than either model's published scores.

Measure cost per completed task rather than price per token. A model that costs a tenth as much and needs three attempts is still cheaper; a model that costs a tenth as much and silently produces a plausible wrong answer is not.

Keep the comparison runnable

Both labs ship frequently, so any conclusion here decays. The durable artefact is not the choice but the evaluation — a fixed task set, a fixed harness, and a recorded baseline for each model.

Built once, re-running it against a new release costs an afternoon rather than a fresh round of argument. That matters more in this field than in most, because the ordering genuinely changes between releases and last quarter's answer is not evidence about this quarter's.