Kimi K3 Swarm: Which Work Actually Parallelizes Well

The Kimi K3 Agent Swarm question that matters is not how many subagents you can run — Moonshot documents up to 300 instances and more than 4,000 tool calls in a single task — but which of your work actually gets faster when you split it. Moonshot answers that question more honestly than most vendors do, because its own documentation names the two ways the system fails when the work does not decompose.

Those two failure modes are called serial collapse and fake parallelism. They are not criticisms from a reviewer; they are training targets that Moonshot published in its own help centre, alongside the reward function it built to suppress them. A vendor that has to explicitly train an orchestrator not to fake parallelism is a vendor telling you, in public, that fan-out is not free and not always a win.

This guide turns that admission into a working decision test. It covers how the architecture is actually put together, what Moonshot’s own critical-steps metric measures, a scored decomposability matrix you can run against your own task list before you spend a credit, what the BrowseComp result does and does not prove, the one case where divergence between subagents is the deliverable rather than the defect, and how to think about fan-out width when the vendor publishes no fixed cost multiplier.

Agent Swarm was introduced on January 27, 2026 alongside Kimi K2.5, described by Moonshot as a scale-out architecture that coordinates large-scale subagent collaboration without predefined roles or manually designed workflows. On April 20, 2026, the release of Kimi K2.6 gave it a substantial capacity upgrade: up to 300 subagent instances running simultaneously, more than 4,000 tool calls in a single task, and a vendor-stated 4.5× speed advantage over sequential execution by a single agent. Agent Swarm now runs on Kimi K3, which Moonshot describes as further improving large-scale parallel search and batch processing — without publishing new capacity numbers beyond those figures.

The structural detail worth internalising is the split between coordination and execution. The main agent — the orchestrator — is capped at 15 steps. Those 15 steps direct up to 4,000 steps executed across the subagents. Almost all of the compute happens below the orchestrator; almost all of the judgement happens inside it. That asymmetry is why the orchestrator is the only part Moonshot trains.

Moonshot gives two reasons for freezing the subagents. The first is clean credit assignment: when a project succeeds or fails, the credit or blame belongs unambiguously to the orchestrator’s scheduling decisions rather than to ambiguous drift in subagent behaviour. The second is stability — if every subagent’s tactics changed simultaneously during training, the team would fall into chaos.

Read that as a design statement about where the difficulty lives. The hard problem in multi-agent work is not making a worker better; it is deciding what to hand it, when, and how many of them to run. That is the same problem you have when you decide whether to use Swarm at all. If you want the wider map of how this pattern sits next to supervisor, pipeline and blackboard designs, our agent architecture patterns taxonomy places orchestrator/subagent systems in context.

The most useful paragraph Moonshot has published about Agent Swarm is not a benchmark. It is the section describing what the orchestrator does wrong when left untrained. Two behaviours are named explicitly, and the reward function exists to suppress both.

Both failures share a root cause: the task did not have the shape that rewards splitting. Moonshot’s countermeasure is a reward function with three dimensions — final completion quality, whether true parallelism was achieved rather than one agent doing everything, and subtask completion rate so the orchestrator cannot pad the roster with agents that do nothing. Early in training the second and third dimensions carry heavy weight; later they are reduced so the model optimises toward result quality once the collaboration habit is established.

Notice what that curriculum implies. Moonshot had to push the model hard toward parallelism to teach it the behaviour at all, then pull back so it would stop parallelising for its own sake. Both directions of correction were necessary. That is the clearest available evidence that neither “always fan out” nor “never fan out” is the right default — the decision is per-task, and it is exactly the decision the rest of this guide is about.

To stop the model from blindly splitting tasks to look busy, Moonshot needed a metric that only improves when parallelism does real work. It settled on critical steps, and explained the idea with a renovation analogy. Run a renovation serially and each trade waits in line, so total time is the sum of every trade’s hours. Run it in parallel and the tiler, carpenter, electrician and plumber start at once, so total time is set by the slowest trade at each stage — not by the total labour. Critical steps are the sum of the slowest subagent’s time across each stage.

That is a critical-path argument, arrived at independently and expressed in plumbing. It is also the cleanest way to explain why adding subagents stops helping. Once every stage is already bounded by one slow worker, the twentieth agent changes nothing about wall-clock time — but it still consumes credits, still produces output somebody has to read, and still adds a row to whatever the orchestrator has to reconcile at the end.

