command-code: shipped effort ladders are narrower than the live API accepts (and config cannot widen a pinned row) #5096

Client or integration

Codex CLI

Provider or upstream service

command-code (Command Code Provider API)

OpenCodex version

2.59.0

Endpoint or capability

reasoning metadata (COMMAND_CODE_MODEL_REASONING_EFFORTS in src/providers/command-code-efforts.ts)

Current behaviour

The shipped table pins several Command Code models to effort ladders narrower than the live API accepts, and 38 live models have no row at all. Because applyDirectReasoningEffortContracts() re-applies the registry value for those models (and the provider block is re-derived from the table on every ocx service restart), a user cannot widen a pinned ladder from config.json — ocx config set providers.command-code.modelReasoningEfforts (49 entries) is back to 17 entries after a restart.

Observed downstream: command-code/deepseek-deepseek-v4.1-flash advertises high, max, ultra in ~/.codex/opencodex-catalog.json / models_cache.json, so Codex offers no low, medium, or xhigh for a model the gateway serves them on. Models with no row advertise no effort control at all.

Expected behaviour

The table's rows should match what the upstream accepts. Measured 2026-09-17 against POST https://api.commandcode.ai/provider/v1/chat/completions (GOAT plan key, OpenAI-completions shape):

• reasoning_effort accepts exactly low | medium | high | xhigh | max.
• none and minimal are rejected for every model: 400 invalid_request_error: Invalid option: expected one of "low"|"medium"|"high"|"xhigh"|"max".
• Omitting the field still returns reasoning / reasoning_details, so there is no honest "off" rung.
• The accepted subset varies per model and is not contiguous (moonshotai/Kimi-K2.7-Code-Highspeed has no medium; poolside/laguna-s-2.1-free accepts only medium).

Rows that disagree with the measurement:

Missing rows (38 live models), all measured: moonshotai/Kimi-K3 low..max, moonshotai/Kimi-K2.7-Code low..xhigh (no max), moonshotai/Kimi-K2.7-Code-Highspeed low, high, xhigh, max, MiniMaxAI/MiniMax-M3 low..max, xiaomi/mimo-v2.5 low..max, xiaomi/mimo-v2.5-pro low..high, xai/grok-4.5 / xai/grok-4.6 low..max, tencent/hy3-paid / tencent/hy4-preview low..max, stepfun/Step-3.7-Flash low..max, Qwen/Qwen3.8-Max low..max, Qwen/Qwen3.8-27B low..max, Qwen/Qwen3.7-* low..xhigh, Qwen/Qwen3.6-* low..xhigh, meta/muse-spark-1.2* / 1.3* low..max, nvidia/nemotron-3-ultra-550b-a55b low..max, meituan/LongCat-2.0:free low..max, inclusionai/ling-3.0-flash-sante:free low..max, thinkingmachines/inkling-small low..max, poolside/laguna-s-2.1-free medium only, google/gemini-3.8-flash low..high.

Minimal redacted request or reproduction

# every rung, per model
curl -sS https://api.commandcode.ai/provider/v1/chat/completions \
  -H "Authorization: Bearer $CMD_KEY" -H 'Content-Type: application/json' \
  -d '{"model":"deepseek/deepseek-v4.1-flash","messages":[{"role":"user","content":"hi"}],
       "max_tokens":64,"reasoning_effort":"xhigh"}'

# what the table produces today (Codex catalog), after `ocx sync`:
jq -r '.models[] | select(.slug=="command-code/deepseek-deepseek-v4.1-flash")
       | [.supported_reasoning_levels[].effort] | join(",")' ~/.codex/opencodex-catalog.json

Two probe traps worth knowing: max_tokens: 8 makes some models answer Invalid 'max_output_tokens' (looks like an unsupported model), and an 8×8 test PNG is rejected as invalid image by several upstreams (looks like "no vision"). Use max_tokens >= 64 and a real PNG.

Actual response or error

# reasoning_effort from the shipped rows that is not accepted / not offered:
$ curl ... -d '{"model":"deepseek/deepseek-v4.1-flash", ..., "reasoning_effort":"xhigh"}'
HTTP 200  (accepted — but Codex never offers it)

$ curl ... -d '{"model":"deepseek/deepseek-v4.1-flash", ..., "reasoning_effort":"minimal"}'
HTTP 400  {"error":{"message":"Invalid option: expected one of \"low\"|\"medium\"|\"high\"|\"xhigh\"|\"max\"","type":"invalid_request_error"}}

$ jq -r '...' ~/.codex/opencodex-catalog.json
high,max,ultra          # after ocx sync, from the shipped table

Upstream documentation

https://commandcode.ai/docs/provider (OpenAI-compatible endpoint; no public per-model effort table). The model profile pages the table's profileUrl points at render client-side and ship an empty reasoningEfforts payload, which is why the in-file note about a dead self-refresh matches what I measured too.

Suggested mapping or implementation notes

Replace the affected rows (and add the 38 missing ones) with the measured ladders above; they are per-model measurements, not family inferences. If it helps, I can open a PR containing the full 46-model table plus the image-modality list, generated from the probe results.

Also relevant for the default rows: on the GOAT plan these return 403 permission_error MODEL_NOT_IN_PLAN (Pro and above, or Provider): all claude-*, gpt-5.4, gpt-5.4-mini, gpt-5.5, gpt-5.3-codex, gpt-5.6-terra, google/gemini-3.1-flash-lite, google/gemini-3.5-flash, google/gemini-3.5-flash-lite, google/gemini-3.6-flash, meta/muse-spark-1.1, sakana/fugu-ultra. /provider/v1/models lists every model regardless of plan access.

Additional context and attachments

No HAR/screenshot needed: the disagreement is between the shipped table and live HTTP responses, reproducible with the two curl commands above. Locally I carry the measured table as an idempotent patch script that re-runs after each ocx update; I would rather delete it in favour of an upstream fix.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on an upstream specification or a concrete client requirement.