fix(kimi): forward role-specific model config to launch (restore deferred pending CLI verification)

[anmol0b]

What

Adds appendModelFlag to the Kimi adapter, called from GetLaunchCommand, so a configured
agentConfig.model is forwarded as --model <model> to the kimi CLI. Also adds a GetConfigSpec override advertising the model field, matching claude-code and codex (#2869). (kiro #2932 handles model config through a hooks file rather than a CLI flag, so it isn't precedent for this approach; copilot's equivalent fix, #2975, is still open and not yet merged.)

Unlike the Copilot fix, this does not wire appendModelFlag into GetRestoreCommand.
Kimi's docs don't confirm --model composes with --session on resume, so forwarding it
there is left as a documented fast-follow rather than guessed at.

Why

Fixes #2890. A Kimi worker/orchestrator configured with a specific model silently fell back
to kimi's global default because the adapter never read cfg.Config.Model — same
root-cause pattern as #2769 (Codex), #2895 (Copilot), and #2897 (Vibe) in this audit series.

How

• Mirrors fix: pass Codex model config to launch commands #2869's appendModelFlag pattern: appends --model only when
  strings.TrimSpace(cfg.Config.Model) is non-blank, so an unconfigured launch is
  byte-for-byte unchanged.
• GetRestoreCommand is intentionally left unchanged. A doc comment on appendModelFlag
  and an inline comment on GetRestoreCommand both point back to this decision, and a
  dedicated regression test (TestGetRestoreCommandDoesNotForwardModelOverride) locks it in
  so a future "just mirror Copilot/Codex" edit doesn't silently wire it without verifying
  kimi --model X --session Y against a real install first.
• Replaced the now-outdated TestGetConfigSpecEmpty (asserted zero fields) with
  TestGetConfigSpecAdvertisesModelField, since that assumption no longer holds once
  model is declared.

Testing

Full package run, all passing (35 tests, no regressions):

• TestGetConfigSpecAdvertisesModelField
• TestGetLaunchCommandAppendsModelFlagWhenConfigured
• TestGetLaunchCommandOmitsModelFlagWhenBlank
• TestGetLaunchCommandModelFlagComposesWithApprovalFlags
• TestGetRestoreCommandDoesNotForwardModelOverride

Open follow-up

Verify --model + --session composition against a real kimi install, then wire
appendModelFlag into GetRestoreCommand in a follow-up PR (tracked against #2890).

Checklist

• Branched from main (or continuing an existing PR branch)
• One focused change; links the related issue when applicable
• Follows AGENTS.md conventions and PR hygiene
• Tests added/updated for user-visible behavior where it makes sense
• Relevant CI checks pass for the area touched (go, frontend, etc.)

[codebanditssss]

Careful PR, and the tests are the strongest part — reflect.DeepEqual against the full argv including flag ordering, plus the whitespace-only case and composition with the approval flags. That's the version of these tests that actually catches a regression rather than just executing the line. go test ./internal/adapters/agent/kimi/... green locally, all 9 checks green.

On deferring the restore path — I think that's right, and I can back it with precedent. You framed it as caution pending verification, but it also matches what the codebase already does:

• claudecode forwards --model on launch (claudecode.go:172), and its GetRestoreCommand emits only --resume <sessionID> plus an optional --append-system-prompt. No model.
• codex is the one that wires both (codex.go:109 and :151).

So launch-yes/restore-no is what the most prominent adapter already does. Kimi matching claudecode here isn't a gap to close later, it's the dominant existing shape — worth noting in case that changes how urgent the follow-up feels.

Approving. Two non-blocking notes inline, both about comments and prose rather than behaviour.

[codebanditssss]

This doc comment is good and does the job it claims. The other half of the pair doesn't exist though.

The PR description says "a doc comment on appendModelFlag and an inline comment on GetRestoreCommand both point back to this decision." GetRestoreCommand is untouched by this diff and carries no such comment.

That matters a little more than a typical missing comment, because the scenario you're defending against is specifically someone opening GetRestoreCommand to "just mirror Codex" — and that person is looking at the function you didn't annotate. They'd have to already know to check appendModelFlag, or discover it by tripping the test.

TestGetRestoreCommandDoesNotForwardModelOverride does catch it, so the safeguard genuinely holds and this isn't a correctness issue. But the breadcrumb you designed for is the cheaper of the two to hit, and it's a two-liner:

func (p *Plugin) GetRestoreCommand(ctx context.Context, cfg ports.RestoreConfig) (cmd []string, ok bool, err error) {
	// Deliberately does not forward cfg.Config.Model: --model + --session
	// composition is unverified against a real kimi install (see #2890 and
	// appendModelFlag). Pinned by TestGetRestoreCommandDoesNotForwardModelOverride.

[codebanditssss]

Not about this hunk, but this is the closest anchor — the sibling list in the description is broader than what's actually on main.

Checking origin/main:

• copilot has no model forwarding at all, so fix(copilot): forward role-specific model config to launch and restore #2975 isn't merged.
• vibe likewise, so Vibe ignores role-specific model config on launch #2897 isn't either.
• kiro does handle the model, but through a different mechanism entirely — it writes it into a hooks file (kiro/hooks.go:268) rather than passing a CLI flag.

So "matching claude-code, codex (#2869), kiro (#2932), and copilot (#2975)" is in practice "matching claude-code and codex." Doesn't change a line of this PR, but a reviewer taking it at face value would build the wrong mental map of where the audit series has actually landed, and kiro in particular isn't a precedent for the flag approach at all.

Worth a quick edit to the description so the series stays legible as it grows.

Also minor: the last two checklist boxes are unticked, but all 9 checks are green on this head.

[codebanditssss]

@anmol0b — new information relevant to the restore deferral here, which arrived after I approved.

@Hardik180704 verified the equivalent composition against a real Pi CLI in #2989:

Verified against the real Pi CLI. I resumed an existing session using pi --model openai/gpt-4o --session <id>. Pi found the correct session and attempted to use the explicitly provided OpenAI model, confirming that --model and --session are accepted together and forwarded correctly.

That's the first actual evidence in the series — every one of these PRs, including this one, had been reasoning from the same absence of it.

To be clear about what it does and doesn't show: it settles Pi, not Kimi. They're different CLIs that happen to share a --session flag name, so this isn't proof for kimi --model X --session Y. Your caution wasn't wrong.

But it does mean the cost of checking is now known to be low — one resume against a real install — and it shifts the prior. Worth knowing because TestGetRestoreCommandDoesNotForwardModelOverride is currently pinning the absence of a feature. If Kimi behaves like Pi, that test is asserting a restriction that doesn't need to exist, and its comment tells the next person not to wire it without re-verifying. Cheap to leave, but also cheap to resolve, and resolving it would make the series consistent.

Nothing blocking — this stays approved either way. Just didn't want the deferral to outlive the uncertainty that motivated it.

[illegalcall]

Reviewed and approving. ✅

• gofmt clean, go vet clean, full kimi package test suite passes locally (go 1.24.1).
• Verified against Moonshot's docs that kimi --model <model> is a real, documented launch flag, so the launch-path forwarding will take effect.
• Especially appreciate the discipline on the restore path: not forwarding --model alongside --session when the composition is unverified, documenting exactly why, and locking the decision in with TestGetRestoreCommandDoesNotForwardModelOverride so a future "just mirror Copilot/Codex" edit can't silently regress it. This is the right posture when the CLI behavior can't be confirmed.

[somewherelostt]

Thanks for contributing to Agent Orchestrator.

This PR is being picked up by the current external contributor on-call pair:

• @illegalcall
• @Pulkit7070

If someone is already working on this, please continue as usual.
The on-call pair is added for visibility, tracking, and support, not to take over the work.
If you need help with review, direction, reproduction, or next steps, please tag @illegalcall and @Pulkit7070 here.

For faster context or live questions, you can also join the AO Discord.

Join the session here:
https://discord.gg/H6ZDcUXmq

Come by if you want to see what is being built, ask questions, or just hang around with the community.

[anmol0b]

Thanks for catching this @codebanditssss

Added the missing breadcrumb comment on
GetRestoreCommand, matching the one on appendModelFlag. Also corrected the
sibling list in the description (you're right that copilot #2975 isn't
merged and kiro #2932 uses a hooks-file mechanism, not a CLI flag : narrowed
to claude-code and codex). Ticked the remaining checklist boxes now that all
9 checks are green.

On the restore deferral: I don't have a real kimi install to verify
--model + --session against right now, so leaving it as-is. The test and
comments still correctly pin the restriction until someone can check — happy
for a follow-up PR to resolve it if someone has kimi installed.