Reasoning Effort “Default” is actually “off” for MiMo / Kimi models

[yanyihan-xiaomi]

Where: DeepSeek Harness · llm-pi-ai (third-party providers and custom gateways)

Summary

The extra Effort item labeled “Default” shows up on llm-pi-ai models that publish a reasoning ladder and have no profile defaultEffort — typically toggle models (Xiaomi MiMo, Moonshot/Kimi). Models with no ladder offer no effort control at all.

Three faces of one defect, fixed together (the last two are one idea: empty ≡ off on this path):

1. The picker inserts a “Default” row when defaultEffort is missing.
2. That choice — and a model pick that names no level — sends no reasoning parameter.
3. pi-ai maps a missing parameter to explicit off, so “Default” silently disables thinking.

Toggle models that think unless told otherwise are hit hardest: users expect “Default” to mean “on,” and get “off” with no error.

Chain:

ladder exists, no defaultEffort
        ↓
picker synthesizes "Default" (empty selection)
        ↓
request goes out with no reasoning parameter
        ↓
pi-ai maps missing parameter → explicit "off"
        ↓
MiMo / Kimi do not think

What you see

1. Add a third-party provider or custom gateway (Settings → Models). All of these are llm-pi-ai routes.
2. Do not set reasoning in cordis.patch.yml.
3. Open the Effort menu → extra “Default” in front of the real levels (“Off” / “High” for toggle models; the catalog ladder otherwise).
4. Leave “Default”, send a prompt → no reasoning, no reasoning_content. Usually no error.
5. Switch to “High” → thinking returns.

Same on every model that publishes a ladder without a profile defaultEffort — Xiaomi is the clearest case, not the only one.

Where to look

Location	What it shows
packages/client/ui-model-selection/src/client/ModelSelect.tsx	When defaultEffort === undefined, the picker inserts { effort: undefined, label: 'Default' }
packages/llm/llm-pi-ai/src/adapter.ts — profileOptions()	'off' and unset both become no reasoning field before pi-ai
packages/llm/llm-pi-ai/src/adapter.ts — describableReasoningLevel()	defaultEffort is only published when the profile sets reasoning
packages/llm/llm-deepseek/src/model-info.ts	DeepSeek route always publishes defaultEffort — no synthetic “Default” there

pi-ai’s “missing effort means off” is taken as given here; this report is only that DSH must not offer a “Default” that lands on it.

Workaround

- id: llm-pi-ai
  config:
    providers:
      xiaomi:          # every pi-ai route that should think
        reasoning: high

“Default” disappears; the picker starts on “High”. If a session already saved “Off”, pick “High” once.

Suggested fix

Picker-scoped: resolve the picker’s own default instead of synthesizing “Default”.

• Prefer defaultEffort, then high, then the first non-off level (picker-effort.ts).
• A model pick carries that level in the selection.
• The effort menu lists only real catalog levels — no synthetic “Default” row.
• Composer seat and /model popup share the same resolution.

