Diagnostica GPT-5.6 en Codex

Codex falla al ejecutar GPT-5.6, pero ese error no te dice qué debes corregir. Puede que la clave no tenga acceso al modelo, que la ruta base /v1 sea incorrecta o que una llamada directa a Responses funcione mientras el proveedor rechaza los metadatos que añade Codex. Repetir el mismo comando suele limitarse a reproducir el síntoma; por sí solo no identifica la capa que falla.

Este kit gratuito comprueba esas capas en orden. Verifica los ID exactos de los modelos y la salida básica de Responses; en SSE exige un marcador de texto exacto y el evento final response.completed; en la prueba de función, exige la función indicada y argumentos JSON exactos. Después ejecuta Codex con una configuración temporal desde un directorio de trabajo vacío y genera un único informe JSON saneado. Las pruebas directas solo envían marcadores fijos y la prueba de Codex no modifica tu configuración existente. El kit comprueba compatibilidad; no mide la calidad de los modelos.

Qué demuestra el kit

Las comprobaciones están separadas por capas de forma deliberada:

1. GET /v1/models confirma que la clave puede ver cada ID de modelo exacto.
2. Una petición mínima a Responses, sin streaming, confirma la generación básica y comprueba el ID de modelo devuelto.
3. La prueba SSE exige un marcador de texto exacto y un evento final response.completed.
4. La prueba estricta de función exige la función indicada y los argumentos JSON exactos.
5. Una ejecución aislada de codex exec prueba la CLI de Codex instalada a través del mismo proveedor.

Que una capa pase no implica que la siguiente también lo haga. Esa separación es la parte útil: si las comprobaciones directas de la API pasan y solo falla codex_cli_smoke, cambiar la clave de API o el ID del modelo difícilmente resolverá el problema real.

Ejecútalo sin tocar tu configuración actual

Coloca check.mjs y el lanzador correspondiente a tu shell en el mismo directorio. En Bash o Zsh, lee la clave sin escribir su valor literal en el historial de la shell:

chmod +x run.sh
printf 'OmniaKey API key: ' >&2
IFS= read -r -s OMNIAKEY_API_KEY
printf '\n' >&2
export OMNIAKEY_API_KEY
./run.sh
unset OMNIAKEY_API_KEY

En Windows PowerShell:

$secureKey = Read-Host 'OmniaKey API key' -AsSecureString
$env:OMNIAKEY_API_KEY = [System.Net.NetworkCredential]::new('', $secureKey).Password
.\run.ps1
Remove-Item Env:OMNIAKEY_API_KEY
$secureKey = $null

La ejecución predeterminada prueba la salida básica de Responses en Sol, Terra y Luna; después comprueba el streaming, la emisión de llamadas a funciones y el recorrido completo de Codex en Sol. Son cinco generaciones directas fijas más un turno aislado de Codex cuando Codex está instalado. El uso de la API puede facturarse aunque el kit sea gratuito.

Usa --full para repetir las comprobaciones más profundas en los tres modelos. Esto produce nueve generaciones directas y tres turnos de Codex. Los reintentos de la API directa y los dos límites de reintento del proveedor en Codex están fijados en cero; el kit no intenta provocar artificialmente un 429. Si un modelo ignora la instrucción fija de no usar herramientas e inicia un bucle de herramientas, un turno de Codex puede generar otra petición al modelo, y el informe marca la comprobación como fallida:

./run.sh --full

Para probar un solo modelo sin invocar Codex:

./run.sh --model gpt-5.6-terra --skip-codex

La clave solo se acepta mediante una variable de entorno y nunca se pasa como argumento de línea de comandos. Los comandos de entrada silenciosa anteriores evitan que su valor literal quede en el historial de la shell; como cualquier variable del entorno de un proceso, mientras esté definida pueden inspeccionarla los procesos locales con permisos suficientes. Antes de escribir el informe, el script elimina la clave exacta, así como las formas habituales Bearer y sk-..., de todos los campos de texto controlados por el proveedor.

