Implantar um gateway

Como administrador do gateway, configure as rotas dos modelos e autorize um usuário para o piloto. Teste a conexão em cada cliente ao qual você oferece suporte antes de distribuir as configurações aos desenvolvedores. Para autenticação no gateway, use OAuth nativo do gateway, chaves de API ou auxiliares de credenciais. Para combinar a autenticação no gateway com o login no espaço de trabalho do ChatGPT, consulte Entrar com o ChatGPT por um gateway.

Pré-requisitos

Antes de implantar o Codex para os desenvolvedores, confirme que você tem:

• Um gateway que atende a solicitações HTTPS exatamente na URL base que você vai distribuir.
• Uma credencial do provedor de origem armazenada no gateway.
• Aliases de modelo aprovados para uso no Codex, cada um mapeado para o modelo de origem correspondente.
• Um método de autenticação testado: OAuth nativo do gateway, chaves de API do gateway com escopo delimitado ou um auxiliar de credenciais.
• Para OAuth, um cliente público registrado, usuários de teste aprovados e um gateway capaz de validar tokens de acesso OAuth.
• Para chaves de API ou auxiliares, um mecanismo de distribuição de segredos ou um auxiliar testado.
• Um meio de distribuir a configuração, os auxiliares necessários e os arquivos de catálogo.

Requisitos do gateway

Antes de conectar o Codex, verifique se o gateway atende aos seguintes requisitos:

• Aceita solicitações da API Responses do Codex em POST /v1/responses.
• Transmite eventos SSE sem armazená-los em buffer e encerra a transmissão com response.completed.
• Permite continuar a conversa quando o cliente reenvia os dados de entrada.
• Preserva previous_response_id somente quando o WebSocket ou o transporte incremental está habilitado.
• Preserva as chamadas de função e os itens function_call_output correspondentes.
• Encaminha as solicitações de cada alias de modelo usado pelo Codex para o modelo de origem previsto.
• Autentica cada usuário individualmente e retorna erros que ajudam a identificar a causa.

Um endpoint de integridade, /v1/models, uma resposta de Chat Completions ou uma única resposta em texto simples não bastam para comprovar a compatibilidade do gateway. Consulte os Requisitos de compatibilidade do gateway para conhecer o contrato em detalhes.

Implantar o gateway

Depois que o gateway estiver em execução, siga estas cinco etapas, na ordem indicada, para verificar se os desenvolvedores conseguem usar o Codex por meio dele:

1. Escolha os nomes dos modelos e verifique as rotas.
2. Escolha o método de autenticação.
3. Teste o Codex por meio do gateway.
4. Distribua a configuração.
5. Verifique a configuração na máquina de um desenvolvedor.

Escolher os nomes e as rotas dos modelos

Defina model no Codex com o nome que o gateway usa para o modelo. Configure o gateway para encaminhar as solicitações que usam esse nome ao modelo de origem aprovado.

Usar um catálogo de modelos para nomes personalizados

Para criar um catálogo local, comece pelo exemplo de models.json.

Forneça um catálogo de modelos quando o gateway usar um nome de modelo que o Codex não reconhece. O catálogo informa quais instruções, opções de raciocínio, limites de contexto e recursos de ferramentas o Codex deve usar para esse nome. Se não houver uma entrada correspondente, a solicitação pode chegar ao modelo de origem correto, mas o Codex usará configurações genéricas.

Hospede um catálogo remoto e use model_providers.<id>.model_catalog_url para atualizar os metadados dos modelos de forma centralizada, ou distribua um arquivo local com model_catalog_json. Use um catálogo local quando o OAuth nativo do gateway for a única credencial. O OAuth por si só não habilita a descoberta de catálogos remotos. Consulte a referência de configuração para saber mais sobre as duas opções.

Solicite ao provedor de nuvem ou de gateway um endpoint ou arquivo de catálogo compatível com a sua versão do Codex. Verifique se o catálogo inclui cada alias aprovado e os metadados do modelo correspondente. Para implementar um catálogo, consulte Implementar catálogos de modelos para gateways e nuvens.

Disponibilizar um catálogo remoto

