Implementar una puerta de enlace

Como administrador de la puerta de enlace, configura las rutas de los modelos y autoriza a un usuario para la prueba piloto. Prueba la conexión en cada cliente que admitas antes de distribuir la configuración a los desarrolladores. Para la autenticación en la puerta de enlace, usa OAuth nativo de la puerta de enlace, claves de API o asistentes de credenciales. Para combinar esa autenticación con el inicio de sesión en un Espacio de trabajo de ChatGPT, consulta Iniciar sesión con ChatGPT a través de una puerta de enlace.

Requisitos previos

Antes de implementar Codex para los desarrolladores, confirma que cuentas con lo siguiente:

• Una puerta de enlace que acepte conexiones HTTPS en la URL base exacta que vas a distribuir.
• Una credencial del proveedor de origen almacenada en la puerta de enlace.
• Alias de modelos aprobados para Codex, asignados a los modelos de origen previstos.
• Un método de autenticación probado: OAuth nativo de la puerta de enlace, claves de API de la puerta de enlace con alcance limitado o un asistente de credenciales.
• Para OAuth, un cliente público registrado, usuarios de prueba aprobados y una puerta de enlace que pueda validar tokens de acceso de OAuth.
• Para las claves de API o los asistentes, un mecanismo de entrega de secretos o un asistente probado.
• Un medio para distribuir la configuración, los asistentes necesarios y los archivos de catálogo.

Requisitos de la puerta de enlace

Antes de conectar Codex, verifica que la puerta de enlace cumpla los siguientes requisitos:

• Aceptar solicitudes de Codex a la API Responses en POST /v1/responses.
• Transmitir eventos SSE sin almacenarlos en un búfer y finalizar la transmisión con response.completed.
• Permitir que la conversación continúe en los turnos siguientes cuando se reenvíe la entrada.
• Conservar previous_response_id solo cuando se habilite WebSocket o el transporte incremental.
• Conservar las llamadas a funciones y los elementos function_call_output correspondientes.
• Dirigir cada alias de modelo que usa Codex al modelo de origen previsto.
• Autenticar a cada usuario por separado y devolver errores que ayuden a identificar la causa.

Un punto de acceso para comprobar el estado, /v1/models, una respuesta de Chat Completions o una sola respuesta de texto sin formato no bastan para verificar la compatibilidad de la puerta de enlace. Consulta los requisitos de compatibilidad de la puerta de enlace para conocer el contrato en detalle.

Implementar la puerta de enlace

Una vez desplegada la puerta de enlace, completa estos cinco pasos en orden para verificar que los desarrolladores puedan usar Codex:

1. Elegir los nombres de los modelos y verificar las rutas.
2. Elegir el método de autenticación.
3. Probar Codex a través de la puerta de enlace.
4. Distribuir la configuración.
5. Verificar la configuración desde el equipo de un desarrollador.

Elegir los nombres y las rutas de los modelos

Asigna a model en Codex el nombre que usa la puerta de enlace para el modelo. Configura la puerta de enlace para que dirija las solicitudes con ese nombre al modelo de origen aprobado.

Usar un catálogo de modelos para nombres personalizados

Para crear un catálogo local, empieza con el ejemplo de models.json.

Proporciona un catálogo de modelos cuando tu puerta de enlace use un nombre de modelo que Codex no reconozca. El catálogo especifica las instrucciones, las opciones de razonamiento, los límites de contexto y las capacidades de uso de herramientas que Codex aplica a ese nombre. Si no hay una entrada que coincida, la solicitud puede llegar al modelo de origen previsto aunque Codex use una configuración genérica.

Aloja un catálogo remoto y configura model_providers.<id>.model_catalog_url para actualizar los metadatos de los modelos de forma centralizada, o distribuye un archivo local con model_catalog_json. Usa un catálogo local cuando OAuth nativo sea la única credencial de la puerta de enlace. OAuth por sí solo no habilita la detección de catálogos remotos. Consulta la referencia de configuración para conocer ambas opciones.

