Kimi K3 Agent Swarm: 300 Parallel Agents

The Kimi K3 Agent Swarm is Moonshot AI's system for running many AI sub-agents in parallel on one task, coordinated by a single orchestrator that can spin up to 300 sub-agents across roughly 4,000 steps (AlphaSignal). It ships as a dedicated model variant, K3 Swarm Max, alongside the standard K3 Max, and it is the marquee feature of the K3 launch.

What makes it more than marketing is how the orchestration is trained. Rather than a hand-written prompt that says "spawn five agents," Moonshot trains the coordinator with reinforcement learning so that deciding when to parallelize is a learned skill, not a template (arxiv: Reinforcement Learning for LLM-based Multi-Agent Systems through Orchestration Traces). That distinction is the whole story of whether a swarm helps or just multiplies cost.

Key Takeaways:

Kimi K3 Agent Swarm runs up to 300 sub-agents over ~4,000 coordinated steps, exposed through the K3 Swarm Max variant.
The orchestrator is a learned policy trained with Parallel-Agent Reinforcement Learning (PARL), not a prompt template; spawning a sub-agent is an action it chooses.
The reward balances task quality against critical-path efficiency (~80/20 in the K2.5 setup), which trains the model to parallelize only when it actually helps.
Swarms win on broad, parallelizable work (search across 100 sources, batch analysis); they struggle on deep sequential tasks and can amplify hallucination and cost.
Agent swarm vs single agent is not either/or: most real work is a research-judge-execute-revise loop, not a 300-way fan-out.

What Is Kimi K3 Agent Swarm?

The Kimi K3 Agent Swarm is a multi-agent architecture where one orchestrator model decomposes a task, launches many sub-agents to work on pieces at the same time, and stitches their results back together. Kimi K3 ships in two flavors: K3 Max for standard chat and single-agent work, and K3 Swarm Max, the variant tuned specifically for large-scale parallel processing (DataCamp).

The difference matters when you pick a model. K3 Max is the right default for a normal coding or writing session. K3 Swarm Max is for the specific shape of problem where the work genuinely splits into many independent pieces, like surveying a hundred sources or running the same analysis across a large batch. Choosing Swarm Max for a linear task wastes its whole advantage.

What this resolves: what the Kimi K3 Agent Swarm is and which variant does what. What it leaves unsolved: how the orchestrator actually decides to parallelize, which is the technically interesting part.

How K3 Swarm Max Works: Orchestrator + 300 Sub-Agents

K3 Swarm Max works through a two-level structure. A main orchestrator agent handles roughly 15 high-level steps, and at each step it can choose to fan out work to sub-agents, up to 300 of them, running as many as 4,000 coordinated steps underneath. The orchestrator plans, delegates, and integrates; the sub-agents do the parallel legwork.

K3 Swarm Max architecture: one orchestrator running about 15 high-level steps fans out to up to 300 parallel sub-agents across roughly 4,000 coordinated steps, with results merging back (PARL reward)

The part that separates this from a scripted multi-agent wrapper is that the orchestrator is a learned policy, not a prompt template. Moonshot trains it with Parallel-Agent Reinforcement Learning (PARL), where creating a sub-agent is an action in the model's action space, the same way calling a tool is. The model learns, from reward, when spawning a parallel worker pays off and when it just adds overhead.

The reward is what makes this work rather than devolve into chaos. It decomposes into a task-performance term plus terms for parallel efficiency and for finishing, written roughly as r_perf + λ1·r_parallel + λ2·r_finish. In the K2.5 setup this landed near an 80/20 split between task quality and critical-path efficiency, where the critical path is measured by the slowest sub-agent at each stage (arxiv: Orchestration Traces). Two failure modes fall out of that design. Without the efficiency term, a swarm collapses to a slow single-threaded pattern (serial collapse); without the quality term, it spawns agents where the work is not actually parallel and quality drops. PARL trains the model to avoid both.

What this resolves: why the Kimi K3 Agent Swarm is a trained behavior, not a clever prompt. What it leaves unsolved: how it got here, because these numbers did not appear all at once.

From Kimi K2.5 to K3: The Agent Swarm Timeline