Use o endpoint HTTPS do catálogo fornecido pelo provedor. Distribua a URL completa do endpoint na tabela do provedor selecionado em 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"

Disponibilize CODEX_GATEWAY_API_KEY para o processo do Codex. Defina base_url separadamente para encaminhar as solicitações de inferência pelo gateway. Se você omitir esse valor, o Codex usará o endpoint padrão da OpenAI para o modo de autenticação atual.

A descoberta exige autenticação por chave de API, por comando ou pelo backend do Codex. Usar apenas o OAuth nativo do gateway ou cabeçalhos personalizados não aciona a descoberta.

Quando a lista de modelos aprovados mudar, coordene a atualização do catálogo com o provedor. Reinicie o cliente após alterar a configuração.

Remova qualquer configuração de model_catalog_json em vigor, inclusive se ela for imposta por requirements.toml. Essa configuração tem precedência sobre a URL remota e impede que o Codex busque o catálogo remoto.

Distribuir um catálogo local

Use model_catalog_json para carregar o arquivo fornecido pelo provedor na inicialização. Um catálogo local personalizado substitui o catálogo que acompanha o Codex.

Defina o alias do gateway, o slug do catálogo e o model do Codex como company-coding-model. Adicione as configurações abaixo antes da primeira tabela TOML na configuração do Codex que você vai distribuir. Use o caminho absoluto real do arquivo:

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

Reinicie a CLI ou o aplicativo para desktop depois de alterar o catálogo, pois o Codex o carrega na inicialização.

Verificar as rotas dos modelos

Para cada modelo, verifique a rota com uma solicitação real à API Responses e consulte os registros do gateway. Uma resposta de /v1/models pode ajudar a descobrir os nomes dos modelos, mas não comprova que um modelo processa as solicitações e usa as ferramentas conforme exigido.

O roteamento de modelos e a autorização de ferramentas são etapas distintas da implantação. Configure separadamente as conexões MCP, a distribuição de plugins e as respectivas políticas.

Escolher o método de autenticação

OAuth nativo do gateway

1. Registre um cliente OAuth público que ofereça suporte ao fluxo de código de autorização com PKCE e aprove os usuários ou grupos que poderão fazer login.
2. Configure o gateway para validar o token de acesso emitido no cookie ou cabeçalho personalizado escolhido. Aplique a cada identidade de usuário as permissões de acesso aos modelos aprovados, os limites de taxa e os orçamentos.
3. Siga as instruções de OAuth nativo do gateway para obter as URLs de autorização e de token, o ID do cliente público, os escopos, o recurso opcional, as configurações de entrega do token e a porta fixa de redirecionamento, se houver. Registre o URI de redirecionamento de loopback correspondente no provedor de identidade.
4. Com um usuário de teste, verifique o login pelo navegador, a renovação do token e a revogação do acesso na CLI ou no aplicativo para desktop que você pretende implantar. Confirme que o navegador consegue acessar o endereço de callback, inclusive para quem usa a CLI remotamente.

Cada usuário faz login individualmente. Distribua apenas a configuração do OAuth. Não distribua um segredo de cliente, uma chave de API do gateway nem o executável de um auxiliar. Mantenha as credenciais do provedor de origem no gateway.

Chaves de API ou auxiliares de credenciais

1. Emita uma credencial do gateway com escopo delimitado para cada desenvolvedor. Assim, você poderá identificar o uso de cada um e revogar o acesso individualmente.
2. Defina os modelos aprovados, os limites de taxa, o orçamento, o vencimento e o período de renovação de cada credencial.
3. Entregue as credenciais pelo gerenciador de segredos ou por um auxiliar de credenciais instalado. Mantenha as credenciais do provedor de origem e as de administrador do gateway fora das máquinas dos desenvolvedores.
4. Se usar um auxiliar, siga o contrato de autenticação por comando e teste a obtenção e a renovação do token antes da distribuição.
5. Informe aos desenvolvedores como renovar as credenciais e a quem pedir ajuda.

Testar o Codex por meio do gateway

Antes de distribuir qualquer item, siga as instruções em Configurar o provedor para configurar um único usuário de teste isolado com o bloco do provedor e o método de autenticação que você pretende distribuir.

