[Bug] plan_mode / swarm_mode in prompt submissions are silently dropped — modes enabled in a new-session draft never reach the first turn

What version of Kimi Code is running?

0.43.0 (kimi web server; binary installed at ~/.kimi-code/bin/kimi)

Which open platform/subscription were you using?

N/A — self-hosted OpenAI-compatible provider (custom openai provider in config.toml). Reproduces without any account login.

Which model were you using?

kimi-k3 (any model behaves the same; this is a server/routing issue)

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Mode fields accepted by the REST prompt-submission schema — plan_mode and swarm_mode — are silently dropped by the server. As a result, when the web UI starts a session from a draft that has Swarm (or Plan) mode enabled, the first turn runs without the mode: the ## Swarm Mode enter-reminder is not injected, and GET /api/v1/sessions/{id}/status keeps reporting swarm_mode: false. The mode only takes effect from the second turn on, once the session profile gets synced through a later interaction.

Root cause, at the source level (main branch):

• packages/kap-server/src/protocol/rest-prompt.ts declares plan_mode / swarm_mode on promptSubmissionSchema (lines 27–28), so submissions carrying them validate fine.
• But the submit handler in packages/kap-server/src/routes/prompts.ts applies only model, thinking, permission_mode, disabled_tools, and skills. It never reads req.body.plan_mode / req.body.swarm_mode (nor tower_* / goal_*).
• The working path is POST /sessions/{id}/profile → applySessionAgentConfig (packages/kap-server/src/routes/sessionAgentConfig.ts), which correctly calls swarm.enter('manual') / plan.enter().
• On the web UI side (observed in the 0.43.0 web bundle), the draft→session promotion copies the draft's plan/swarm modes only into its local per-session state and sends them on the (inert) prompt fields; only tower mode is synced to the server profile during promotion. So the runtime never learns the mode for turn 1.

What steps can reproduce the bug?

Server-level repro (no UI involved):

TOKEN=$(cat ~/.kimi-code/server.token)
SID=$(curl -s -X POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"metadata":{"cwd":"/tmp"}}' http://127.0.0.1:58627/api/v1/sessions | jq -r .data.id)

# First turn with swarm_mode: true in the prompt body
curl -s -X POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"content":[{"type":"text","text":"Reply with just: OK"}],"model":"kimi-k3","swarm_mode":true}' \
  http://127.0.0.1:58627/api/v1/sessions/$SID/prompts

sleep 5
curl -s -H "Authorization: Bearer $TOKEN" http://127.0.0.1:58627/api/v1/sessions/$SID/status | jq .data.swarm_mode
# => false

grep -c "Swarm Mode" ~/.kimi-code/sessions/*/$SID/agents/main/wire.jsonl
# => 0 (no enter-reminder was injected)

The same prompt via the profile endpoint works as expected:

curl -s -X POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"agent_config":{"swarm_mode":true}}' http://127.0.0.1:58627/api/v1/sessions/$SID/profile

# the next plain prompt now runs with the "## Swarm Mode" enter-reminder in context
# and status.swarm_mode == true

plan_mode behaves the same way: present in the schema, dropped by the handler.

Web UI repro (the user-visible version):

1. Open kimi web, click New Session.
2. Enable Swarm mode in the draft composer (/swarm on or the + menu) — the Swarm pill shows.
3. Send a first message.
4. Ask the agent whether its context contains the ## Swarm Mode section, or inspect the session's wire.jsonl: the first turn has no enter-reminder. The reminder appears from the second turn onward.

What did you expect to happen?

A session whose first prompt is submitted with swarm_mode: true (or plan_mode: true) — which is exactly what the web UI sends when the draft composer has the mode enabled — should run its first turn in that mode. Either the submit handler should apply these fields (e.g. by funneling them through the same services applySessionAgentConfig uses), or the web UI should sync draft modes to the session profile during promotion; arguably both, so the API contract matches its schema either way.

Related

• #2198 reports the same family of problem (mode selection not reaching the runtime) on the Kimi Work desktop surface.

Start in packages/kap-server/src/routes/prompts.ts and compare the submit handler with applySessionAgentConfig in packages/kap-server/src/routes/sessionAgentConfig.ts; the schema is in packages/kap-server/src/protocol/rest-prompt.ts. Run the curl reproduction against a new session and verify that a first prompt with swarm_mode or plan_mode updates session status and injects the corresponding mode reminder.