There is at least one piece of academic work pointing the same way. M1-Parallel, published in July 2025, runs multiple multi-agent teams in parallel on the same problem to find diverse solution paths rather than splitting subtasks of one problem. It reported up to a 2.2× speedup with early termination and aggregation — but also found that engineering task-specific diversity strategies produced no additional performance gains over simple repeated sampling. The paper predates Agent Swarm and does not evaluate Moonshot’s system, but the direction is consistent: parallel gains come from work that is genuinely independent and cheaply aggregable, not from structure imposed on tasks that resist it.

Moonshot documents six task families as especially suitable for Agent Swarm: large-scale information retrieval, batch downloads, broad reading across 100+ documents, long-form writing exceeding 100,000 characters, complex programming including front-end work, code review and multi-file refactoring, and office automation across documents, spreadsheets and presentations. That list is a starting point, not a decision rule — “complex programming” contains both work that fans out beautifully and work that collides on every shared file.

So here is the test we run instead. Three yes/no questions, each scored 1 when the answer favours fan-out and 0 when it does not. Question one: can the subtasks run with genuinely zero cross-dependency? Question two: is merging N outputs cheap — a concatenation, a table, a folder — or expensive, requiring somebody to resolve contradictions into a single narrative? Question three: can the deliverable tolerate divergence, or does it need one voice and one decision? Add the three. Only a 3 out of 3 is an unambiguous fan-out.

The three zero-score rows are the ones worth dwelling on, because each maps to a Moonshot failure mode. The auth refactor and the production-incident debug both trigger serial collapse: the dependency chain is real, so a well-trained orchestrator will correctly stop splitting — and you will have paid swarm-tier credits for a single-agent run. The brand-voice article is the fake- parallelism trap: it splits easily into sections, produces plausible parallel output, and delivers an article with four different registers that a human then rewrites end to end.

The two-out-of-three rows are not rejections. They are instructions: fan out, but assign the merge explicitly before you start. Name who or what resolves contradictions, decide the output schema up front, and budget for that step rather than discovering it after 40 agents have returned. That merge design is most of the work in a real Swarm workflow — enough that we treat it as its own topic in the end-to-end market-research workflow.

The headline result Moonshot publishes for Agent Swarm is BrowseComp accuracy rising from 15.9% for a single agent to 33.3% for the swarm. That is a real and substantial gap — a little over double — and it is the strongest published evidence that fan-out helps on the right task shape. It is also narrower evidence than it first appears.

BrowseComp is OpenAI’s benchmark, not Moonshot’s. It contains 1,266 questions built by an inverted-question method: start from a verifiable fact, construct a question whose answer is hard to find but easy to check — what the authors call the asymmetry of verification — then confirm the question resists strong models and does not surface in top search results. It measures browsing persistence and retrieval depth. It does not measure coding, it does not measure single-voice writing, and it does not measure anything requiring one coherent through-line.

That matters for how far you can carry the result. A doubling on BrowseComp is strong evidence for wide information-retrieval work — which is also Agent Swarm’s best-documented category — and weak evidence for anything else. This is our reading rather than a vendor claim, but it follows directly from what the benchmark was built to test.

One more caveat belongs here, carefully bounded. A single hands-on review published in late July 2026 ran Kimi K3 against Claude Opus 4.8 on real GitHub issues and reported near-parity on simple tasks but a markedly higher failure rate for K3 on deliberately adversarial ones. That review tested single-agent coding quality, not swarm coordination, and it has not been corroborated by a second lab — so it says nothing about parallelisation behaviour. It is relevant in one indirect way only: the less reliable an individual subagent is on hard work, the more verification and reconciliation you inherit after the fan-out, which pushes borderline tasks toward the sequential column of the table above.

Most “when not to parallelise” advice, including the third column of our own table, treats disagreement between workers as a defect to be merged away. Moonshot’s own case studies contain the counter-example, and it is worth naming explicitly rather than glossing over.