Se o gateway disponibilizar o catálogo de modelos, confirme que ele retorna um array models compatível com o Codex. Se a inferência na OpenAI usar a credencial do usuário, confirme que o gateway encaminha os cabeçalhos obrigatórios do ChatGPT ao backend do Codex.

Registre a versão do cliente, o sistema operacional, o ID do provedor, o alias do modelo e o método de autenticação usados no piloto. Execute as verificações abaixo em cada interface que você pretende oferecer aos desenvolvedores, seja a CLI ou o aplicativo para desktop. Se você oferecer tanto a autenticação exclusiva no gateway quanto a autenticação no gateway combinada com o login com o ChatGPT, teste cada combinação separadamente.

Se a aprovação automática estiver habilitada, use uma pasta de teste descartável para acionar uma ferramenta cuja ação exija revisão segundo a política que você pretende aplicar. Confirme que o gateway processa a solicitação de revisão e que o cliente aplica a decisão de aprovação. Uma chamada de ferramenta somente leitura que dispensa aprovação não testa esse fluxo. Antes de ampliar o piloto, registre os fluxos de trabalho que não têm suporte.

Se a implantação mudar o provedor de quem já usa o Codex, teste uma conversa nova e outra criada antes da mudança em cada cliente compatível. Registre se os usuários conseguem visualizar a conversa existente, continuá-la ou criar uma ramificação a partir dela. Forneça um procedimento de recuperação para cada fluxo de trabalho bloqueado. Não presuma que alterar o provedor padrão migra o histórico de conversas.

Depois que todas as verificações passarem, prepare as instruções para os desenvolvedores.

Distribuir a configuração

Para que todas as máquinas se conectem da mesma forma, distribua a URL base do gateway, o ID do provedor, o alias do modelo aprovado e as configurações de autenticação.

O que distribuir

Para o OAuth nativo do gateway, distribua a tabela do provedor e a tabela [model_providers.<id>.gateway_oauth] do guia de conexão com os valores de registro obtidos anteriormente. Mantenha requires_openai_auth = false e omita env_key, experimental_bearer_token e a tabela auth de autenticação por comando quando o OAuth for a única credencial do gateway.

Para usar um auxiliar de credenciais, distribua o bloco de config.toml abaixo pela camada de configuração escolhida. Use um modelo reconhecido pela sua versão do Codex ou forneça o catálogo correspondente, conforme descrito acima. Instale o programa que obtém o token no caminho configurado para o 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 uma chave estática de teste com validade curta, remova o bloco de autenticação, coloque env_key = "CODEX_GATEWAY_API_KEY" dentro de [model_providers.enterprise-gateway] e defina a variável fora do TOML. Não combine env_key com autenticação por comando.

Distribuir configurações padrão e requisitos

Se os usuários não entram no Codex com o ChatGPT, você pode distribuir as configurações da equipe a partir do seu próprio servidor. O Codex busca essas configurações independentemente de como você encaminha as solicitações aos modelos.

Consulte Precedência das configurações para escolher em qual camada distribuir as configurações padrão. Para saber mais sobre configurações obrigatórias e payloads de MDM para macOS, consulte Configuração gerenciada.

Para definir padrões para toda a máquina no macOS ou no Linux, use /etc/codex/config.toml. No Windows, coloque config.toml em %ProgramData%\OpenAI\Codex\. As configurações de usuário e de perfil podem substituir esses padrões. As referências acima descrevem os requisitos compatíveis e os locais dos respectivos arquivos.

Distribua separadamente os executáveis dos auxiliares e os arquivos de catálogo locais mencionados na configuração.

Para tornar obrigatória uma URL de catálogo remoto, inclua a definição completa do provedor em requirements.toml, na tabela [model_providers.<id>]. Uma definição obrigatória substitui a tabela correspondente do provedor na configuração comum. Inclua base_url, as configurações de autenticação e os demais campos necessários. Use o requisito model_provider quando também precisar tornar obrigatória a seleção desse provedor.

model_catalog_json aponta para um arquivo JSON local. Se você tornar essa configuração obrigatória por meio de requirements.toml, o requisito fixará o caminho, mas não distribuirá o arquivo. Coloque o catálogo nesse caminho absoluto antes de iniciar o Codex.