The Kimi agent swarm did not launch at 300 sub-agents. It scaled across three releases, and it matters not to credit K3 with capabilities that shipped earlier.

Release	Swarm scale	What was added
Kimi K2.5	~100 sub-agents, ~1,500 steps	Introduced PARL: parallelism as a learned skill
Kimi K2.6	~300 sub-agents, ~4,000 steps	Scaled the swarm; added Claw Groups (cross-vendor + human-in-the-loop, research preview)
Kimi K3	300 sub-agents, ~4,000 steps	K3 Swarm Max: a dedicated variant, on the stronger K3 base

So the 300-sub-agent, 4,000-step ceiling arrived with K2.6, not K3, which also introduced Claw Groups for cross-vendor and human-in-the-loop coordination (covered in Kimi Agent Swarm and Claw Groups). What K3 adds is not a bigger number but a dedicated Swarm Max variant running on a far more capable 2.8T base model, which should make each sub-agent individually smarter. The measured gains from the swarm approach were real even at the earlier scale: versus a single agent, Moonshot reported 3 to 4.5 times fewer critical steps on large-scale search and up to 4.5 times faster execution.

Consider Nadia, a competitive-intelligence analyst who had been running K2.6's swarm to pull structured data from dozens of sources nightly. Moving to K3 Swarm Max did not change the 300-agent ceiling she already had; it made each sub-agent's extraction cleaner because the underlying model got smarter. That is the honest upgrade story: better parts, same coordination limits.

What this resolves: which swarm capabilities are genuinely new to K3 versus inherited from K2.6. What it leaves unsolved: what all this parallelism is actually good for.

What Parallel AI Agents Are Actually Good At

Parallel AI agents shine on a specific shape of work: broad, decomposable tasks where many pieces can run independently and get merged at the end. Moonshot's own demo cases show the pattern precisely. In one, the swarm identified the top three creators across 100 YouTube niches by dispatching 300 parallel sub-agents, then assembled the findings into a structured table with charts.

Moonshot's official Agent Swarm demo: the K2.6-era swarm dispatched 300 sub-agents across 100 YouTube niches to build a structured top-three-creators table (source: Kimi Agent Swarm help page)

In another, it collected more than 200 Paul Graham essays scattered across different sites and formats.

Both cases share a signature: the work is wide, not deep. A hundred niches, two hundred essays, dozens of sources, and each unit of work barely depends on the others. That is the sweet spot for multi-agent orchestration, the design space we map in the AI agent orchestration guide. The three patterns that fit are broad search (survey many sources at once), batch operations (run the same task across many items), and multi-perspective analysis (attack one question from several angles in parallel).

Take Wei, a market researcher who needed pricing and positioning for 80 competitor products before a Monday review. A single agent would grind through them serially over hours. A swarm dispatches dozens of sub-agents, each owning a handful of products, and returns a merged table in a fraction of the wall-clock time. When the work genuinely parallelizes, the speedup is real and large.

What this resolves: the exact task shape where parallel AI agents win. What it leaves unsolved: everything that shape leaves out, which is where swarms get into trouble.

Where Swarms Break Down

Swarms are not free, and three failure modes show up fast. The first is boundary conflict: when sub-agents' pieces are not cleanly independent, they duplicate work, contradict each other, or step on shared state, and the orchestrator spends its budget reconciling them instead of making progress.

The second is hallucination amplification. K3's hallucination rate rose versus its predecessor, per The Decoder citing Artificial Analysis (the-decoder.com). In a single-agent run one wrong fact is one wrong fact. In a 300-agent swarm, a confident error in an early sub-agent can propagate into the merged output that other agents then build on, and no human saw it happen.

The third is cost. A swarm that runs thousands of tool calls scales with output volume, and K3 charges $15 per million output tokens. A 4,000-step run is not four thousand times a chat message, but it is materially more than a single sequential agent doing the same job, and the bill lands whether the parallelism helped or not. For a task that was never parallel to begin with, you pay swarm prices for single-agent results. Take Ravi, a data lead who pointed K3 Swarm Max at a dependency-heavy migration expecting a speedup: the sub-agents kept editing overlapping files, the orchestrator burned most of its 4,000-step budget reconciling their conflicts, and the run cost several times a single agent doing the same migration serially. He moved the job back to one agent and reserved the swarm for the genuinely wide research pass that fed it.

