Step 3 · Runtime & operations · Runtime · SubagentBatch & disk ENPT
Kimi CLI AgentSwarm · Visual Course

SubagentBatch & disk state

How the runtime launches subagents with a 5 + 700ms ramp — and where forensics live in wire.jsonl and state.json.

Read the plain version, or open the technical layer on any section.
1

The big idea


When AgentSwarm passes validation, the binary's SubagentBatch class takes over. It expands each item into a concrete prompt, creates persisted subagent directories, and launches them with a controlled ramp to avoid provider rate limits.

Ramp policy (documented + confirmed in session 30e21381):

  • Burst: 5 subagents launch immediately
  • Ramp: +1 subagent every 700 ms
  • Cap: optional KIMI_CODE_AGENT_SWARM_MAX_CONCURRENCY limits the initial burst
  • Rate limit: subagent requeued — Provider rate limit; subagent requeued for retry.

Every agent (main and sub) gets an append-only wire.jsonl. Session-level state.json holds the agent registry with parentAgentId, swarmItem, and type: main|sub. This is your forensic trail.

Think of it like… boarding a wide-body jet. The first five passengers board at once (burst), then one every 700ms (ramp) so the gate doesn't jam. Each passenger gets their own flight log (wire.jsonl); the manifest (state.json) lists who belongs to which group.

Observed timestamps (8 agents)

21:41:44.204 agent-3
21:41:44.207 agent-4
21:41:44.210 agent-1
21:41:44.215 agent-2
21:41:44.218 agent-0   ← 5 in ~14 ms
21:41:44.847 agent-5   ← +629 ms
21:41:45.548 agent-6   ← +701 ms
21:41:46.253 agent-7   ← +705 ms

Stress session e046c6c5: 43 agents, 10× AgentSwarm calls, 7,471+ main wire events — proves sequential multi-swarm missions in production.

2

In one picture


~/.kimi-code/sessions/ wd_<hash>/session_<uuid>/ state.json agents registry agents/ main/wire.jsonl agent-0/wire.jsonl … agent-N/ SubagentBatch ramp 5 immediate → +1 / 700ms KIMI_CODE_AGENT_SWARM_MAX_CONCURRENCY wire.jsonl event types tool.call · tool.result · swarm_mode.enter context.append_loop_event (append-only)
Left: on-disk layout per session. Right: SubagentBatch ramp policy and wire event taxonomy.
3

In the code


Registry links each subagent back to its swarm item. Wire logs every tool call and result.

state.json — agent registry (session 30e21381)
{
  "agents": {
    "main": { "type": "main", "parentAgentId": null },
    "agent-0": { "type": "sub", "parentAgentId": "main", "swarmItem": "claude" },
    "agent-1": { "type": "sub", "parentAgentId": "main", "swarmItem": "grok" }
  }
}
SubagentBatch strings (binary v0.18.0)
AGENT_SWARM_MAX_CONCURRENCY_ENV = "KIMI_CODE_AGENT_SWARM_MAX_CONCURRENCY"
RATE_LIMIT_MESSAGE = "Provider rate limit; subagent requeued for retry."

class SubagentBatch {
  normalLaunchCount = 0;
  normalLaunchTimer;
  maxConcurrency;
}

Reproducible checks

jq '.agents' ~/.kimi-code/sessions/wd_*/session_*/state.json
rg 'AgentSwarm' ~/.kimi-code/sessions/wd_*/session_*/main/wire.jsonl
KIMI_CODE_AGENT_SWARM_MAX_CONCURRENCY=4 kimi
4

Try it: simulate the ramp


Drag the slider to see which agents would be live at each tick of the 5+700ms ramp (8-agent swarm).

0 ms
Burst phase: launching first 5 agents…
Next: how Kimi AgentSwarm compares to Droid Missions — and operator patterns that combine swarm execution with proof gates.