Align DeepSeek reasoning levels with official low/high/max ladder #1057

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:

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    -> max

Upstream documentation

https://api-docs.deepseek.com/zh-cn/quick_start/agent_integrations/codex

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.