What this resolves: the concrete ways a swarm underperforms or overcharges. What it leaves unsolved: how to decide, for a given job, between a swarm and a single agent.

Agent Swarm vs Single Agent: Which Do You Need?

The agent swarm vs single agent choice comes down to one question: is your work wide or deep? A swarm wins on parallel width, many independent pieces at once. A single agent wins on sequential depth, where each step depends on the last and the value is in careful iteration.

Your task looks like...	Better fit	Why
Survey 100 sources, then summarize	Agent swarm	Independent pieces, merge at the end
Run one analysis across 500 items	Agent swarm	Batch parallelism
Refactor a codebase step by step	Single agent	Each step depends on the last
Research, judge, execute, then revise	Single agent (looped)	Sequential reasoning, not fan-out
Draft, get feedback, redraft	Single agent	Depth over width

Here is the honest part: for the wide tasks, the Kimi K3 Agent Swarm genuinely wins, and it is not close. If your job is fanning out across a hundred sources, a well-trained swarm beats a lone agent on both speed and coverage. But most real-world work is not a 300-way fan-out. It is a loop: research a problem, judge the options, execute a change, review the result, revise. That loop is sequential by nature, and adding 300 parallel agents to it does not make it faster, it makes it noisier and more expensive.

That is the shape MoClaw is built around. Instead of maximizing parallel width, a managed Kimi K3 agent runs the research-judge-execute-revise loop with memory across runs and access to your tools and channels, and it can call parallel search when a step genuinely fans out. The swarm is a capability inside the loop, not the whole architecture. Concede the batch-processing crown to the swarm, then notice that your actual weekly work is mostly loops, not fan-outs.

What this resolves: a clear rule for choosing swarm versus single agent by task shape. What it leaves unsolved: the specific questions people keep asking, below.

FAQ: Kimi K3 Agent Swarm

How many agents can Kimi K3 run?

Up to 300 sub-agents across roughly 4,000 coordinated steps, orchestrated by a main agent that handles about 15 high-level steps. That ceiling arrived with K2.6; K3 Swarm Max runs it on the stronger K3 base. For the full spec context, see what is kimi k3.

What is PARL?

PARL is Parallel-Agent Reinforcement Learning, Moonshot's training method that makes parallelism a learned skill. Creating a sub-agent is an action the orchestrator chooses, and a reward balancing task quality against critical-path efficiency teaches it to parallelize only when it helps.

Is Agent Swarm available in the API?

The swarm capability is exposed through the K3 Swarm Max variant, distinct from K3 Max. Access, the 1M context, and higher-throughput tiers are membership-gated, and calling them on the wrong plan returns a 401.

Agent swarm vs single agent, which is faster?

For wide, parallelizable work, the swarm is dramatically faster, up to 4.5x in Moonshot's tests. For deep sequential work, a single agent is faster and cheaper, because parallelism adds coordination overhead without speeding up steps that depend on each other.

How does this compare to Claude's agents?

K3 ships a dedicated large-scale swarm variant that Claude does not match directly, though Claude's single-agent tooling is more mature. See our kimi k3 vs claude comparison for the full picture.

Where Kimi K3 Agent Swarm Actually Fits

The Kimi K3 Agent Swarm is a genuine advance in multi-agent orchestration, and on the work it suits, broad search, batch operations, multi-perspective analysis, it delivers speedups a single agent cannot touch. The learned orchestration policy behind it, trained with PARL so that parallelism is chosen rather than scripted, is the real technical achievement, not the headline 300-agent number that actually shipped with K2.6.

The mistake would be treating a swarm as the default architecture for all agent work. Most real tasks are sequential loops, not fan-outs, and for those a swarm adds cost and hallucination risk without adding speed. Match the tool to the task shape: reach for the swarm when your work is genuinely wide, and a single looped agent when it is deep. For the rest of the K3 picture, see what is kimi k3, the kimi k3 vs claude head-to-head, or the upgrade math in kimi k3 vs k2.6.