Solicita a tu proveedor de nube o de puerta de enlace un punto de acceso al catálogo o un archivo de catálogo compatible con tu versión de Codex. Asegúrate de que incluya cada alias aprobado y los metadatos de su modelo. Para implementar el catálogo, consulta Implementar catálogos de modelos para puertas de enlace y servicios en la nube.

Publicar un catálogo remoto

Usa el punto de acceso HTTPS al catálogo que te proporcione el proveedor. Distribuye la URL completa del punto de acceso en la tabla del proveedor seleccionado en config.toml:

model = "company-coding-model"
model_provider = "enterprise-gateway"
web_search = "disabled"

[model_providers.enterprise-gateway]
name = "Organization Gateway"
base_url = "https://gateway.example.com/v1"
model_catalog_url = "https://gateway.example.com/codex/models"
wire_api = "responses"
env_key = "CODEX_GATEWAY_API_KEY"

Asegúrate de que CODEX_GATEWAY_API_KEY esté disponible para el proceso de Codex. Configura base_url por separado para dirigir las solicitudes de inferencia a través de la puerta de enlace. Si omites este valor, Codex usa el punto de acceso predeterminado de OpenAI para el modo de autenticación actual.

La detección del catálogo requiere autenticación mediante una clave de API, un comando o el backend de Codex. Ni OAuth nativo de la puerta de enlace ni los encabezados personalizados activan la detección por sí solos.

Cuando cambien tus modelos aprobados, coordina las actualizaciones del catálogo con tu proveedor. Reinicia el cliente después de cambiar su configuración.

Elimina cualquier valor vigente de model_catalog_json, incluso si se exige mediante requirements.toml. Ese valor tiene prioridad sobre la URL remota e impide que se descargue el catálogo.

Distribuir un catálogo local

Usa model_catalog_json para cargar el archivo del proveedor al iniciar Codex. Un catálogo local personalizado reemplaza el catálogo incluido con Codex.

Asigna el mismo valor al alias de la puerta de enlace, al campo slug del catálogo y al campo model de Codex: company-coding-model. Agrega los siguientes ajustes antes de la primera tabla TOML en la configuración de Codex que distribuyas. Usa la ruta absoluta real del archivo:

model = "company-coding-model"
model_catalog_json = "/absolute/path/to/gateway-models.json"

Reinicia la CLI o la aplicación de escritorio después de cambiar el catálogo, ya que Codex lo carga al iniciarse.

Verificar las rutas de los modelos

Verifica la ruta de cada modelo con una solicitud real a la API Responses y los registros de la puerta de enlace. Una respuesta de /v1/models puede ayudarte a encontrar nombres de modelos, pero no demuestra que un modelo admita las solicitudes y el uso de herramientas requeridos.

El enrutamiento de modelos y la autorización de herramientas son partes independientes de la implementación. Configura por separado las conexiones MCP, la distribución de complementos y sus respectivas políticas.

Elegir el método de autenticación

OAuth nativo de la puerta de enlace

1. Registra un cliente OAuth público que admita el flujo de código de autorización con PKCE y aprueba a los usuarios o grupos que podrán iniciar sesión.
2. Configura la puerta de enlace para que valide el token de acceso emitido que recibe en la cookie o el encabezado personalizado que hayas seleccionado. Aplica los modelos aprobados, los límites de solicitudes y los presupuestos según la identidad de cada usuario.
3. Sigue las instrucciones de OAuth nativo de la puerta de enlace para recopilar las URL de autorización y de token, el ID del cliente público, los alcances, el recurso opcional, los ajustes de entrega de tokens y el puerto de redirección fijo, si lo hay. Registra en tu proveedor de identidad la URI de redirección de loopback correspondiente.
4. Usa una cuenta de prueba para verificar el inicio de sesión en el navegador, la renovación del token y la revocación del acceso en la CLI o la aplicación de escritorio que planeas implementar. Confirma que el navegador pueda acceder a la dirección de retorno, también en el caso de los usuarios remotos de la CLI.

Cada usuario inicia sesión por separado. Distribuye únicamente la configuración de OAuth. No distribuyas un secreto de cliente, una clave de API de la puerta de enlace ni el ejecutable de un asistente. Conserva las credenciales del proveedor de origen en la puerta de enlace.

