Skip to content

feat(agent-acp): support config-option model + thought-level reasoning (Kimi)#2

Merged
huntharo merged 1 commit into
mainfrom
feat/acp-configoption-model-and-thought-level
Jun 8, 2026
Merged

feat(agent-acp): support config-option model + thought-level reasoning (Kimi)#2
huntharo merged 1 commit into
mainfrom
feat/acp-configoption-model-and-thought-level

Conversation

@huntharo

@huntharo huntharo commented Jun 8, 2026

Copy link
Copy Markdown
Contributor

Why

Kimi Code CLI (v0.11.0) advertises its model and thinking controls as ACP configOptions (category: "model" and category: "thought_level"), not the top-level models / modes that Gemini/Grok/Qwen use. Two user-visible consequences in a downstream consumer (PwrSnap capture enrichment):

  1. Model name was blank. The one-shot client derived the model only from models.currentModelId, which Kimi never sets → model: "" → "model unavailable".
  2. Reasoning hint was ignored → slow. applyReasoning only matched ACP modes; Kimi has none, so a neutral effort: "low" was silently dropped and the model always ran its full thinking pass. Measured against a real Kimi enrichment turn: thinking ON ≈ 54s vs OFF ≈ 8s (~6.5×) for identical output.

What

  • Model reporting — read the effective model from the model configOption when models.currentModelId is absent, in both startThread() and the one-shot listModels(). A host now sees kimi-code/kimi-for-coding / label "Kimi-k2.6". New exported helpers: modelIdFromCapabilities, modelsFromCapabilities, modelConfigOption.
  • Reasoning effortapplyReasoning falls back to a thought_level (or id thinking) configOption when no mode matches: low-effort tokens → its OFF value, high-effort → its ON value, via session/set_config_option. New exported helper: reasoningValueForThoughtLevel.

Both are additive and backward-compatible — they only engage when the relevant configOption is present and the existing models/modes path finds no match, so Gemini/Grok/Qwen behavior is unchanged.

Tests

+14 tests (128 total, all green): capability helpers, the pure reasoningValueForThoughtLevel mapping, and one-shot integration tests asserting the model comes from the configOption, low effort issues set_config_option {configId:"thinking", value:"off"}, and no redundant round-trip when the value already matches.

pnpm build, pnpm typecheck, pnpm test, pnpm lint:licenses, pnpm lint:boundaries all pass locally.

🤖 Generated with Claude Code

…g (Kimi)

Kimi Code CLI advertises its model and reasoning controls as ACP
`configOptions` (category "model" / "thought_level"), not the top-level
`models` / `modes` that Gemini/Grok/Qwen use. As a result a host saw
"model unavailable" for every Kimi run, and a neutral `reasoning` hint was
silently ignored — so a reasoning model always ran its (slow) thinking pass
even for one-shot structured jobs like capture enrichment.

- Read the effective model from the `model` configOption when no
  `models.currentModelId` is advertised (startThread + one-shot listModels).
  New helpers: modelIdFromCapabilities, modelsFromCapabilities,
  modelConfigOption.
- applyReasoning falls back to a thought_level/`thinking` configOption: low
  effort -> its OFF value, high -> its ON value, via session/set_config_option.
  New helper: reasoningValueForThoughtLevel.

Additive + backward-compatible: only engages when the configOption exists and
the existing models/modes path finds nothing. +14 tests (128 total).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@huntharo huntharo merged commit 59b67ba into main Jun 8, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant