Agentic work is the clearest thing Moonshot says K3 is for, and the product design backs it up: reasoning cannot be switched off, tool calling supports dynamic tool loading, and there is a second serving variant — K3 Swarm Max — built specifically for running many sub-agents in parallel. That is an unusual amount of agent-shaped surface area for an open-weight model.
This page is written for engineers building autonomous agents and multi-agent systems. If you want the model overview first, start with the complete Kimi K3 guide.
| Best effort level | max (the API default is max) |
| Context available | 1M tokens — enough for real working material, not just snippets |
| Cost | $3.00 per million input tokens, $15.00 per million output, $0.30 cached input |
Why Kimi K3 suits long-horizon agents
- 1M tokens of context is enough to hold a long tool-call history without immediately building a summarisation layer — the thing that usually breaks first in a long agent run.
- Always-on reasoning means every tool decision gets deliberation. Agents fail most often on which tool to call, not on calling it correctly, and that is a reasoning problem.
- K3 Swarm Max exists for the fan-out case: batch jobs and search-heavy work where many sub-agents run at once, rather than one agent thinking hard in sequence.
- Published agentic figures are strong: 88.3 on Terminal-Bench 2.1 and 91.2 on BrowseComp, both benchmarks that measure multi-step tool use rather than single-shot answers.
- Cached input at $0.30 per million makes the repeated-system-prompt pattern that every agent loop uses genuinely cheap.
A workflow that works
- Structure the prompt cache-first. Your system prompt, tool definitions, and any fixed context go at the front and stay byte-identical between calls. That is what turns $3.00 input into $0.30 input.
- Load tools dynamically. K3 supports narrowing the tool set per call. An agent offered eighty tools reasons worse than one offered the eight that are relevant — pass the subset.
- Pick your variant deliberately. K3 Max for a single agent working a problem through; K3 Swarm Max when the job decomposes into parallel sub-tasks.
- Budget the run, not the request. With reasoning always on, a hundred-step agent run has a hundred reasoning passes. Set a hard token ceiling for the whole run and stop it rather than trusting per-call limits.
- Log
finish_reasonon every call. Long agent runs fail quietly. A truncated response that your code treats as complete is the most common cause of an agent that appears to work and does not.
Settings to start from
Set reasoning_effort to max. This is the one workload where the default is also the right answer. On a long run, a bad decision at step 4 costs you every step after it, so reasoning depth up front is usually cheaper than the recovery. Drop to high only once you have measured that your specific loop tolerates it.
Remember that reasoning cannot be turned off on this model, and that the API default is max — the most expensive of the three levels. Setting it explicitly is the single highest-value line of configuration you will write. See reasoning effort explained if you want to tune it properly.
What to watch out for
- Cost compounds silently. Reasoning on every step of a multi-hundred-step run, at $15.00 per million output tokens, is how agent bills get away from people. Instrument spend per run from day one.
- A 1M window is not infinite. Long runs still fill it. Plan your compaction or summarisation strategy before you need it, not after an agent dies mid-task.
- Parallel does not mean coordinated. K3 Swarm Max runs sub-agents simultaneously; keeping their outputs consistent is still your architecture's job.
- No published rate limits to plan against. Moonshot's docs do not publish per-tier throughput figures, so load-test your own account before assuming a swarm will scale.
The verdict
One of the better-positioned models for agent work right now, and the price is what makes long runs affordable rather than experimental. Start with a single-agent loop on max effort, get spend instrumentation in before you scale, and only reach for Swarm Max once you have a job that genuinely decomposes.
If cost is the constraint, read how to cut Kimi K3 costs before downgrading — caching and effort levels usually beat switching models.
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
Is Kimi K3 good for building AI agents?
It is one of the more agent-oriented models available: reasoning is always on, tool calling supports dynamic tool loading, and a dedicated K3 Swarm Max variant handles parallel multi-agent workloads. Published results on agentic benchmarks are strong — 88.3 on Terminal-Bench 2.1 and 91.2 on BrowseComp.
What is the difference between K3 Max and K3 Swarm Max?
Same underlying model, different operational tuning. K3 Max handles chat and single-agent tasks and is what the Kimi apps use by default. K3 Swarm Max targets large-scale parallel workloads where many sub-agents run at once — batch processing and search-heavy jobs. See our [K3 Max vs Swarm Max breakdown](/blog/kimi-k3-max-vs-swarm-max).
How do I stop a Kimi K3 agent from getting expensive?
Three levers, in order of effect. Cache the fixed prefix so repeated context costs $0.30 rather than $3.00 per million. Drop `reasoning_effort` to `low` on steps that are mechanical rather than judgement calls. And set a token ceiling for the whole run, not per call — with reasoning always on, per-call limits do not bound a long loop.
