Skip to content

fix(command-code): preserve xhigh instead of rewriting it to max - #14929

Merged
diegosouzapw merged 2 commits into
cheaper-inference:release/v3.8.51from
adivekar-utexas:fix/command-code-preserve-xhigh-effort
Sep 29, 2026
Merged

diegosouzapw merged 2 commits into
cheaper-inference:release/v3.8.51from
adivekar-utexas:fix/command-code-preserve-xhigh-effort

Conversation

@adivekar-utexas

Copy link
Copy Markdown
Contributor

The bug

Command Code's validator advertises low|medium|high|xhigh|max — xhigh is a native and distinct tier. But open-sse/executors/base/reasoningEffort.ts had Command Code in its isMaxTierTarget list, which rewrote xhigh → max unconditionally:

if (isMaxTierTarget && effortStr === "xhigh") {
  return writeEffortValue(b, "max", c);
}

writeEffortValue writes to every carrier, so both top-level reasoning_effort and the nested reasoning.effort were silently changed. Observed on the wire: a payload setting "reasoning": {"effort": "xhigh"} went upstream as "reasoning": {"effort": "max"}.

Why it is wrong

  1. It spends a different reasoning level than the caller asked for.
  2. The premise is false for Command Code. The same file quotes Command Code's own 400 message — expected one of "low"|"medium"|"high"|"xhigh"|"max" — which is the proof that xhigh is accepted.
  3. It preempted the correct mechanism that already exists further down: if (supportsXHigh) return body; // model accepts xhigh natively. supportsXHighEffort() defaults to true for unlisted models, so the fix is to stop short-circuiting before it.

The change

Command Code is removed from isMaxTierTarget. Nothing else moves.

Case Before After
command-code + xhigh, unlisted model max xhigh
command-code + max max max
GLM 5.1+ / DeepSeek V4+ / Kimi K3+ + xhigh, any provider max max
ollama-cloud or opencode-go + xhigh max max
openrouter + xhigh xhigh xhigh

The model-level ceilings are deliberately kept, because those families genuinely top out at max in their own native API.

Tests

Two existing tests encoded the bug and are inverted to pin the fix:

  • command-code maps normalized xhigh back to max becomes command-code preserves native xhigh on every carrier, asserting both reasoning_effort and nested reasoning.effort survive.
  • The Qwen case asserted xhigh → max on cmd. It now asserts max on opencode-go (unchanged behaviour) and xhigh on command-code.

Three added cases bound the change so it cannot be over-applied: literal max still passes through, max-tier model families still collapse on command-code, and ollama-cloud is unchanged.

Sweep: every unit test mentioning xhigh was run — 123 suites, 1938 assertions passing. chatcore-translation-paths has 3 failures (tests 2/64/72, none about effort) that are pre-existing — confirmed identical with this patch stashed. ESLint clean, open-sse-typecheck 0 errors, check:file-size OK, complexity ratchets OK (2931/3218 and 1328/1437).

open-sse/executors/base/reasoningEffort.ts is not in the Stryker mutate set, so no tap.testFiles registration is needed.

Command Code's own validator advertises low|medium|high|xhigh|max (the quoted
enum in the minimal mapping just above), so xhigh is a native and distinct tier
there. The provider-wide isMaxTierTarget rule rewrote it to max unconditionally,
which spent a different reasoning level than the caller asked for, and it also
overwrote the nested reasoning.effort carrier that the Responses path reads.

Command Code is removed from isMaxTierTarget. Everything else is unchanged: the
model-level ceilings (GLM 5.1+, DeepSeek V4+, Kimi K3+) still map xhigh to max
regardless of provider, as do the Ollama Cloud and OpenCode Go gateways, and
OpenRouter still passes xhigh through. Unlisted models already preserved xhigh
via supportsXHighEffort(); this early return was preempting that.

Two tests encoded the old behaviour and are inverted to pin the new one. Three
added cases bound the change: literal max still passes through, max-tier model
families still collapse on command-code, and ollama-cloud is unchanged.
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.

2 participants