Client or integration
Codex App
Area
Catalog / models
Summary
A newly live Command Code model, deepseek/deepseek-v4.1-flash (Codex slug command-code/deepseek-deepseek-v4.1-flash), arrives in the injected catalog with supported_reasoning_levels: [] and no default_reasoning_level. In Codex App the reasoning-effort picker is empty / unusable.
This is the same hole as #2883 / #2917: Command Code /provider/v1/models does not carry an effort contract, so the picker is filled only from the static table in src/providers/command-code-efforts.ts. That table still has no row for deepseek/deepseek-v4.1-flash on current main (checked against https://github.com/lidge-jun/opencodex/blob/main/src/providers/command-code-efforts.ts). configuredReasoningEfforts therefore falls through to the provider-level empty ladder.
The model is a 2026-09-10 live arrival (modelDiscovery.recentArrivals). Vanilla ocx effort model command-code/deepseek/deepseek-v4.1-flash reports supportedEfforts: [].
Same-class companion on the same account: google/gemini-3.8-flash also has an empty ladder.
Reproduction
- OpenCodex 2.50.0 with Command Code OAuth (
providers.command-code.liveModels = true).
- Select
deepseek/deepseek-v4.1-flash (it is in selectedModels / live catalog).
ocx inspect catalog --json → slug command-code/deepseek-deepseek-v4.1-flash has supported_reasoning_levels: [].
- Codex App model picker for that slug shows no reasoning-effort rungs.
Stock table keys on main still stop at deepseek/deepseek-v4-flash / deepseek/deepseek-v4-pro / deepseek/deepseek-v4-flash-vision-exp. No deepseek/deepseek-v4.1-flash row.
Version
2.50.0 (@bitkyc08/opencodex). GitHub main src/providers/command-code-efforts.ts also lacks the row.
Operating system
macOS 26.5.2 (25F84)
Provider and model
command-code / deepseek/deepseek-v4.1-flash
Also empty: command-code / google/gemini-3.8-flash
Logs or error output
Vanilla (no local overlay):
ocx effort model command-code/deepseek/deepseek-v4.1-flash --json
{
"provider": "command-code",
"model": "deepseek/deepseek-v4.1-flash",
"reasoningDisabled": false,
"supportedEfforts": [],
"wireMap": null,
"mappedTiers": {}
}
Catalog entry before overlay: supported_reasoning_levels: [], default_reasoning_level absent.
Suggested ladder (measured, not live-probed)
Same decode recipe as #2917. commandcode.ai profile pages render client-side; the delivered HTML still ships a serialized payload whose compact arrays are effort-table indices.
On a 2026-09-11 fetch of https://commandcode.ai/models/deepseek-v4-1-flash the same page carries already-committed rows, so the index map can be cross-checked:
gpt-5.6-luna [231,232,233,234,301] → committed low, medium, high, xhigh, max
google/gemini-3.7-flash [231,232,233] → committed low, medium, high
z-ai/glm-5.3-flash [231,233,301] → committed low, high, max
deepseek/deepseek-v4-flash [233,301] → committed high, max
deepseek/deepseek-v4-pro [233,301] → committed high, max
Therefore:
deepseek/deepseek-v4.1-flash [231,233,301] → low, high, max
google/gemini-3.8-flash [231,232,233] → low, medium, high (same-class leftover)
DeepSeek's public thinking-mode table (https://api-docs.deepseek.com/guides/thinking_mode) also documents low / high / max with default high, and maps medium → high, xhigh → high, ultra → max. No authenticated Command Code /alpha/generate accept/reject probe was run.
Profile-page auto-refresh (refreshCommandCodeReasoningEfforts) is still dead for every row, as noted on #2883. A one-line table add is the same fix shape as #2917.
I am not asking to relax modelRecordValue; bridging deepseek-v4-flash onto deepseek-v4.1-flash by stem would be wrong (V4.1 is a different model, and Command Code's own payload already differs: [233,301] vs [231,233,301]).
Checks
Client or integration
Codex App
Area
Catalog / models
Summary
A newly live Command Code model,
deepseek/deepseek-v4.1-flash(Codex slugcommand-code/deepseek-deepseek-v4.1-flash), arrives in the injected catalog withsupported_reasoning_levels: []and nodefault_reasoning_level. In Codex App the reasoning-effort picker is empty / unusable.This is the same hole as #2883 / #2917: Command Code
/provider/v1/modelsdoes not carry an effort contract, so the picker is filled only from the static table insrc/providers/command-code-efforts.ts. That table still has no row fordeepseek/deepseek-v4.1-flashon currentmain(checked against https://github.com/lidge-jun/opencodex/blob/main/src/providers/command-code-efforts.ts).configuredReasoningEffortstherefore falls through to the provider-level empty ladder.The model is a 2026-09-10 live arrival (
modelDiscovery.recentArrivals). Vanillaocx effort model command-code/deepseek/deepseek-v4.1-flashreportssupportedEfforts: [].Same-class companion on the same account:
google/gemini-3.8-flashalso has an empty ladder.Reproduction
providers.command-code.liveModels = true).deepseek/deepseek-v4.1-flash(it is inselectedModels/ live catalog).ocx inspect catalog --json→ slugcommand-code/deepseek-deepseek-v4.1-flashhassupported_reasoning_levels: [].Stock table keys on
mainstill stop atdeepseek/deepseek-v4-flash/deepseek/deepseek-v4-pro/deepseek/deepseek-v4-flash-vision-exp. Nodeepseek/deepseek-v4.1-flashrow.Version
2.50.0 (
@bitkyc08/opencodex). GitHubmainsrc/providers/command-code-efforts.tsalso lacks the row.Operating system
macOS 26.5.2 (25F84)
Provider and model
command-code / deepseek/deepseek-v4.1-flash
Also empty: command-code / google/gemini-3.8-flash
Logs or error output
Vanilla (no local overlay):
Catalog entry before overlay:
supported_reasoning_levels: [],default_reasoning_levelabsent.Suggested ladder (measured, not live-probed)
Same decode recipe as #2917. commandcode.ai profile pages render client-side; the delivered HTML still ships a serialized payload whose compact arrays are effort-table indices.
On a 2026-09-11 fetch of https://commandcode.ai/models/deepseek-v4-1-flash the same page carries already-committed rows, so the index map can be cross-checked:
gpt-5.6-luna[231,232,233,234,301]→ committedlow, medium, high, xhigh, maxgoogle/gemini-3.7-flash[231,232,233]→ committedlow, medium, highz-ai/glm-5.3-flash[231,233,301]→ committedlow, high, maxdeepseek/deepseek-v4-flash[233,301]→ committedhigh, maxdeepseek/deepseek-v4-pro[233,301]→ committedhigh, maxTherefore:
deepseek/deepseek-v4.1-flash[231,233,301]→low, high, maxgoogle/gemini-3.8-flash[231,232,233]→low, medium, high(same-class leftover)DeepSeek's public thinking-mode table (https://api-docs.deepseek.com/guides/thinking_mode) also documents
low / high / maxwith defaulthigh, and mapsmedium → high,xhigh → high,ultra → max. No authenticated Command Code/alpha/generateaccept/reject probe was run.Profile-page auto-refresh (
refreshCommandCodeReasoningEfforts) is still dead for every row, as noted on #2883. A one-line table add is the same fix shape as #2917.I am not asking to relax
modelRecordValue; bridgingdeepseek-v4-flashontodeepseek-v4.1-flashby stem would be wrong (V4.1 is a different model, and Command Code's own payload already differs:[233,301]vs[231,233,301]).Checks