MoonshotAI / MoonshotAI/kimi-code

`[Bug] Kimi Work desktop: Swarm mode selection no longer reaches the runtime — no swarm_mode.enter / enter-reminder injection since app 3.1.4, while sessions still run as k3-agent-swarm`

Open
#2,198 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
TypeScript
Stars
7.5k
Forks
1.2k
Avg merge
11h 53m
Merged PRs (30d)
350

Description

What version of Kimi Code is running?

Kimi Work desktop for Windows (win32-x64): app 3.1.5 (Kimi-Setup-3.1.5.exe), daimon bundle 0.5.49, vendored kimi-code runtime 0.15.3 @ f17a6ecb. Regression window: app 3.1.3 → 3.1.4 (installed 2026-07-23 16:02–16:04 EDT, i.e., 20:02–20:04Z; main.log timestamps are local time).

Which open platform/subscription were you using?

Vivace (upgraded from Moderato on 2026-07-23, ~1:13 AM EDT). All behavior in this report — including the pre-update swarm session later that morning and everything after the 0.5.47 install that afternoon — occurred on Vivace.

Which model were you using?

k3-agent-swarm

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Selecting Swarm mode in the Kimi Work UI used to reach the runtime as an instruction; since app 3.1.4 it no longer does, while the session still runs — and presumably bills — on the swarm model tier.

Before (app 3.1.3, Jul 23 10:40–13:30Z, observed in session wire logs): with Swarm selected, the conversation carried swarm_mode.enter / swarm_mode.exit wire events wrapping each turn, and each swarm turn's prompt was preceded by the enter-reminder from packages/agent-core/src/agent/swarm/enter-reminder.md:

You are now in "agent swarm" mode. The user may send tasks that require a large number of parallel subagents. …

All llm.request events used model k3-agent-swarm, and the session dispatched 10 parallel subagents. This matches the behavior described on the Agent Swarm help page (archived): "Deploy up to 300 Subagent instances simultaneously… automatically coordinate large-scale AI Subagent collaboration."

After (app 3.1.4/3.1.5, sessions of Jul 24 and Jul 25): with the same Swarm mode selected in the UI —

  • the Electron client still records agent_mode: "agent-swarm" for every message in its telemetry (kimi_work_send_message events in %APPDATA%\kimi-desktop\logs\main.log);
  • every llm.request still uses model k3-agent-swarm;
  • the AgentSwarm and Agent tools are still registered and active in tools.set_active_tools;
  • but there are zero swarm_mode.enter/exit events and zero injections of the enter-reminder across entire sessions (checked line-by-line in wire.jsonl for two full multi-turn sessions).

The runtime is never told the user chose swarm mode. Combined with the new default-deny prompt rule (companion issue: #2197), the observable result is that swarm-tier sessions run inline unless the user spells out "use subagents" in the task text.

What steps can reproduce the bug?
  1. Kimi Work desktop ≥ app 3.1.4 on Windows, membership tier with Agent Swarm access, Swarm mode selected in the UI.
  2. Run a multi-turn session; then open the session's agents/main/wire.jsonl (location per the Agents docs, "Storage Location in the Session Directory").
  3. grep for swarm_mode and for "You are now in" → 0 hits. grep the same file for "model"k3-agent-swarm on every request.
  4. Compare with any pre-3.1.4 swarm session's wire.jsonl (if retained): swarm_mode.enter events and the enter-reminder text are present there.
What is the expected behavior?

Either (a) the mode selection propagates to the runtime as before (swarm_mode.enter + reminder), or (b) if swarm entry is now intentionally deferred/queued (e.g., for capacity reasons), the UI should say so instead of silently accepting the selection — and the change should appear in release notes. Users on swarm-eligible paid tiers currently get single-agent behavior by default from a session that runs on the swarm model.

Additional information

Impact

  • Behavior/billing mismatch: sessions are served by k3-agent-swarm while the mechanism that produces swarm behavior is disconnected.

  • Silent regression: no error, no UI change, no changelog — only wire-log archaeology reveals it. The desktop bundle has no public changelog at all.

  • Support burden: the agent itself, asked why it didn't swarm, cannot see that the mode was selected ("nothing in my runtime context told me swarm behavior was expected" — which the wire logs confirm is literally true post-3.1.4).

Notes

  • Timeline context: this landed the same day (Jul 23) as the new prompt-level Agent-tool restriction (#2197) and four days after the Jul 19 pause of new subscriptions for capacity reasons; if both are deliberate load-shedding, documenting them would let users make informed use of their credits.

  • Related (not duplicates): #720 (configurable default swarm mode), #1957 (swarm progress visibility).

  • Wire/log excerpts above are redacted per the docs' guidance on wire files; fuller redacted excerpts (timestamps, event sequences) available on request.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing the pre- and post-3.1.4 session agents/main/wire.jsonl files, then trace the runtime integration that should emit swarm_mode.enter/exit and inject packages/agent-core/src/agent/swarm/enter-reminder.md. Confirm the selected mode reaches the runtime while k3-agent-swarm requests continue, and verify the resulting wire events and reminder in a reproduced session.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.