MoonshotAI / MoonshotAI/kimi-code

Feature request: named subagent model slots ([subagent_models]) so the main agent can choose subagent models by task

Open
#2,250 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

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

Description

What feature would you like to see?

Problem. With the experimental secondary-model feature, newly spawned subagents (Agent / AgentSwarm) can bind to a single [secondary_model] instead of always inheriting the caller's model. A single alternate slot is often not enough: routine search/formatting wants a cheap, fast model; architecture review or complex debugging wants the highest-quality one; codebase-wide work wants a long-context one. Today the main agent also has no information to make that choice — it only knows "secondary" and "primary".

Proposal: named subagent model slots. A [subagent_models.<slot>] config section where each slot carries a base model plus the guidance the main agent needs to choose:

[subagent_models.fast]
model = "provider/fast"
description = "Low-cost, low-latency model for routine searches and formatting."
recommended_for = ["search", "formatting"]
default = true

[subagent_models.quality]
model = "provider/quality"
description = "Highest reasoning quality for architecture and complex code."
recommended_for = ["architecture", "complex_debugging"]
max_output_size = 16384

Behavior:

  • Agent and AgentSwarm expose the slot names dynamically as the model parameter enum, and their tool descriptions list every slot's model, description, and recommended uses, so the main agent can choose per task (plus primary for its own model).
  • Selection priority: explicit tool-call model > agent profile model_preference (now a slot name) > the slot marked default > the first slot. With no named slots, the legacy [secondary_model] keeps working unchanged as a single secondary slot; with neither, subagents inherit the caller's model. Resumed subagents always keep their recorded model.
  • Fields beyond model / description / recommended_for / default act as a per-slot model patch (same fields as [models.*.overrides]). Patched slots synthesize a runtime-only derived entry (__sm__<slot>): never persisted to config.toml, hidden from GET /models and from the models view of GET /config (mirroring the __secondary__ hiding introduced in #2228), and never overriding a user-defined [models.__sm__*] entry — a collision produces a session warning, tool metadata degrades gracefully, and spawning on that slot fails closed.
  • Gated behind the existing secondary-model experimental flag (KIMI_CODE_EXPERIMENTAL_SECONDARY_MODEL); behavior with the flag off is unchanged, and the TUI is unaffected (same surface support as the current secondary-model experiment: kimi web and experimental kimi -p).
Additional information

A complete implementation is ready on my fork — engine (agent-core-v2) + server routes, ~90 new tests across config/tool/warning/API layers, bilingual user docs, and a changeset — kept in sync with main (including #2228 and the hostIdentity refactor). Happy to open a PR if maintainers are open to this direction, and to adjust the design based on feedback first.

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 reviewing the existing secondary-model experiment, the agent-core-v2 engine, and the server routes; #2228 is cited as relevant context. Use the proposed config, tool, warning, and API test layers as the implementation checklist. Done means the named-slot behavior, compatibility rules, documentation, and changeset are covered, including the reported ~90 tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
ai, cli
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.