Claves de API o asistentes de credenciales

1. Emite una credencial de la puerta de enlace con alcance limitado para cada desarrollador. Así podrás atribuir el uso y revocar el acceso de forma individual.
2. Define los modelos aprobados, los límites de solicitudes, el presupuesto, la fecha de vencimiento y el período de renovación de cada credencial.
3. Entrega las credenciales mediante tu gestor de secretos o un asistente de credenciales instalado. Mantén las credenciales del proveedor de origen y las del administrador de la puerta de enlace fuera de los equipos de los desarrolladores.
4. Si usas un asistente, sigue el contrato de autenticación mediante comandos y prueba la obtención y la renovación de tokens antes de distribuirlo.
5. Indica a los desarrolladores cómo renovar sus credenciales y a quién acudir si necesitan ayuda.

Probar Codex a través de la puerta de enlace

Antes de distribuir la configuración, sigue los pasos de Configurar el proveedor para configurar una cuenta de prueba aislada con el bloque del proveedor y el método de autenticación que planeas distribuir.

Si la puerta de enlace proporciona el catálogo de modelos, confirma que devuelva un arreglo models compatible con Codex. Si usas la credencial del usuario para la inferencia con OpenAI, confirma que la puerta de enlace reenvíe los encabezados de ChatGPT requeridos al backend de Codex.

Registra la versión del cliente, el sistema operativo, el ID del proveedor, el alias del modelo y el método de autenticación que uses en la prueba piloto. Ejecuta las siguientes pruebas en cada cliente que planees admitir, ya sea la CLI o la aplicación de escritorio. Si ofreces tanto la autenticación exclusiva en la puerta de enlace como la opción de combinarla con el inicio de sesión en ChatGPT, prueba cada combinación por separado.

Si la aprobación automática está habilitada, usa una carpeta de prueba desechable para activar una acción de herramienta que requiera revisión según la política que planeas aplicar. Confirma que la puerta de enlace procese la solicitud de revisión y que el cliente aplique la decisión de aprobación. Una llamada de solo lectura que no requiera aprobación no sirve para probar este proceso. Documenta los flujos de trabajo que no se admitan antes de ampliar la prueba piloto.

Si la implementación cambia el proveedor de los usuarios actuales, prueba en cada cliente admitido tanto una conversación nueva como una creada antes del cambio. Registra si los usuarios pueden ver la conversación existente, continuarla o crear una rama a partir de ella. Si algún flujo de trabajo queda bloqueado, indícales cómo recuperarlo. No des por hecho que cambiar el proveedor predeterminado migra el historial de conversaciones.

Una vez superadas las pruebas, prepara la información que entregarás a los desarrolladores.

Distribuir la configuración

Para que todos los equipos se conecten por la misma ruta, distribuye la URL base de la puerta de enlace, el ID del proveedor, el alias de modelo aprobado y los ajustes de autenticación.

Qué distribuir

Para OAuth nativo de la puerta de enlace, distribuye la tabla del proveedor y la tabla [model_providers.<id>.gateway_oauth] de la guía de conexión con los valores de registro que recopilaste antes. Mantén requires_openai_auth = false y omite env_key, experimental_bearer_token y la tabla auth de autenticación mediante comandos cuando OAuth sea la única credencial de la puerta de enlace.

Si usas un asistente de credenciales, distribuye el siguiente bloque de config.toml mediante la capa de configuración que elegiste. Usa un modelo que tu versión de Codex reconozca o proporciona el catálogo correspondiente como se indicó antes. Instala el programa que obtiene el token en la ruta configurada para el comando:

model = "gpt-6-sol"
model_provider = "enterprise-gateway"
web_search = "disabled"

[model_providers.enterprise-gateway]
name = "Organization Gateway"
base_url = "https://gateway.example.com/v1"
wire_api = "responses"

[model_providers.enterprise-gateway.auth]
command = "/usr/local/bin/fetch-codex-gateway-token"
args = ["print-token"]
timeout_ms = 30000
refresh_interval_ms = 300000