Qué contiene el informe

Cada informe incluye la versión del kit, la marca de tiempo UTC, el origen del endpoint y su ruta base, el sistema operativo, la arquitectura, las versiones de Node y Codex, los modelos seleccionados, los dos tiempos de espera y los límites explícitos de cero reintentos. Según la capa y el resultado, los campos aplicables pueden incluir:

• los ID de modelo solicitado y devuelto;
• el estado pass, fail o skip;
• el estado HTTP y las cabeceras de respuesta permitidas para los ID de petición y los límites de tasa;
• el ID de respuesta y el uso de tokens cuando el endpoint los devuelve;
• el tiempo transcurrido y, según corresponda, el contrato incumplido o el motivo de omisión;
• una categoría de error normalizada, sin la clave de API ni el cuerpo de respuesta sin filtrar.

En sistemas POSIX, el archivo de salida se crea con permisos exclusivos para su propietario. Los ID de petición no son credenciales, pero conviene revisar el informe antes de compartirlo porque pueden ayudar al proveedor a rastrear una petición.

El código de salida 0 significa que pasaron todas las comprobaciones ejecutadas. 1 indica que falló al menos una. 2 significa que los argumentos, la variable de entorno de la clave, la URL u otro requisito previo no eran válidos. Si Codex no está instalado, se registra como skip; no se disfraza como un fallo de la API.

Datos verificados de GPT-5.6

OpenAI documenta actualmente estos ID exactos y estos roles:

El alias gpt-5.6 dirige actualmente las peticiones a gpt-5.6-sol. Para diagnosticar, usa los ID explícitos: un alias introduce una duda de enrutamiento que la prueba de compatibilidad no necesita.

Las páginas actuales de los tres modelos indican una ventana de contexto de API de 1,050,000 tokens, un máximo de entrada de 922,000, un máximo de salida de 128,000 y una fecha de corte de conocimiento 2026-02-16. También indican compatibilidad con Responses, Chat Completions y Batch, además de streaming, salidas estructuradas y llamadas a funciones. Consulta las páginas principales de Sol, Terra y Luna.

Esos son límites de los modelos en la API, no una promesa de que todas las configuraciones del cliente Codex expongan la ventana completa. Codex tiene su propio catálogo de modelos, model_context_window y un mecanismo de compactación automática. Este kit no envía un prompt de un millón de tokens ni deduce la ventana efectiva de Codex a partir de la cifra anunciada para la API.

Configuración mínima de proveedor para Codex

La configuración actual de Codex utiliza ~/.codex/config.toml en el nivel de usuario para los proveedores personalizados. La referencia de configuración vigente enumera responses como el valor admitido para wire_api. Este es un ejemplo mínimo para OmniaKey:

model = "gpt-5.6-sol"
model_provider = "omniakey"

[model_providers.omniakey]
name = "OmniaKey"
base_url = "https://api.omniakey.com/v1"
env_key = "OMNIAKEY_API_KEY"
wire_api = "responses"

env_key y requires_openai_auth son modos de autenticación alternativos. La documentación actual de autenticación de Codex indica que requires_openai_auth = true hace que Codex ignore env_key; no lo añadas a este bloque de proveedor.

Haz una copia de seguridad de la configuración real antes de editarla:

cp ~/.codex/config.toml ~/.codex/config.toml.before-gpt56

El equivalente en PowerShell:

Copy-Item "$HOME\.codex\config.toml" "$HOME\.codex\config.toml.before-gpt56"

El comprobador de compatibilidad no exige editar ese archivo ni usar su configuración de proveedor. La prueba rápida de Codex ignora la configuración del usuario, crea un CODEX_HOME temporal, pasa la configuración del proveedor solo a ese proceso, usa un directorio de trabajo vacío y un sandbox de solo lectura, y después elimina el directorio. Solo transmite la clave y las variables de entorno de ejecución, configuración regional, directorio temporal, proxy y TLS incluidas en una lista cerrada; el informe registra sus nombres, nunca sus valores.