No TOML, escreva os caminhos absolutos do Windows já resolvidos. O Codex não expande %ProgramData% nos valores de model_catalog_json nem de command na autenticação do provedor. Por exemplo, use os caminhos abaixo somente se os arquivos tiverem sido instalados nesses locais:

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"]

Uma CLI executada no WSL lê os caminhos do Linux e o CODEX_HOME do Linux. Ela não herda automaticamente a configuração nativa do Windows.

Distribuir cabeçalhos de roteamento

Se o gateway encaminha solicitações de acordo com a configuração ou a ferramenta, adicione os cabeçalhos esperados à configuração do provedor no arquivo requirements.toml gerenciado. O exemplo abaixo fornece o ID da configuração de roteamento e identifica o Codex como cliente:

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

Use env_http_headers para os valores de cabeçalhos fornecidos pelo ambiente do cliente. Envie uma solicitação de teste e confirme a rota selecionada nos logs do gateway. Consulte Provedores de modelos personalizados para conhecer as opções de cabeçalho.

Entregar os valores de configuração aos desenvolvedores

Forneça aos desenvolvedores um único procedimento de configuração que corresponda ao que você testou no piloto. Inclua as informações abaixo mesmo quando a distribuição da configuração for centralizada:

Para máquinas gerenciadas, encaminhe os desenvolvedores para Verificar se já existe uma configuração. Para a configuração manual, encaminhe-os para Configurar o provedor.

Se a implantação mudar o provedor, inclua as instruções que você testou para as conversas existentes. Mantenha a configuração anterior que funcionava à disposição do responsável pela implantação, caso o piloto revele algum problema.

A configuração manual não permite impor requisitos. O arquivo .codex/config.toml local do projeto não pode substituir chaves sensíveis que controlam o roteamento do provedor ou da autenticação.

Verificar a configuração na máquina de um desenvolvedor

Para confirmar que a máquina de um desenvolvedor recebeu as configurações distribuídas:

1. Confirme que o cliente aprovado e os auxiliares ou arquivos de catálogo necessários estão instalados. Reinicie o Codex e conclua as etapas de login indicadas nas instruções fornecidas aos desenvolvedores.
2. Confirme que o provedor e o modelo são os esperados. Na CLI, use /status. Use /debug-config para inspecionar as camadas de configuração quando as configurações em vigor forem diferentes das informadas aos desenvolvedores.
3. Execute o teste rápido descrito em Conectar-se a um gateway.
4. Faça uma pergunta complementar para confirmar que a conversa continua. Em seguida, procure a solicitação desse desenvolvedor nos logs do gateway.

Amplie o acesso depois que o piloto passar nas verificações em todos os clientes e combinações de autenticação aos quais você oferece suporte. Guarde a configuração testada e os resultados junto com as instruções de implantação para poder repetir as verificações após atualizações do cliente, do gateway ou das políticas.

Solucionar falhas na implantação

Use o sintoma para identificar onde investigar o problema: na configuração, nas credenciais ou no gateway.

Reutilizar uma implantação de gateway existente

Se a sua organização já usa o Claude Code por meio de um gateway, talvez seja possível reutilizar o mesmo produto de gateway, o caminho de rede, a infraestrutura de logs e o acesso ao Bedrock. Adicione uma rota da API Responses para o Codex, uma credencial, aliases de modelo e o arquivo config.toml, preservando a configuração que já funciona. As configurações do cliente Claude e o contrato de /v1/messages não configuram o Codex.

Para migrar com segurança, siga estas etapas na ordem indicada:

1. Faça um inventário da conexão atual do Claude, incluindo a URL do gateway, a origem das credenciais, os cabeçalhos obrigatórios, os aliases de modelo, os mapeamentos de perfis do Bedrock e o canal de distribuição gerenciada.
2. Adicione uma rota paralela da API Responses para o Codex e os aliases de modelo do Codex.
3. Escolha entre OAuth nativo do gateway, uma chave de API ou um auxiliar de credenciais e autorize um usuário de teste. Para uma credencial estática, disponibilize-a por meio de env_key. Para um auxiliar, implemente e teste o contrato do Codex para obtenção de tokens por comando.
4. Configure o provedor para esse desenvolvedor com o método de autenticação escolhido na etapa 3. Para uma implantação gerenciada, adapte o payload aos caminhos e à ordem de precedência do Codex descritos em Implantar um gateway.
5. Execute a verificação rápida da conexão na CLI ou no aplicativo para desktop que o desenvolvedor usa. Em seguida, execute todas as verificações de streaming, continuação da conversa, chamadas de ferramentas, erros, logs e roteamento de aliases descritas em Testar o Codex por meio do gateway.
6. Depois que o piloto passar nas verificações, distribua a configuração aos demais desenvolvedores.