In its multi-perspective analysis case, Agent Swarm reviews a product launch strategy by assigning independent agents genuinely different roles — a senior product manager worried about technical debt, a sceptical investor questioning unit economics, a head of customer success defending edge cases — and then forces reconciliation. Moonshot frames the design goal as structurally avoiding groupthink. The divergence is not noise to be smoothed; it is the entire reason to run the task at all.

The same logic drives its multi-style writing case, where twenty independent writer subagents each continue the same novel in a different literary register — interior monologue, labyrinthine fabulism, bureaucratic absurdism — producing twenty alternate endings that are supposed to disagree. In both cases the one-coherent-voice test inverts: you are not trying to produce one voice, you are trying to produce many and then decide between them.

That fourth pattern deserves the most attention, because it is where most agency and engineering work lands. Very little real work is purely additive or purely convergent; most of it is a wide, boring evidence-gathering phase followed by a narrow, judgement-heavy synthesis. Swarm is excellent at the first half and structurally unsuited to the second. Splitting your workflow at that seam — rather than deciding to “use Swarm” or “not use Swarm” for the whole job — is the single highest-leverage change most teams can make. It is the same reasoning we apply to parallel multi-agent coding patterns generally, and the first thing we map in an AI transformation engagement — which parts of an existing workflow decompose, and which quietly do not.

Once you have decided a task fans out, the second question is how far. Moonshot publishes no cost curve and no fixed credit multiplier, so an honest answer cannot be a number — it has to be a reasoning tool. The table below applies the vendor’s own critical-steps definition at four widths and asks, at each, what actually sets your wall-clock time and what you inherit in coordination load. It is a framework for interrogating your own task, not measured data.

The pattern the table is trying to make visible is that the binding constraint moves. At three agents your limit is the slowest worker; at three hundred it is your own ability to check the output. That shift is why “use the maximum width” is almost never the right instruction. The right instruction is to widen until the stage is bounded by something other than worker count, then stop — and if you cannot tell where that point is, run the task twice at different widths and time it rather than trusting a vendor multiple.

Worth noting for calibration: Moonshot is not alone in shipping parallel orchestration as a product surface. OpenAI’s ultra setting coordinates four agents in parallel by default, a default width Swarm’s documented ceiling exceeds roughly seventy-five-fold. That gap is a design statement about where each vendor thinks the useful width sits — and it should make you sceptical of any framing where more agents is automatically better.

Agent Swarm is gated to Moonshot’s paid membership tiers — Moderato, Allegretto and Allegro — and the vendor states plainly that a swarm task consumes roughly several times the credits of a regular agent task, scaling with complexity and subagent count. That is the whole of the published cost guidance. There is no fixed swarm-to-single multiplier anywhere in Moonshot’s documentation, and you should be suspicious of any third-party article that supplies one.

The underlying model has a published API price, which is a different surface from the consumer credit tiers. Moonshot’s standard list pricing for Kimi K3 is $0.30 per 1M cache-hit input tokens, $3.00 per 1M cache-miss input tokens and $15.00 per 1M output tokens — the vendor itself notes that the output rate includes the reasoning trace, which is a real cost factor on agentic work. OpenRouter’s moonshotai/kimi-k3 listing matches that at $3.00 in and $15.00 out per 1M tokens on its provider rate. Those figures are API rates and do not translate directly into swarm credits.

For context on the model underneath: Kimi K3 is a 2.8T-total, 104B-active mixture of experts with 896 experts, a 1M-token context window and native vision. It has been hosted since mid-July 2026, with open weights following in late July under a bespoke Kimi K3 licence — notably not the modified-MIT terms K2 shipped under. That licence gates commercial model-as-a-service use above roughly $20M a year in revenue from that use, and requires visible Kimi K3 branding for product embedding above 100 million monthly active users or $20M a month in revenue. If you are evaluating the model itself rather than the swarm, our write-up of Kimi K3’s full release specs covers the architecture in depth, and the hands-on setup guide for Kimi Code covers the CLI and caching behaviour.

Before you run anything wide, put a ceiling on it. Fan-out is the fastest way to turn a budgeting mistake into a large one, because the spend happens in parallel and you find out afterwards. Our agent token-budget framework is built for exactly this — set the cap before the dispatch, not after the invoice. And if the deciding factor is a capability other than parallelism, the 1M context, vision and reasoning-effort surfaces are frequently the better lever.