Kimi K3 shipped with two serving variants, and the distinction is operational rather than architectural: same underlying model, tuned for different shapes of work. K3 Max is for chat and single-agent tasks. K3 Swarm Max is for large-scale parallel multi-agent workloads.
The difference
| K3 Max | K3 Swarm Max | |
|---|---|---|
| Shape of work | One agent, sequential | Many sub-agents, parallel |
| Built for | Chat, coding sessions, document analysis, research | Batch processing, search-heavy fan-out, multi-agent orchestration |
| Used by | The Kimi apps, Kimi Work, mobile — the default | Purpose-built parallel workloads |
| Underlying model | Same 2.8T model | Same 2.8T model |
Both share the 1M tokens window, the always-on reasoning, and the same pricing structure.
When Swarm Max is the right answer
Swarm Max extends Kimi's Agent Swarm capability to K3's scale. It earns its place when your job genuinely decomposes into independent sub-tasks that can run at once:
- Research fan-out — twenty sub-queries against different sources, then a synthesis pass.
- Batch processing — a large set of documents or records handled in parallel rather than in sequence.
- Broad search — exploring many branches where you do not know in advance which will pay off.
The test is simple: if your sub-tasks need each other's output, they are sequential and Swarm Max buys you nothing.
When K3 Max is the right answer
Almost everything else, including most things people assume need a swarm:
- Any interactive use — chat, coding sessions, iterative document work.
- Single-agent loops, even long ones. A hundred sequential steps is still one agent.
- Anything where step n depends on step n−1.
Start here. Reach for Swarm Max when you have measured a fan-out phase that is genuinely slow because it is serial, not because you like the idea of parallel agents.
Practical notes
The documented API model ID is kimi-k3; the variants are serving modes rather than separate ID strings in the published docs. If you need to target Swarm Max specifically, check Moonshot's current API reference rather than assuming a naming convention — this is the kind of detail that changes early in a model's life.
Also worth knowing: parallel execution does not mean coordinated execution. Keeping sub-agent outputs consistent with one another remains your architecture's job, and it is the part that usually takes longer than expected.
More on Kimi K3
Start with the complete Kimi K3 guide for the overview, or go deeper:
Ready to go deeper?
Read the full Kimi K3 guideFrequently Asked Questions
What is the difference between K3 Max and K3 Swarm Max?
Same underlying 2.8T model, different operational tuning. K3 Max handles chat and single-agent tasks and is the default in the Kimi apps. K3 Swarm Max targets large-scale parallel multi-agent workloads — batch processing and search-heavy fan-out where many sub-agents run simultaneously.
Which Kimi K3 variant should I use?
K3 Max, unless you have a job that genuinely decomposes into independent parallel sub-tasks. If step n depends on step n−1, your work is sequential and Swarm Max adds complexity without adding speed — even for long agent runs.
Do the two variants cost different amounts?
Both draw on the same model and the same published rates of $3.00 input and $15.00 output per million tokens. What differs is total consumption: a parallel swarm running twenty sub-agents uses roughly twenty agents' worth of tokens, which is the cost consideration that actually matters.