Referência do catálogo de modelos

Começar com um arquivo models.json local

Primeiro, configure e selecione o provedor do gateway na máquina em que você executa o Codex.

Salve este catálogo como models.json na máquina que executa o Codex. Substitua gateway-model pelo ID exato do modelo aceito pelo gateway. O nome de exibição é o rótulo que os usuários veem no seletor 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 um exemplo mais amplo, consulte o catálogo de modelos do Codex.

Defina model_catalog_json em config.toml com o caminho absoluto do arquivo. Reinicie o Codex, selecione Gateway model e envie uma solicitação. Verifique se o gateway recebeu o ID do modelo que você definiu em slug.

Para criar um alias de um modelo que acompanha o Codex, copie a entrada completa desse modelo no catálogo da sua versão do Codex e altere slug e display_name. Se o alias não tiver um modelo de destino para migração, defina upgrade como null. Assim, você preserva a janela de contexto, as opções de raciocínio e as configurações de ferramentas do modelo.

Disponibilizar um catálogo para os clientes

Esta página se destina a desenvolvedores que implementam o formato Codex Models. Esse formato define o catálogo de modelos usado pelo seletor de modelos. Se você desenvolve um provedor de inferência, como um gateway ou um serviço de nuvem, use esta especificação para que o aplicativo para desktop e a CLI do Codex descubram seus modelos e usem as instruções e configurações de recursos de cada um.

Se você administra uma organização e quer controlar o catálogo de modelos, consulte as orientações de configuração de model_catalog_url.

Para oferecer suporte ao formato, implemente um endpoint de catálogo que exija autenticação. Busque no provedor de origem as configurações padrão atuais para a versão do Codex que fez a solicitação, aplique as alterações locais e retorne o catálogo resultante.

Implementar o endpoint do catálogo

O endpoint padrão do catálogo é /models, relativo à base_url do provedor. Por exemplo, com base_url = "https://gateway.example.com/v1", o Codex faz a seguinte solicitação:

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

Por padrão, a descoberta aceita autenticação por comando e autenticação pelo backend do Codex, como o login com o ChatGPT. Para um provedor personalizado que usa autenticação por chave de API sem autenticação por comando, defina model_providers.<id>.model_catalog_url explicitamente para habilitar a descoberta remota. A chave de API por si só não aciona a descoberta no caminho padrão.

Use model_catalog_url para especificar a URL completa do catálogo, como https://gateway.example.com/codex/models. Ela também pode apontar para o endpoint padrão /v1/models. O Codex usa essa URL diretamente, sem acrescentar /models. Para a descoberta por chave de API, mantenha features.api_key_model_discovery habilitado, como vem por padrão. Cabeçalhos personalizados por si só não habilitam a descoberta.

O Codex envia os dados de autenticação e os cabeçalhos configurados para o provedor selecionado e acrescenta à URL client_version e os parâmetros definidos em query_params do provedor, se houver. Hospede o catálogo em um serviço autorizado a receber essas credenciais.

Autentique o solicitante, busque as configurações padrão correspondentes no provedor de origem, aplique suas alterações e retorne diretamente o JSON completo de ModelsResponse. Atribua a cada entrada um slug exclusivo e não vazio. Quando model_catalog_url é definido explicitamente, o Codex rejeita redirecionamentos e respostas maiores que 1 MiB. Continue aplicando os controles de acesso aos modelos em cada solicitação de inferência.

Nos clientes que usam o endpoint, remova qualquer configuração de model_catalog_json em vigor. O arquivo local tem precedência e impede que o Codex busque o catálogo remoto.