This does not publish defaultEffort on the adapter, so dispatch and auxiliary calls that name no effort keep today’s behaviour (same seam as #8670). A route-wide defaultEffort would change every unnamed call on the route.

Sketch (packages/client/ui-model-selection/src/client/picker-effort.ts):

export function pickerDefaultEffort(reasoning): string | undefined {
  if (reasoning === undefined) return undefined
  if (reasoning.defaultEffort !== undefined) return reasoning.defaultEffort
  return reasoning.efforts.find(level => level.id === 'high')?.id
    ?? reasoning.efforts.find(level => level.id !== 'off')?.id
}

External PR kept only as a readable diff of this picker change:
yanyihan-xiaomi#2

Related

• #4627 — per-model default thinking level (same “unset → off” root)
• #7949 — MiMo toggle labels; same reasoning: high workaround
• #8670 — auxiliary call with no effort → thinking disabled

[argszero]

Thanks for the write-up — I checked the chain against the current master (571902028a) and it holds. Three things I'd add, because they change the shape of the fix.

1. The synthetic entry is narrower than "every llm-pi-ai route without reasoning:".

reasoningInfo() (packages/llm/llm-pi-ai/src/adapter.ts) opens with if (!model.reasoning) return {}. For a model pi-ai reports as carrying no reasoning metadata, the adapter publishes no reasoning field at all, so the picker has no effort row to render and no synthetic entry to insert. The extra Default item appears exactly where there is a ladder and no profile default — the toggle-model population you describe (MiMo, Kimi, …), not every route. That bounds the fix: describableReasoningLevel() returning undefined for an absent profile setting is only reachable where a ladder exists, so there is no case where a default has to be invented for a model that cannot think.

2. Publishing a default is not only a picker fix — it becomes the effective effort for every call on that route.

packages/llm/llm/src/index.ts resolves a call with const effective = requested ?? reasoning.defaultEffort. Once a real defaultEffort exists, every dispatch on that route that names no effort receives it, including the auxiliary calls. You link #8670, and that is the same surface: an auxiliary call inherits whatever the route resolves to unless something upstream special-cases it. So "+13/−3, prefer high" is right as far as it goes, but the blast radius is the whole route rather than the menu — if only some callers should think, the caller is where that has to be expressed, not the route default.

3. The picker is not the only reader, and one method does not cover them all.

If a deployment wants this before upstream lands, the seam exists: LlmRuntime methods can be shadowed on the instance (Symbol.for('cordis.original')) — we do exactly that for imageRequestPricing in @argszero/dsh-image-price-fallback. But defaultEffort is consumed on three separate paths, and covering one is not covering the others:

• ctx.llm.resolveModelInfo → packages/api/session-controller/src/catalog.ts → the browser picker;
• ctx.llm.resolveCallConfig → packages/api/session-controller/src/commands.ts, packages/acp/acp/src/model-control.ts, packages/subagent/tool-subagent/src/model-selection.ts → model selections;
• ctx.llm.prepareCall(config) → packages/core/agent-loop/src/agent.ts → the turn dispatch. This one resolves through the private resolveCallWithInfo, so shadowing the two public queries would fix the menu and leave the headless turn exactly as it is today.

Anything doing this must also leave alone a route that already declares defaultEffort.

Related but a different defect: @argszero/dsh-effort-route-guard@0.1.0 fixes the opposite direction — an effort that survives a route change and is then rejected by the new route (UNSUPPORTED_REASONING_EFFORT with no HTTP request). It does not cover this, and this would not cover it.

[yanyihan-xiaomi]

Thanks for the notes. I narrowed the write-up: synthetic “Default” only where there’s a ladder and no profile default.

Patch is now picker-only, no adapter defaultEffort:
yanyihan-xiaomi#2

[argszero]

A plugin-shaped workaround, for the case the profile default cannot cover.

Published: @argszero/dsh-effort-default-fallback@0.1.0 — source at https://github.com/argszero/dsh-effort-default-fallback.

Setting reasoning: in the provider profile is the documented fix, and it is the right one when a whole provider can share a default. The plugin exists for the case it cannot cover: that knob is per provider, while the models behind a gateway are not.

npm install @argszero/dsh-effort-default-fallback

Mount the shipped patch, then list the routes:

- insert:
    - id: effort-default-fallback
      name: '@argszero/dsh-effort-default-fallback'
      config:
        mode: enforce          # observe (the default) counts the same decisions and changes nothing
        defaults:
          xiaomi: high
          moonshot/kimi-k2-thinking: medium

defaults is the whole scope — a bare key names a provider, a provider/model key names one exact route and wins when both are listed. It answers only where the route declares a ladder, admits the level and has no default of its own. Every refusal — an unlisted route, a route with no ladder, a route that already declares a default, a level the ladder does not admit, off as a value, an unreadable route, a call that already names an effort — is left exactly as it was, and counted by name, so ctx.get('effortDefaultFallback').snapshot() answers whether the plugin is doing anything on a given deployment.

Two things from building it that bear on the fix above:

• The absence has three read paths, not one: resolveModelInfo (what the picker renders), resolveCallConfig (installing a session's selection) and prepareCall (the turn itself). Filling only the call config leaves the picker and a resumed session unchanged — worth knowing if the narrow fix lands in one of them.
• The turn path is only reachable from 0.2.1-alpha.2 on. LlmRuntime.prepareCall takes its third configure parameter from that build; on 0.1.7-rc.2, 0.2.0-rc.2 and 0.2.1-alpha.1 the runtime's signature is (config, signal?), so a plugin registered there would compile, mount, run, and change nothing on the turn while the two query layers kept answering — the kind of half-fix that still looks green. The package claims that line and probes both of its builds end to end rather than asserting them.

Neither changes the complaint: "Default" should not mean "off", and the narrowest fix is still that the picker should not offer a row the route cannot honour.