Para usar una clave de prueba estática de corta duración, elimina el bloque de autenticación, coloca env_key = "CODEX_GATEWAY_API_KEY" dentro de [model_providers.enterprise-gateway] y define la variable fuera de TOML. No combines env_key con la autenticación mediante comandos.

Distribuir valores predeterminados y requisitos

Si tus usuarios no inician sesión en Codex con ChatGPT, puedes distribuir la configuración del equipo desde tu propio servidor. Codex obtiene esa configuración independientemente de cómo se enruten las solicitudes a los modelos.

Consulta el orden de prioridad de la configuración para elegir dónde distribuir los valores predeterminados. Para conocer los ajustes obligatorios y las cargas útiles de MDM para macOS, consulta Configuración administrada.

Para definir valores predeterminados en todo el equipo en macOS o Linux, usa /etc/codex/config.toml. En Windows, coloca config.toml en %ProgramData%\OpenAI\Codex\. La configuración de usuario o de perfil puede reemplazar estos valores. Las referencias enlazadas describen los requisitos admitidos y la ubicación de sus archivos.

Distribuye por separado los ejecutables de los asistentes y los archivos de catálogo locales a los que haga referencia la configuración.

Para exigir el uso de una URL de catálogo remoto, coloca la definición completa del proveedor en requirements.toml, en la tabla [model_providers.<id>]. Una definición obligatoria reemplaza la tabla del mismo proveedor en la configuración habitual. Incluye base_url, los ajustes de autenticación y los demás campos necesarios. Usa el requisito model_provider cuando también necesites exigir la selección del proveedor.

model_catalog_json apunta a un archivo JSON local. Si exiges este ajuste mediante requirements.toml, el requisito fija la ruta, pero no distribuye el archivo. Coloca el catálogo en esa ruta absoluta antes de iniciar Codex.

Escribe las rutas absolutas de Windows ya resueltas en TOML. Codex no expande %ProgramData% dentro de model_catalog_json ni en los valores de command de la configuración de autenticación del proveedor. Por ejemplo, usa las siguientes rutas solo si tu implementación colocó los archivos ahí:

model_catalog_json = 'C:\ProgramData\OpenAI\Codex\models.json'

[model_providers.enterprise-gateway.auth]
command = 'C:\ProgramData\OpenAI\Codex\fetch-gateway-token.cmd'
args = ["print-token"]

Una CLI que se ejecuta en WSL lee las rutas de Linux y el valor de CODEX_HOME de Linux. No hereda automáticamente la configuración nativa de Windows.

Distribuir los encabezados de enrutamiento

Si la puerta de enlace dirige las solicitudes según la configuración o la herramienta, agrega los encabezados que espera a la definición del proveedor en el archivo requirements.toml administrado. El siguiente ejemplo proporciona el ID de una configuración de enrutamiento e identifica a Codex como cliente:

[model_providers.enterprise-gateway.http_headers]
x-portkey-config = "<gateway-routing-config-id>"
x-portkey-metadata = '{"tool_id":"codex"}'

Usa env_http_headers para los valores de encabezado que proporciona el entorno del cliente. Envía una solicitud de prueba y confirma la ruta seleccionada en los registros de la puerta de enlace. Consulta Proveedores de modelos personalizados para conocer las opciones de encabezados.

Entregar los valores de configuración a los desarrolladores

Entrega a los desarrolladores un único procedimiento de configuración que coincida con el que verificaste en la prueba piloto. Incluye la siguiente información incluso si distribuyes la configuración de forma centralizada:

Si los equipos son administrados, remite a los desarrolladores a Comprobar si ya existe una configuración. Para la configuración manual, remítelos a Configurar el proveedor.

Si esta implementación cambia el proveedor, incluye las instrucciones que probaste para las conversaciones existentes. Asegúrate de que el responsable de la implementación tenga a mano la configuración anterior que funcionaba, por si la prueba piloto revela algún problema.

