Usar DeepSeek con Codex: protocolo Responses, enrutamiento con CC Switch y verificación

Si desea que Codex utilice DeepSeek, la primera reacción suele ser cambiar ~/.codex/config.toml:

1
2


model = "deepseek-chat"
base_url = "https://api.deepseek.com"

Esta idea es válida en algunas versiones antiguas o escenarios comunes del SDK de OpenAI, pero cuando se aplica a la CLI del Codex actual, es fácil encontrarse con un problema subyacente: el proveedor del modelo personalizado del Codex utiliza el protocolo OpenAI Responses y la interfaz oficial de DeepSeek proporciona principalmente métodos de llamada de Chat Completions compatibles con OpenAI.

Mi máquina actual es codex-cli 0.111.0. Puede ver en codex --help que admite las entradas de configuración --config, --model y --profile; La referencia de configuración oficial del Codex de OpenAI también es muy clara: model_providers.<id>.wire_api actualmente solo admite responses, y el valor predeterminado es responses cuando se omite. .

La ruta de llamada proporcionada por la documentación oficial de DeepSeek es https://api.deepseek.com/chat/completions, y el ejemplo también es client.chat.completions.create(...). Entonces, el problema no es que el SDK de OpenAI no pueda llamar a DeepSeek, sino que la semántica de solicitud enviada por Codex y la semántica entendida por la interfaz nativa de DeepSeek no son exactamente la misma.

Es por esto que después de cambiar directamente base_url a https://api.deepseek.com, pueden ocurrir los siguientes fenómenos:

La ruta de la solicitud no coincide, directamente 404 o el formato de devolución es incorrecto.
El análisis falló durante múltiples rondas de diálogo, invocación de herramientas y generación de parches.
tool_calls La secuencia, la estructura del mensaje y el formato del evento de transmisión no coinciden.
Parece que el modelo puede responder una frase, pero cuando el Codex llega a funcionar, empieza a informar errores.

Un enfoque más estable es poner una “capa de traducción” entre Codex y DeepSeek. Hay dos rutas comunes. Método 1: enrutamiento local de DeepSeek usando CC Switch

La función de la puerta de enlace local no es simplemente reenviar, sino convertir solicitudes de Respuestas del Codex en Finalizaciones de Chat que DeepSeek pueda manejar, y luego convertir secuencias JSON, SSE, contenido de inferencia y llamadas de herramientas ordinarias a eventos de Respuestas que el Codex pueda analizar.

CC Switch ofrece esta clara ruta oficial del proyecto a partir de la versión 3.16. El orden de las operaciones es:

Instale la versión actual de CC Switch desde las versiones oficiales.
Cambie a la página del Codex en la parte superior y agregue un nuevo proveedor.
Seleccione el ajuste preestablecido de DeepSeek integrado y complete la clave API de DeepSeek.
Mantenga el valor predeterminado Needs Local Routing habilitado automáticamente.
Habilite el enrutamiento local en la página Enrutamiento de configuración y habilite la toma de control para Codex.
Salga por completo y reinicie Codex para que se vuelva a cargar el directorio del modelo.

Cuando el enrutamiento está habilitado, la dirección local del Codex proporcionada por la guía oficial suele ser:

1

http://127.0.0.1:15721/v1

No escriba este puerto como una verdad fija; Consulte la interfaz actual de CC Switch y el nivel de usuario generado ~/.codex/config.toml. CC Switch administrará el directorio de modelos y los campos de autenticación. Copiar manualmente el TOML en el tutorial anterior fácilmente entrará en conflicto con la versión actual.

Después de ingresar al Codex, primero use `/model` para verificar si se muestra el ajuste preestablecido de DeepSeek y luego envíe una solicitud mínima. Luego verifique la cantidad de solicitudes o registros en la página CC Switch Routing; Sólo si las solicitudes se enrutan localmente se puede demostrar que no se hace un mal uso de otros proveedores. Registro del entorno real

Cuando se revisó este artículo, los resultados de la ejecución local fueron:

1

codex-cli 0.111.0

`codex --help` También se muestran `--config`, `--model` y `--profile` disponibles. La máquina actual no tiene CC Switch instalado y DeepSeek Key no está configurado, por lo que este artículo no pretende haber completado la prueba de generación de DeepSeek de un extremo a otro; Los pasos de la interfaz anteriores provienen de la documentación del proyecto CC Switch. La propia aceptación del lector debe guardar la versión del Codex, la versión CC Switch, los registros de solicitudes y los resultados de la invocación de la herramienta. Método 2: utilice OpenRouter BYOK para realizar puentes en línea

Si no desea ejecutar una capa de traducción local, puede evaluar la API Beta de Respuestas de OpenRouter con BYOK. BYOK vincula su proveedor ascendente Key a OpenRouter, y OpenRouter es responsable del enrutamiento; la clave API de OpenRouter todavía se utiliza para acceder al Codex.

OpenRouter actualmente marca la API de Responses como Beta y señala que es una implementación sin estado. Las capacidades de la interfaz y los eventos requeridos por el Codex aún pueden cambiar, por lo que esta ruta debe verificarse antes de decidir si se utilizará para trabajos a largo plazo.

Lo más común que se escribe mal aquí es la variable de entorno. Codex accede a OpenRouter, por lo que env_key normalmente debería ser OPENROUTER_API_KEY, no DEEPSEEK_API_KEY. La clave DeepSeek debe agregarse en BYOK o en la configuración de la clave del proveedor de OpenRouter.

Ejemplo de configuración:

Método de inicio

1
2
3
4
5
6
7
8
9


[profiles.deepseek-openrouter]
model = "deepseek/deepseek-chat"
model_provider = "openrouter"

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"
wire_api = "responses"

1
2


export OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

PowerShell:

1
2


$env:OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

Luego agregue la clave del proveedor de DeepSeek en el backend de OpenRouter y restrinja la clave API de OpenRouter que permite el uso de esta clave BYOK. La ID del modelo debe basarse en el directorio del modelo actual de OpenRouter. No puede copiar directamente el nombre del modelo oficial de DeepSeek y asumir que está disponible.

Antes de iniciar el Codex, verifique el punto final de Respuestas:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


$headers = @{
  Authorization = "Bearer $env:OPENROUTER_API_KEY"
  "Content-Type" = "application/json"
}

$body = @{
  model = "从 OpenRouter 模型目录复制的 DeepSeek ID"
  input = "只回复 READY"
  max_output_tokens = 16
} | ConvertTo-Json -Depth 6

Invoke-RestMethod `
  -Uri https://openrouter.ai/api/v1/responses `
  -Method Post `
  -Headers $headers `
  -Body $body

Esta solicitud se realizó correctamente, lo que solo prueba que la llamada de Respuestas básica está disponible. Las lecturas de archivos, los parches, las respuestas de transmisión y las llamadas a herramientas también deben verificarse en el repositorio provisional para determinar si cumple con el flujo de trabajo del Codex.

Esta ruta elimina la necesidad de mantenimiento de la puerta de enlace local, pero agrega una capa intermedia en línea y Responses aún está en versión Beta. Al solucionar problemas, guarde la información de error de Codex, OpenRouter y DeepSeek ascendente por separado. ¿Quieres seguir usando el nombre del modelo deepseek-chat?

En la descripción de la documentación oficial de DeepSeek de mayo de 2026, aparecieron los nombres de modelo recomendados deepseek-v4-flash y deepseek-v4-pro, y se sugiere que los alias compatibles deepseek-chat y deepseek-reasoner se abandonarán después del 24 de julio de 2026.

Por tanto, se recomienda dar prioridad a las pruebas en la nueva configuración:

1

model = "deepseek-v4-flash"

Si usa OpenRouter, debe escribirlo de acuerdo con el nombre del modelo de OpenRouter, por ejemplo:

1

model = "deepseek/deepseek-chat"

