Catalog pinned to CLI 1.44.0: models added upstream (deepseek-v4.1-flash, etc.) can never have reasoning enabled

[Fu3rte]

Bundled catalog is generated from command-code@1.44.0; CLI is at 1.53.0. Models added upstream since then are missing from MODEL_REASONING/MODEL_EFFORTS, so their reasoning can never be enabled.

Example: deepseek/deepseek-v4.1-flash

Upstream registry (command-code@1.53.0, dist/cli.mjs):

DEEPSEEK_V4_1_FLASH:{id:"deepseek/deepseek-v4.1-flash",reasoning:!0,
  reasoningEfforts:["low","high","max"],contextWindow:1e6}

Bundled catalog: absent from both MODEL_REASONING and MODEL_EFFORTS → reasoning: false, no levels.
The endpoint accepts it fine; the parameter is simply never sent.

Other models affected (reasoning:true upstream, absent locally): minimax/minimax-m3-free (low/medium/high), tencent/Hy3, gpt-6-astra (low/medium/high/xhigh/max).

Root cause

MODEL_EFFORTS/MODEL_REASONING drive everything, and commandcode-catalog-overrides.ts only offers MODEL_EFFORT_OVERRIDES — an efforts hook. There is no way to override the reasoning flag, so a model missing from the generated catalog stays permanently non-reasoning:

• src/core.ts:145 — if (!level || level === "off" || !model.reasoning) return undefined → reasoning_effort never sent
• index.ts:137 — compat.supportsReasoningEffort: MODEL_EFFORTS[model.id] !== undefined → false
• src/models.ts:86 — thinkingMetadataForModel returns undefined for any id not in MODEL_REASONING

So MODEL_EFFORT_OVERRIDES alone can't fix it either — efforts without the flag still hit the core.ts:145 guard.

Reproduce

pi -p --model commandcode/deepseek/deepseek-v4.1-flash --thinking max --no-session "prove it thinks"
# no reasoning content, no reasoning tokens

Workaround (works today, no fork needed)

~/.pi/agent/models.json:

{"providers":{"commandcode":{"modelOverrides":{
  "deepseek/deepseek-v4.1-flash":{
    "reasoning":true,
    "thinkingLevelMap":{"minimal":null,"low":"low","medium":null,"high":"high","xhigh":null,"max":"max"},
    "compat":{"supportsReasoningEffort":true}
  }}}}}

All three are required — reasoning clears the core.ts:145 guard, thinkingLevelMap maps pi levels, and compat.supportsReasoningEffort is what actually puts the field on the wire.

Verified against a local echo server: --thinking high → reasoning_effort:"high", max → "max", off → absent. Against the real endpoint, a hard prompt returns thinking content (e.g. 219 reasoning tokens); low correctly returns none.

Suggested fix

Either bump COMMAND_CODE_CLI_VERSION and re-run npm run sync:commandcode-catalog (fixes all four, but drifts again), or add a reasoning-flag override to commandcode-catalog-overrides.ts:

export const MODEL_REASONING_OVERRIDES: Readonly<Record<string, true>> = {
  "deepseek/deepseek-v4.1-flash": true,
  // ...
}

merged into MODEL_REASONING in src/models.ts alongside MODEL_EFFORT_OVERRIDES, so newly added upstream models can be enabled without waiting for a catalog sync. Note the daily drift check (check:commandcode-catalog) currently only compares the generated file, so it doesn't catch models that upstream added but the pinned version never had.

[pierreraby]

I hit the same problem and traced it, so sharing what I found here before proposing changes.

The catalog is not the only thing that is stale — the sync that should fix it has been failing on every run since 2026-09-04 (8 consecutive scheduled failures on main, SHA adea658), so the automation could never propose the catalog update.

Three distinct blockers, all reproduced locally:

1. The sync cannot satisfy its own guard. tests/test-models.ts requires that a manual effort override be deleted by hand as soon as upstream publishes its own levels. command-code@1.53.1 now ships efforts for all five meta/muse-spark-* entries, so the sync regenerates the catalog, then fails test:models, then format:check, and create-pull-request is skipped. The workflow stays red and blocks its own pull request.

2. The documented end state is unreachable. Following the manual procedure does not reach green either: once the five overrides are gone, MODEL_EFFORT_OVERRIDES is empty and its assert.ok(...length > 0) fails.

3. tests/test-pi-local.mjs fails on unmodified main. pi@0.85.0 started streaming Anthropic Messages through the SDK, which appends ?beta=true to /v1/messages. The mock compares the exact URL, answers 404, and the suite dies at test-pi-local.mjs:944. CI installs pi@latest unpinned, so every pull request has been red since then — this is also why the npm test step of feat(models): enable reasoning for deepseek-v4.1-flash #91 fails.

On the reasoning:true + efforts combination: the two upstream sources cannot actually disagree. parseBundleModelCapabilities() emits reasoningModelIds for an entry that has reasoning:!0 or reasoningEfforts:[, so a model with efforts always carries the flag in the generated catalog. I verified across both 1.44.0 and 1.53.1: zero flags added, zero lost. That means an override of the reasoning flag alone is not needed — syncing the catalog is what fixes deepseek/deepseek-v4.1-flash, and it fixes meta/muse-spark-* and MiniMaxAI/MiniMax-M3 at the same time.

Two things worth knowing about the override workaround, both verified against the live endpoint and against a real pi binary with an isolated HOME:

• modelOverrides entries for gpt-6-astra and minimax/minimax-m3-free have no effect: pi ignores unknown model ids, and neither id is present in GET /provider/v1/models (69 models, neither id returned) even though both exist in the CLI bundle and in models.md. No catalog sync can make them selectable in pi — that looks like a separate Provider API gap.
• GET /provider/v1/models returns only id, name and context_length; it carries no capability data. So the provider cannot derive reasoning/efforts from the live endpoint — it has to refresh the CLI-derived snapshot, which is exactly what is broken.

I opened #95, which makes the sync prune obsolete overrides itself (idempotent), drops the assertion that made the override-free state unreachable, and fixes the pi 0.85 mock routing so PRs can go green again. With the catalog synced, deepseek/deepseek-v4.1-flash reports thinking: yes in pi --list-models with no local models.json override at all.