Repository navigation
Description
Client or integration
Codex App
Provider or upstream service
DeepSeek
OpenCodex version
main at 68d3aa0836648ae1d7b592fc5aa3b30146c0886d (the same mapping is also present in 2.10.0)
Endpoint or capability
Model discovery / reasoning metadata
Current behaviour
OpenCodex advertises high / xhigh / max for DeepSeek V4 models:
const DEEPSEEK_THINKING_EFFORTS = ["high", "xhigh", "max"];It maps low to high, while both xhigh and max map to max.
Source:
opencodex/src/providers/registry.ts
Lines 349 to 360 in 68d3aa0
| const DEEPSEEK_THINKING_MODELS = ["deepseek-v4-pro", "deepseek-v4-flash"]; | |
| const OPENCODE_FREE_DEEPSEEK_MODELS = ["deepseek-v4-flash-free"]; | |
| // "max" is advertised too: the wire map routes xhigh->max and max->max, so the picker | |
| // should surface the max tier instead of hiding it behind xhigh. | |
| const DEEPSEEK_THINKING_EFFORTS = ["high", "xhigh", "max"]; | |
| const DEEPSEEK_THINKING_REASONING_MAP: Record<string, string> = { | |
| low: "high", | |
| medium: "high", | |
| high: "high", | |
| xhigh: "max", | |
| max: "max", | |
| }; |
Consequently, users cannot select DeepSeek's native low effort, and the picker presents xhigh as a native level even though it is an alias for max.
Expected behaviour
Match DeepSeek's official Codex reasoning ladder:
low / high / max
Native values should remain unchanged:
low -> low
high -> high
max -> max
Compatibility normalization for other Codex values may remain internal, but those aliases should not be advertised as native DeepSeek levels.
Minimal redacted request or reproduction
# Inspect the current DeepSeek reasoning ladder and mapping.
curl -fsSL https://raw.githubusercontent.com/lidge-jun/opencodex/68d3aa0836648ae1d7b592fc5aa3b30146c0886d/src/providers/registry.ts \
| sed -n '349,360p'
# Compare the result with DeepSeek's official Codex models.json in the documentation below.Actual response or error
Advertised levels: high / xhigh / max
low -> high
medium -> high
high -> high
xhigh -> max
max -> maxUpstream documentation
The official Codex model catalog declares low / high / max for deepseek-v4-flash.
Suggested mapping or implementation notes
Advertise the provider-native ladder:
const DEEPSEEK_THINKING_EFFORTS = ["low", "high", "max"];If compatibility is needed for values from older clients, global configuration, or existing sessions, keep it as a non-advertised fallback, for example:
medium -> high
xhigh -> max
ultra -> max
Additional context and attachments
This is separate from the Responses turn-stall problem in #938 and the Claude Code subagent effort propagation issue in #704.
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.
Activity
github-actions commentedon Aug 5, 2026
Automated translation bookkeeping — detected language: unknown.
github-actions commentedon Aug 5, 2026
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
agentHits commentedon Aug 5, 2026
good idea @bluesmilery
Merge pull request #1069 from lidge-jun/codex/1057-deepseek-effort-la…
lidge-jun commentedon Aug 6, 2026
Fixed on dev by PR #1069, merge commit cdb963e. The registry now advertises the effort ladder each DeepSeek V4 model actually honors (with regression tests). Note: dev is ahead of the current npm release — the fix ships with the next release train.
fix(deepseek): advertise the ladder each V4 model actually honors (li…
fix(deepseek): advertise the ladder each V4 model actually honors (li…
Merge pull request lidge-jun#1069 from lidge-jun/codex/1057-deepseek-…