providers: route DeepSeek V4 Flash through native Responses API by default

[estelledc]

What are you trying to accomplish?

Make the official DeepSeek V4 Flash model use DeepSeek's native OpenAI Responses API route for every OpenCodex user, without requiring a hand-written provider override.

What prevents this today?

The deepseek registry preset is provider-wide openai-chat. OpenCodex 2.8.0 already supports a per-model modelAdapters override, so a user can opt in manually:

{
  "providers": {
    "deepseek": {
      "modelAdapters": {
        "deepseek-v4-flash": "openai-responses"
      }
    }
  }
}

Without that entry, deepseek-v4-flash follows the provider-wide Chat Completions adapter. This is functional for some requests, but it does not use the native Responses contract that DeepSeek documents for Codex.

What should OpenCodex do?

• Built-in routing maps the exact API model id deepseek-v4-flash to openai-responses.
• deepseek-v4-pro, legacy models, and other providers keep their current routes.
• An explicit modelAdapters entry remains an opt-out/override, so users can deliberately select openai-chat if needed.
• The version label DeepSeek-V4-Flash-0731 is not used as the API model id; requests should send deepseek-v4-flash.

Example usage or interface

After the change, this should use the native Responses route without extra configuration:

codex exec -m deepseek/deepseek-v4-flash

The equivalent explicit opt-in should remain supported for users who want to configure the route themselves:

"modelAdapters": { "deepseek-v4-flash": "openai-responses" }

Alternatives or workarounds

The current workaround is the explicit modelAdapters entry above. It works, but every user has to discover and maintain the same provider-specific setting.

Additional context

In an isolated OpenCodex 2.8.0 config with the override above, a real request through /v1/responses returned the native DeepSeek response shape and completed successfully. A real Codex CLI tool loop (pwd, then an exact final marker) also completed successfully through the same isolated proxy.

The upstream documentation states that V4-Flash natively supports the Responses API and is adapted for Codex:

• https://api-docs.deepseek.com/updates/
• https://api-docs.deepseek.com/quick_start/pricing/
• https://api-docs.deepseek.com/guides/responses_api/

The suggested implementation is a registry-only per-model wire default, using the existing modelAdapters resolution and preserving explicit override precedence. I searched existing issues and found the related mixed-wire override work in #404, but no DeepSeek native Responses default issue. The request and reproduction contain no credentials or personal data.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[ryanqeelee]

+1 from an actual user. I run Codex Desktop through the opencodex proxy with deepseek/deepseek-v4-flash (currently openai-chat adapter), and the native DeepSeek Responses route would remove the manual modelAdapters override for every user. Would love to see the registry default in 2.8.x; also following for when deepseek-v4-pro upstream Responses support lands (early Aug per DeepSeek docs).

[lidge-jun]

Fixed on dev by PR #808 (@estelledc), verified at 81f3f689a.

src/providers/registry.ts:825 now carries modelWireDefaults: { "deepseek-v4-flash": "openai-responses" } on the DeepSeek entry, and the resolver at :1262-1263 reads it — gated on providerMatchesRegistryTransport(), so a custom provider reusing the deepseek id but pointing elsewhere does not silently inherit the route.

Pro and the legacy models keep openai-chat, and explicit modelAdapters still take precedence, so anyone who wants Flash back on chat completions can set it.

Closing as implemented.