Un sandbox de solo lectura impide las escrituras, pero no todas las lecturas posibles. El prompt fijo que prohíbe usar herramientas se comprueba, pero no constituye una barrera de seguridad estricta. Usa --skip-codex o ejecuta el kit dentro de un contenedor o una máquina virtual aislados si el equipo contiene archivos que el proceso de Codex no deba poder leer.

Consulta la referencia de configuración de Codex y la guía de agentes de programación de OmniaKey antes de introducir cambios permanentes.

Interpreta los fallos por capas, no por intuición

No agrupes 401 y 403 bajo el mismo diagnóstico. Un 401 suele indicar un problema de autenticación; un 403 puede significar que una identidad válida carece de permiso. Del mismo modo, un 404 puede deberse a una ruta base /v1 incorrecta o a un modelo no disponible en una ruta válida.

La guía de errores de OpenAI recomienda revisar la forma de la petición ante solicitudes incorrectas, reducir el ritmo ante límites de tasa y reintentar la solicitud tras una breve espera cuando se produce un error del servidor. Este kit deja los reintentos en tus manos de forma intencionada para que el primer fallo siga siendo visible.

La trampa actual de los proveedores personalizados

Dos informes abiertos de Codex, #31870 y #31882, documentan fallos de GPT-5.6 a través de Azure y proveedores personalizados en Codex 0.144.x. En los casos descritos, las llamadas directas a Responses funcionaban, mientras que las peticiones de Codex fallaban con errores 400 que mencionaban X-OpenAI-Internal-Codex-Responses-Lite o el espacio de nombres reservado collaboration.

Estos issues son informes de campo, no una prueba de que fallen todos los proveedores personalizados. Esa es precisamente la razón por la que el kit comprueba por separado la capa directa y la de Codex.

Si el informe muestra esa división:

1. Registra codex_version, la categoría exacta del error y el ID de petición.
2. Actualiza a la última versión estable de Codex y vuelve a ejecutar la misma versión del kit.
3. Comprueba si los dos issues siguen abiertos y si algún mantenedor ha publicado una corrección.
4. Si el fallo persiste, envía el informe saneado a tu proveedor o al soporte de Codex.

El issue #31882 describe una sustitución completa del catálogo de modelos que desactiva Responses-Lite y los metadatos multiagente. Es una solución frágil: la sustitución reemplaza los metadatos del catálogo, puede quedar desfasada tras una actualización y puede desactivar funciones de las que dependes. La versión 1.0.0 de este kit detecta las firmas de fallo descritas en esos informes, pero deliberadamente no parchea Codex ni recomienda una vuelta silenciosa a una versión anterior.

Lo que este kit no mide

Esta es una sonda de compatibilidad, no un benchmark de calidad de modelos. No compara la precisión al programar, el comportamiento con contexto largo, la tasa de aciertos de caché, la latencia en producción, los tiempos de entrega progresiva de SSE, el precio facturado, las entradas de imagen, las herramientas alojadas, el trabajo multiagente ni un ciclo completo de continuación de llamada a función. Un informe verde significa que los contratos probados funcionaron una vez con las versiones y el endpoint registrados. No predice el comportamiento de todas las cargas de trabajo ni proporciona aislamiento del sistema de archivos a nivel de proceso.

Para poder reproducir el resultado, conserva el informe generado y los archivos exactos del kit. Verifica las descargas con SHA256SUMS, vuelve a ejecutarlo después de un cambio de Codex o de proveedor y compara las comprobaciones individuales, no solo el estado final.

Fuentes consultadas

• Uso de GPT-5.6
• Modelos GPT-5.6 en Codex
• Página del modelo GPT-5.6 Sol
• Página del modelo GPT-5.6 Terra
• Página del modelo GPT-5.6 Luna
• Referencia de configuración de Codex
• Autenticación de Codex con proveedores alternativos
• Guía de errores de la API de OpenAI
• Issue #31870 de Codex e #31882, ambos abiertos cuando se comprobaron