Usar o schema correspondente ao cliente

Leia o parâmetro de consulta client_version na solicitação do catálogo. O Codex envia a versão da CLI no formato major.minor.patch, sem o sufixo de pré-lançamento, se houver. No aplicativo para desktop, esse valor é a versão da CLI que acompanha o aplicativo.

Use a tag rust-v<version> correspondente no repositório público do Codex. Para uma compilação personalizada, use o commit exato do código-fonte. Os links abaixo usam rust-v0.162.1. Selecione a revisão correspondente ao seu cliente:

• Consulte os tipos de resposta ModelsResponse e ModelInfo para conhecer o schema.
• Consulte o arquivo models.json que acompanha o Codex para ver um exemplo completo. Esse arquivo contém dados do catálogo, e não um documento JSON Schema.

O arquivo incluído registra os dados disponíveis na data da versão. Busque as configurações padrão atuais antes de gerar seu catálogo.

Buscar as configurações padrão atuais do provedor de origem

Os provedores de nuvem que disponibilizam modelos da OpenAI buscam as configurações padrão na OpenAI. Os gateways leem o catálogo do provedor de nuvem ou de origem para preservar as configurações do modelo implantado e sua disponibilidade por conta e região. Informe a versão do Codex que fez a solicitação em cada etapa e autentique-se separadamente em cada endpoint.

Para buscar as configurações padrão diretamente na OpenAI, chame o endpoint de modelos do Codex com o mesmo valor de client_version. Por exemplo, com uma chave de API da 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 uma integração com o ChatGPT, use o token de acesso ao ChatGPT do solicitante e, quando aplicável, o cabeçalho ChatGPT-Account-ID. Use credenciais autorizadas para o endpoint de origem. A chave de API do próprio gateway não permite a autenticação na OpenAI.

Analise a resposta completa, incluindo o array models de nível superior. Esse endpoint retorna metadados do Codex, como instruções, configurações padrão de raciocínio, configurações de ferramentas, limites de contexto e níveis de serviço. O endpoint público /v1/models não fornece esse catálogo.

Atualize essas configurações padrão mesmo que a versão do Codex não tenha mudado. Restrinja as solicitações à identidade prevista no provedor de origem e respeite os controles de cache da resposta, pois os catálogos podem variar conforme o acesso do solicitante. Mantenha suas alterações separadas para poder reaplicá-las às configurações padrão atualizadas.

Aplicar as alterações do provedor

Altere os valores dos campos e preserve a estrutura da resposta definida pela versão:

• Filtre os modelos para incluir apenas aqueles que o solicitante pode usar. Mapeie cada slug para uma rota de inferência compatível e ajuste display_name, description ou priority. Para um alias sem migração de modelo, defina upgrade como null.
• Defina as opções de raciocínio, os limites de contexto, as modalidades de entrada e os níveis de serviço de acordo com os valores aceitos pelo modelo e pela rota. Escolha os valores padrão entre as opções compatíveis. Para uma rota sem níveis de serviço, esvazie service_tiers e additional_speed_tiers e defina default_service_tier como null.
• Preserve as instruções e as configurações de ferramentas do provedor de origem, a menos que já tenha testado as substituições. Os metadados não acrescentam recursos ao modelo nem concedem acesso à inferência.

Para um alias de modelo do gateway, veja como fornecer metadados do modelo. Teste o catálogo resultante com cada versão do Codex à qual você oferece suporte.

Usar os tipos públicos de Rust

Use crates da mesma tag ou do mesmo commit do repositório Git público que corresponde ao schema do cliente:

• Use codex-protocol para acessar codex_protocol::openai_models::{ModelsResponse, ModelInfo}. Desserialize a resposta com serde_json::from_slice::<ModelsResponse>(), edite catalog.models e serialize toda a estrutura com serde_json::to_vec(). Essa estrutura trata os campos de compatibilidade das instruções do modelo.
• Use codex-models-manager::bundled_models_response() para carregar o catálogo estático incluído nessa revisão como um ModelsResponse. Essa função não busca as configurações padrão atuais do provedor de origem.

Documentação relacionada

• Configurar o provedor
• MCP
• Plug-ins
• Configuração gerenciada