La configuración manual no permite imponer ajustes obligatorios. El archivo .codex/config.toml local del proyecto no puede reemplazar claves sensibles que controlan el enrutamiento del proveedor o de la autenticación.

Verificar la configuración desde el equipo de un desarrollador

Para confirmar que el equipo de un desarrollador recibió la configuración distribuida:

1. Confirma que estén instalados el cliente aprobado y los asistentes o archivos de catálogo necesarios. Reinicia Codex y completa los inicios de sesión indicados en las instrucciones para desarrolladores.
2. Confirma que el proveedor y el modelo sean los previstos. En la CLI, usa /status. Usa /debug-config para revisar las capas de configuración si los ajustes efectivos difieren de los que indicaste a los desarrolladores.
3. Ejecuta la prueba breve de Conectar Codex a una puerta de enlace.
4. Haz una pregunta de seguimiento para confirmar que la conversación continúa. Luego busca la solicitud de ese desarrollador en los registros de la puerta de enlace.

Amplía el acceso una vez que la prueba piloto dé los resultados esperados en los clientes y las combinaciones de autenticación que admitas. Guarda la configuración probada y los resultados junto con las instrucciones de implementación para que puedas repetir las pruebas después de actualizar el cliente, la puerta de enlace o las políticas.

Resolver problemas de implementación

Usa el problema observado para determinar si debes revisar la configuración, las credenciales o la puerta de enlace:

Reutilizar una implementación existente de la puerta de enlace

Si tu organización ya usa Claude Code a través de una puerta de enlace, es posible que puedas reutilizar el producto de puerta de enlace, la ruta de red, el sistema de registro y el acceso a Bedrock. Agrega una ruta de la API Responses para Codex, una credencial, los alias de los modelos y config.toml sin alterar la configuración que ya funciona. Ni los ajustes del cliente de Claude ni el contrato de /v1/messages configuran Codex.

Para migrar de forma segura, completa estos pasos en orden:

1. Haz un inventario de la conexión actual de Claude: la URL de la puerta de enlace, el origen de las credenciales, los encabezados necesarios, los alias de los modelos, las asignaciones de perfiles de Bedrock y el canal de distribución administrada.
2. Agrega en paralelo una ruta de la API Responses para Codex y los alias de modelos de Codex.
3. Elige entre OAuth nativo de la puerta de enlace, una clave de API o un asistente de credenciales y autoriza a un usuario de prueba. Si usas una credencial estática, haz que esté disponible mediante env_key. Si usas un asistente, implementa y prueba el contrato de Codex para obtener tokens mediante comandos.
4. Configura el proveedor para ese desarrollador con el método de autenticación que seleccionaste en el paso 3. Si la implementación es administrada, adapta la carga útil a las rutas y al orden de prioridad de Codex que se describen en Implementar una puerta de enlace.
5. Ejecuta la prueba breve de conexión en la CLI o la aplicación de escritorio que usa el desarrollador. Luego ejecuta todas las pruebas de transmisión, continuidad entre turnos, llamadas a herramientas, errores, registro y enrutamiento de alias que se describen en Probar Codex a través de la puerta de enlace.
6. Una vez que la prueba piloto se complete con éxito, distribuye la configuración al resto de los desarrolladores.

Referencia del catálogo de modelos

Empezar con un archivo models.json local

Primero, configura y selecciona el proveedor de la puerta de enlace en el equipo donde ejecutas Codex.

Guarda este catálogo como models.json en el equipo donde se ejecuta Codex. Reemplaza gateway-model por el ID exacto del modelo que acepta tu puerta de enlace. El nombre para mostrar es la etiqueta que ven los usuarios en el selector de modelos.

{
  "models": [
    {
      "slug": "gateway-model",
      "display_name": "Gateway model",
      "base_instructions": "Help the user with their coding tasks.",
      "supported_reasoning_levels": [],
      "shell_type": "shell_command",
      "visibility": "list",
      "supported_in_api": true,
      "priority": 0,
      "support_verbosity": false,
      "truncation_policy": { "mode": "tokens", "limit": 10000 },
      "experimental_supported_tools": []
    }
  ]
}