El nombre real disponible depende de la puerta de enlace o de la página del modelo OpenRouter que esté utilizando. Cuando el nombre del modelo es incorrecto, los errores suelen aparecer como `model not found`, 404 o el proveedor no puede encontrar el punto final correspondiente. ¿Por qué no se recomienda cambiar directamente la base_url oficial de DeepSeek?

Por supuesto, puedes intentar escribir:

1
2
3
4
5
6
7
8


[profiles.deepseek-direct]
model = "deepseek-v4-flash"
model_provider = "deepseek"

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com"
env_key = "DEEPSEEK_API_KEY"

Pero esto se parece más a un experimento de depuración y no es adecuado como solución estable. Porque Codex hablará con el proveedor personalizado de acuerdo con el protocolo de Respuestas y el ejemplo oficial de DeepSeek usa `/chat/completions`. Si DeepSeek o Codex completan la capa de compatibilidad en el futuro, esta conexión directa puede resultar sencilla; Hasta entonces, la capa puente es más fiable. ¿Qué debo hacer si sigo usando OpenAI después de cambiar la configuración?

Primero confirme la ubicación del archivo de configuración. La configuración global debe estar en:

.codex/config.toml en el proyecto

1

~/.codex/config.toml

no es adecuado para configuraciones de proveedor a nivel de máquina como model_provider y model_providers. La documentación oficial de OpenAI también recuerda que la configuración a nivel de proyecto no cubrirá estos campos relacionados con proveedores locales y certificaciones.

No trate codex logout como el primer paso en la solución de problemas generales. El estado de inicio de sesión oficial y la configuración del proveedor externo son cuestiones diferentes; salir apresuradamente sólo aumentará los costos de recuperación. Primero verifique el perfil, model_provider, el directorio del modelo y el registro de enrutamiento local en uso.

También puedes utilizar parámetros temporales para realizar una verificación rápida:

1

codex --profile deepseek-openrouter

1

codex -c model_provider=openrouter -c model="实际模型 ID"

Si esto tiene efecto, significa que la configuración en sí es legible; si no tiene efecto, primero verifique si el nombre del perfil, la sintaxis TOML y las variables de entorno solo son válidas en el shell actual. Lista de verificación para solucionar problemas

401: la clave es incorrecta o env_key apunta a la variable de entorno incorrecta.
404: base_url o el nombre del modelo es incorrecto, o la solicitud de Respuestas puede enviarse a una dirección que solo admite Finalizaciones de Chat.
tool_calls, parche, error de análisis de transmisión: lo más probable es que el puente del protocolo esté incompleto.
Aún se muestra el modelo OpenAI predeterminado: confirme la configuración a nivel de usuario, el perfil y los resultados de /model, no elimine primero el estado de inicio de sesión.
Las nuevas ventanas que se abren después de configurar las variables de entorno en PowerShell fallan: $env:... Solo tiene efecto para la sesión actual. Si necesita guardarlo durante mucho tiempo, cambie las variables de entorno del usuario.

- OpenRouter BYOK no elimina su propia clave DeepSeek: verifique si la clave del proveedor en segundo plano de OpenRouter está vinculada, si se permite el uso de la clave API de OpenRouter actual y si el respaldo está habilitado. Conclusión

Deje que Codex use DeepSeek. No es que no puedas cambiar config.toml, pero no puedes simplemente cambiar base_url y esperar que todo sea automáticamente compatible.

Las dos formas que se pueden verificar actualmente son:

Utilice el enrutamiento local de CC Switch para convertir respuestas y finalizaciones de chat.
Utilice OpenRouter Responses API Beta y combínelo con el enrutamiento BYOK a su propia clave DeepSeek.

Ninguno de los métodos puede basarse únicamente en “devolver una frase” como criterio de éxito. Como mínimo, verifique que la selección del modelo, la salida de streaming, las modificaciones de archivos, las llamadas a herramientas, la recuperación de errores y las claves realmente vayan al proveedor esperado.

Referencias: