How to Connect Codex to DeepSeek via CC Switch Local Routing

Many users first get stuck when trying to integrate DeepSeek with Codex, not because of API keys or model names, but because Codex and DeepSeek speak different API dialects: Codex’s CLI/App expects the OpenAI Responses API, while DeepSeek exposes a POST /chat/completions endpoint that follows the OpenAI Chat Completions format.

The correct request flow is Codex → CC Switch local router → DeepSeek Chat API. In this chain Codex still thinks it is calling a Responses API; the local router rewrites the request to /chat/completions, forwards it to DeepSeek, then converts DeepSeek’s JSON or SSE response back to the Responses shape that Codex understands.

Preparation

Install CC Switch (version 3.16.0 or newer).

Install Codex CLI/App and run it once so that ~/.codex/ exists.

Obtain a valid DeepSeek API Key.

Step 1 – Add DeepSeek as a provider under the Codex tag

Open CC Switch, switch to the Codex tab, and click the plus button to add a provider.

Select the built‑in DeepSeek preset, then fill in the DeepSeek API Key and save.

Do not write the full endpoint URL (e.g., https://api.deepseek.com/chat/completions) in the preset; the base URL should be the service root, and the router will append the path.

Step 2 – Start the local router and enable the Codex route

In CC Switch’s routing/proxy page, turn on the global router switch.

Enable the Codex switch under Application Routes.

The default listening address is http://127.0.0.1:15721. After enabling the Codex route, Codex’s base URL becomes http://127.0.0.1:15721/v1. Verify the port is listening with nc -vz 127.0.0.1 15721.

Step 3 – Activate the DeepSeek provider and restart Codex

In Codex’s provider list, enable the DeepSeek entry.

Ensure three conditions are consistent: the enabled provider is DeepSeek, the local router service is running, and the Codex switch in Application Routes is on.

Restart the Codex process so it reloads ~/.codex/config.toml and picks up the new model mapping.

After restart, run /model in Codex to confirm that a DeepSeek model appears.

Checking the configuration

The relevant parts of ~/.codex/config.toml should be:

base_url = "http://127.0.0.1:15721/v1"
wire_api = "responses"

Although the upstream is a Chat Completions API, wire_api stays set to responses because the conversion happens inside CC Switch, not in Codex.

Other Chat‑only providers

The same approach works for any vendor that only offers a Chat Completions endpoint (e.g., Kimi, MiniMax, SiliconFlow). Choose the appropriate handling based on the upstream documentation:

If the vendor has a preset in CC Switch, enable it and turn on “requires local routing mapping”.

If the vendor is an OpenAI‑compatible Chat service, create a custom provider and select “OpenAI Chat Completions”.

If the vendor already supports the Responses API, configure it directly without routing.

For gateways with special paths, only use the full URL mode when absolutely necessary.

Common troubleshooting

404 or missing /responses : You likely wrote the DeepSeek Chat base URL directly into Codex or forgot to enable the Codex route. Check that base_url is http://127.0.0.1:15721/v1 and that the Codex route is on.

DeepSeek returns 404 : A custom provider may have included the /chat/completions path in the base URL or the wrong preset was selected. Use the DeepSeek preset or set the base URL to the service root.

/model shows no DeepSeek models : The old Codex process didn’t load the new model directory. Save the provider and restart Codex.

Router running but wrong provider is used : The enabled provider, router service, and Codex switch are not all aligned. Re‑check each component.

Streaming output broken or malformed : The upstream Chat SSE was not converted, or the request bypassed the router. Ensure the provider’s API format is “OpenAI Chat Completions” and that “requires local routing mapping” is enabled.

Port connection failure : The router didn’t start or the port is occupied. Verify with nc -vz 127.0.0.1 15721 and change the listening port in CC Switch if needed.

When troubleshooting, follow this order: 1) confirm the local router is up; 2) verify Codex is being routed; 3) check that DeepSeek is the active provider; 4) finally inspect model names, API keys, and balance.

Safety boundaries

Keep the listening address at 127.0.0.1 unless you deliberately need LAN access.

Never copy the real API Key into Codex’s config; store it only in the CC Switch provider configuration.

Do not treat the official OpenAI Codex account as a generic third‑party proxy; using third‑party routing with official accounts carries account‑risk.

Sanitize screenshots: remove API keys, balances, emails, and organization IDs.

In production, retain a fallback (e.g., official OpenAI or another Responses‑compatible service) and be ready to disable the local router.

Minimal viable configuration checklist

CC Switch upgraded to a version that supports Codex local routing.

DeepSeek provider added under the Codex tag (preset or custom with OpenAI Chat Completions).

“Requires local routing mapping” enabled.

Local router service running, default address 127.0.0.1:15721.

Codex switch in Application Routes turned on. ~/.codex/config.toml points to http://127.0.0.1:15721/v1 and keeps wire_api = "responses".

DeepSeek provider enabled and Codex restarted. /model shows or defaults to a DeepSeek model.

When this checklist is satisfied, the key principle is that Codex stays on the Responses side while the provider stays on the Chat side, with CC Switch handling the conversion. Understanding this lets you swap in Kimi, MiniMax, SiliconFlow, or any other Chat‑only vendor by checking the upstream endpoint ( /chat/completions vs. /responses).