Para ver un ejemplo más amplio, consulta el catálogo de modelos de Codex.

Asigna a model_catalog_json en config.toml la ruta absoluta del archivo. Reinicia Codex, selecciona Gateway model y envía una solicitud. Comprueba que la puerta de enlace haya recibido el ID del modelo que especificaste en slug.

Si creas un alias para un modelo incluido con Codex, copia la entrada completa de ese modelo del catálogo de tu versión de Codex y cambia los valores de slug y display_name. Si el alias no tiene un modelo de destino para la migración, asigna a upgrade el valor null. Así se conservan la ventana de contexto, las opciones de razonamiento y la configuración de herramientas del modelo.

Publicar un catálogo para los clientes

Esta página está dirigida a los desarrolladores que implementan el formato Codex Models, que define el catálogo de modelos y permite que funcione el selector de modelos. Si desarrollas un proveedor de inferencia, como una puerta de enlace o un servicio en la nube, usa esta especificación para que la aplicación de escritorio y la CLI de Codex puedan detectar tus modelos y usar sus instrucciones y los ajustes que definen sus capacidades.

Si administras una organización y quieres controlar el catálogo de modelos, consulta la guía de configuración de model_catalog_url.

Para admitir el formato, implementa un punto de acceso al catálogo que requiera autenticación. Obtén del proveedor de origen los valores predeterminados vigentes para la versión de Codex que realiza la solicitud, aplica tus ajustes y devuelve el catálogo resultante.

Implementar el punto de acceso al catálogo

El punto de acceso predeterminado al catálogo es /models, relativo a la base_url del proveedor. Por ejemplo, con base_url = "https://gateway.example.com/v1", Codex envía esta solicitud:

GET /v1/models?client_version=0.162.1
Authorization: Bearer <PROVIDER_ACCESS_TOKEN>

La detección predeterminada admite la autenticación mediante comandos y la autenticación mediante el backend de Codex, como el inicio de sesión con ChatGPT. Si un proveedor personalizado usa una clave de API sin autenticación mediante comandos, define model_providers.<id>.model_catalog_url de forma explícita para habilitar la detección remota. Una clave de API por sí sola no activa la detección en la ruta predeterminada.

Usa model_catalog_url para especificar la URL completa del catálogo, como https://gateway.example.com/codex/models. También puede apuntar al punto de acceso predeterminado /v1/models. Codex usa la URL directamente, sin agregar /models. Para la detección mediante una clave de API, mantén habilitada la opción features.api_key_model_discovery, que está activa de forma predeterminada. Los encabezados personalizados por sí solos no habilitan la detección.

Codex envía los datos de autenticación del proveedor seleccionado y los encabezados configurados. También agrega a la URL client_version y los parámetros que el proveedor tenga en query_params. Aloja el catálogo en un servicio autorizado para recibir esas credenciales.

Autentica a quien realiza la solicitud, obtén los valores predeterminados correspondientes del proveedor de origen, aplica tus ajustes y devuelve directamente el JSON completo de ModelsResponse. Asigna a cada entrada un slug único que no esté vacío. Cuando se especifica model_catalog_url de forma explícita, Codex rechaza las redirecciones y las respuestas de más de 1 MiB. Sigue aplicando los controles de acceso a los modelos en las solicitudes de inferencia.

Elimina cualquier valor vigente de model_catalog_json en los clientes que usen el punto de acceso. El archivo local tiene prioridad e impide que se descargue el catálogo remoto.

Usar el esquema correspondiente al cliente

Lee el parámetro de consulta client_version en la solicitud del catálogo. Codex envía la versión de su CLI con el formato major.minor.patch, sin sufijos de versiones preliminares. En los clientes de escritorio, ese valor corresponde a la versión de la CLI incluida con la aplicación.

Usa la etiqueta rust-v<version> correspondiente en el repositorio público de Codex o, si se trata de una compilación personalizada, el commit exacto del código fuente. Los siguientes enlaces usan rust-v0.162.1. Selecciona la revisión que corresponda a tu cliente:

• Consulta los tipos de respuesta ModelsResponse y ModelInfo para conocer el esquema.
• Revisa el archivo models.json incluido con Codex para ver un ejemplo completo. Este archivo contiene datos del catálogo, no un documento JSON Schema.

El archivo incluido refleja el estado del catálogo en el momento de publicar esa versión. Obtén los valores predeterminados vigentes antes de generar tu catálogo.

Obtener los valores predeterminados vigentes del proveedor de origen

Los proveedores de nube que ofrecen modelos de OpenAI obtienen los valores predeterminados de OpenAI. Las puertas de enlace leen el catálogo de su proveedor de nube o de origen para conservar la configuración del modelo desplegado y su disponibilidad por cuenta y región. En cada paso, envía la versión de Codex que realiza la solicitud y autentícate por separado en cada punto de acceso.

Para obtener los valores predeterminados directamente de OpenAI, llama al punto de acceso de modelos de Codex con el mismo valor de client_version. Por ejemplo, si usas una clave de API de OpenAI:

curl --fail --silent --show-error \
  'https://chatgpt.com/backend-api/codex/models?client_version=0.162.1' \
  -H "Authorization: Bearer $OPENAI_API_KEY"

Para una integración con ChatGPT, usa el token de acceso de ChatGPT de quien realiza la solicitud y, cuando corresponda, el encabezado ChatGPT-Account-ID. Usa credenciales autorizadas para el punto de acceso de origen. La clave de API de la puerta de enlace no sirve para autenticarse en OpenAI.

Procesa la respuesta completa, incluido el arreglo models de nivel superior. Este punto de acceso devuelve metadatos de Codex, como instrucciones, valores predeterminados de razonamiento, ajustes de herramientas, límites de contexto y niveles de servicio. El punto de acceso público /v1/models no proporciona este catálogo.

Actualiza estos valores predeterminados incluso si la versión de Codex no ha cambiado. Como el catálogo puede variar según los permisos de quien lo solicita, limita cada solicitud a la identidad correspondiente en el proveedor de origen y respeta los controles de caché de la respuesta. Guarda tus ajustes por separado para poder volver a aplicarlos cuando actualices los valores predeterminados.

Aplicar los ajustes propios del proveedor

Modifica los valores de los campos sin alterar la estructura de la respuesta que corresponde a esa versión:

• Incluye solo los modelos que pueda usar quien realiza la solicitud. Asigna cada slug a una ruta de inferencia admitida y ajusta display_name, description o priority. Si un alias no tiene un modelo de destino para la migración, asigna a upgrade el valor null.
• Configura las opciones de razonamiento, los límites de contexto, las modalidades de entrada y los niveles de servicio con valores que admitan tanto el modelo como la ruta. Elige los valores predeterminados entre las opciones admitidas. Si la ruta no ofrece niveles de servicio, deja vacíos service_tiers y additional_speed_tiers, y asigna a default_service_tier el valor null.
• Conserva las instrucciones y los ajustes de herramientas del proveedor de origen, salvo que ya hayas probado los que los reemplazarán. Los metadatos no agregan capacidades al modelo ni conceden acceso a la inferencia.

Si usas un alias de modelo en la puerta de enlace, consulta cómo proporcionar los metadatos del modelo. Prueba el catálogo resultante con cada versión de Codex que admitas.

Usar los tipos públicos de Rust

Usa los crates de la misma etiqueta pública de Git o del mismo commit al que corresponda el esquema del cliente:

• Usa codex-protocol para trabajar con codex_protocol::openai_models::{ModelsResponse, ModelInfo}. Deserializa la respuesta con serde_json::from_slice::<ModelsResponse>(), edita catalog.models y serializa la estructura completa con serde_json::to_vec(). Esta estructura gestiona los campos de compatibilidad de las instrucciones del modelo.
• Usa codex-models-manager::bundled_models_response() para cargar el catálogo estático incluido en esa revisión como un ModelsResponse. Esta función no obtiene los valores predeterminados vigentes del proveedor de origen.

Documentación relacionada

• Configurar el proveedor
• MCP
• Complementos
• Configuración administrada