Déployer une passerelle

En tant qu’administrateur de la passerelle, configurez le routage vers les modèles et autorisez un utilisateur à participer au pilote. Testez la connexion sur chaque client pris en charge avant de distribuer les paramètres aux développeurs. Pour l’authentification auprès de la passerelle, utilisez OAuth natif de la passerelle, des clés API ou des assistants d’authentification. Pour combiner cette authentification avec la connexion à un espace de travail ChatGPT, consultez Se connecter avec ChatGPT via une passerelle.

Prérequis

Avant de déployer Codex auprès des développeurs, vérifiez que vous disposez des éléments suivants :

• Une passerelle qui répond en HTTPS à l’URL de base exacte que vous allez distribuer.
• Un identifiant d’accès au fournisseur en amont, conservé sur la passerelle.
• Des alias de modèles approuvés pour Codex, associés aux modèles en amont prévus.
• Une méthode d’authentification testée : OAuth natif de la passerelle, clés API de passerelle à portée limitée ou assistant d’authentification.
• Pour OAuth, un client public enregistré, des utilisateurs de test autorisés et une passerelle capable de valider les jetons d’accès OAuth.
• Pour les clés API ou les assistants d’authentification, un mécanisme de distribution des secrets ou un assistant testé.
• Un moyen de distribuer la configuration, les éventuels assistants requis et les fichiers de catalogue.

Exigences relatives à la passerelle

Avant de connecter Codex, vérifiez que la passerelle prend en charge chacun des comportements requis :

• Accepter les requêtes que Codex adresse à l’API Responses sur POST /v1/responses.
• Transmettre les événements SSE en continu, sans mise en mémoire tampon, et terminer le flux par response.completed.
• Permettre la poursuite d’un échange lorsque le client renvoie les données d’entrée précédentes.
• Conserver previous_response_id uniquement si WebSocket ou le transport incrémental est activé.
• Conserver les appels de fonction et les éléments function_call_output correspondants.
• Acheminer les requêtes portant chaque alias de modèle utilisé par Codex vers le modèle en amont prévu.
• Authentifier chaque utilisateur individuellement et renvoyer des erreurs qui permettent d’en identifier la cause.

Un point de terminaison de contrôle d’état, /v1/models, une réponse de Chat Completions ou une seule réponse en texte brut ne suffit pas à établir la compatibilité de la passerelle. Consultez les exigences de compatibilité des passerelles pour connaître le contrat détaillé.

Déployer la passerelle

Une fois la passerelle déployée, suivez ces cinq étapes dans l’ordre pour vérifier son fonctionnement sur les postes de développement :

1. Choisissez les noms des modèles et vérifiez les routes.
2. Choisissez la méthode d’authentification.
3. Testez Codex via la passerelle.
4. Distribuez la configuration.
5. Vérifiez la configuration depuis le poste d’un développeur.

Choisir les noms des modèles et les routes

Attribuez au paramètre model de Codex le nom du modèle utilisé par la passerelle. Configurez la passerelle pour qu’elle achemine les requêtes portant ce nom vers le modèle en amont approuvé.

Utiliser un catalogue de modèles pour les noms personnalisés

Pour créer un catalogue local, partez de l’exemple de fichier models.json.

Fournissez un catalogue de modèles lorsque votre passerelle utilise un nom de modèle que Codex ne reconnaît pas. Le catalogue précise les instructions, les options de raisonnement, les limites de contexte et les capacités d’utilisation des outils que Codex associe à ce nom. Sans entrée correspondante, une requête peut atteindre le modèle en amont prévu alors que Codex utilise des paramètres génériques.

Hébergez un catalogue distant et indiquez son URL dans model_providers.<id>.model_catalog_url pour centraliser la mise à jour des métadonnées des modèles, ou distribuez un fichier local avec model_catalog_json. Utilisez un catalogue local si OAuth natif de la passerelle est le seul moyen d’authentification. OAuth seul ne permet pas à Codex de découvrir le catalogue distant. Ces deux paramètres sont décrits dans la référence de configuration.

Demandez à votre fournisseur de cloud ou de passerelle un point de terminaison de catalogue ou un fichier compatible avec votre version de Codex. Vérifiez que le catalogue contient chaque alias approuvé et les métadonnées du modèle correspondant. Pour créer un catalogue, consultez Mettre en œuvre des catalogues de modèles pour les passerelles et les plateformes cloud.

Mettre à disposition un catalogue distant

Utilisez le point de terminaison HTTPS du catalogue indiqué par votre fournisseur. Distribuez l’URL complète de ce point de terminaison dans la table du fournisseur sélectionné dans 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"

Rendez CODEX_GATEWAY_API_KEY accessible au processus Codex. Définissez séparément base_url pour acheminer les requêtes d’inférence via la passerelle. Si vous omettez ce paramètre, Codex utilise le point de terminaison OpenAI par défaut pour le mode d’authentification actif.

La découverte du catalogue nécessite une authentification par clé API, par commande ou via le backend de Codex. Ni OAuth natif de la passerelle ni des en-têtes personnalisés ne suffisent à la déclencher.

Coordonnez les mises à jour du catalogue avec votre fournisseur lorsque la liste des modèles approuvés change. Redémarrez le client après avoir modifié sa configuration.

Supprimez tout paramètre model_catalog_json qui s’applique, y compris s’il est imposé par requirements.toml. Ce paramètre est prioritaire sur l’URL distante et empêche la récupération du catalogue distant.

Distribuer un catalogue local

Utilisez model_catalog_json pour charger au démarrage le fichier transmis par votre fournisseur. Un catalogue local personnalisé remplace le catalogue livré avec Codex.

Attribuez à l’alias de la passerelle, au slug du catalogue et au paramètre model de Codex la même valeur : company-coding-model. Ajoutez les paramètres suivants avant la première table TOML dans la configuration Codex que vous distribuez, en indiquant le chemin absolu réel du fichier :

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

Redémarrez la CLI ou l’application de bureau après avoir modifié le catalogue, car Codex le charge au démarrage.

Vérifier le routage des modèles

Pour chaque modèle, envoyez une véritable requête à l’API Responses et vérifiez dans les journaux de la passerelle qu’elle a suivi la route prévue. Une réponse de /v1/models peut vous aider à découvrir les noms disponibles, mais elle ne prouve pas qu’un modèle prend en charge les requêtes et les appels d’outils requis.

Le routage des modèles et l’autorisation d’utiliser les outils sont deux volets distincts du déploiement. Configurez séparément les connexions MCP, la distribution des plugins et les règles qui s’y appliquent.

Choisir la méthode d’authentification

OAuth natif de la passerelle

1. Enregistrez un client OAuth public qui prend en charge le flux par code d’autorisation avec PKCE, puis autorisez les utilisateurs ou les groupes qui pourront se connecter.
2. Configurez la passerelle pour qu’elle valide le jeton d’accès émis, transmis dans le cookie ou l’en-tête personnalisé choisi. Associez les modèles approuvés, les limites de débit et les budgets à l’identité de chaque utilisateur.
3. Suivez les instructions de la section OAuth natif de la passerelle pour recueillir les URL d’autorisation et d’obtention des jetons, l’identifiant du client public, les portées, la ressource facultative, les paramètres de transmission du jeton et, le cas échéant, le port de redirection fixe. Enregistrez l’URI de redirection de bouclage correspondante auprès de votre fournisseur d’identité.
4. Avec un utilisateur de test, vérifiez la connexion depuis le navigateur, le renouvellement du jeton et la révocation de l’accès dans la CLI ou l’application de bureau que vous prévoyez de déployer. Vérifiez que le navigateur peut atteindre l’adresse de rappel, y compris pour les utilisateurs qui exécutent la CLI à distance.

Chaque utilisateur se connecte avec son propre compte. Distribuez uniquement la configuration OAuth, sans secret client, clé API de passerelle ni exécutable d’assistant d’authentification. Conservez les identifiants du fournisseur en amont sur la passerelle.

Clés API ou assistants d’authentification

1. Délivrez à chaque développeur un identifiant de passerelle à portée limitée pour pouvoir lui attribuer sa consommation et révoquer son accès individuellement.
2. Définissez les modèles approuvés, les limites de débit, le budget, la date d’expiration et la période de renouvellement de chaque identifiant.
3. Transmettez les identifiants via votre gestionnaire de secrets ou un assistant d’authentification installé. Conservez les identifiants du fournisseur en amont et ceux de l’administrateur de la passerelle hors des postes de développement.
4. Si vous utilisez un assistant, respectez le contrat d’authentification par commande et testez la récupération et le renouvellement des jetons avant la distribution.
5. Indiquez aux développeurs comment renouveler leurs identifiants et à qui s’adresser en cas de besoin.

Tester Codex via la passerelle

Avant toute distribution, suivez les instructions de la section Configurer le fournisseur pour configurer un compte de test isolé avec le bloc du fournisseur et la méthode d’authentification que vous prévoyez de distribuer.

Si la passerelle fournit le catalogue de modèles, vérifiez qu’elle renvoie un tableau models compatible avec Codex. Si les requêtes d’inférence adressées à OpenAI utilisent l’identifiant de l’utilisateur, vérifiez que la passerelle transmet les en-têtes ChatGPT requis au backend de Codex.

Pour le pilote, consignez la version du client, le système d’exploitation, l’identifiant du fournisseur, l’alias du modèle et la méthode d’authentification. Effectuez les vérifications ci-dessous dans chacune des interfaces que vous prévoyez de prendre en charge : CLI, application de bureau ou les deux. Si vous proposez l’authentification auprès de la passerelle seule et l’authentification auprès de la passerelle associée à la connexion à ChatGPT, testez les deux configurations séparément.

Si l’approbation automatique est activée, utilisez un dossier de test temporaire pour déclencher une action d’outil qui doit être examinée selon les règles que vous prévoyez d’appliquer. Vérifiez que la passerelle traite la demande d’examen et que le client applique la décision d’approbation. Un appel d’outil en lecture seule qui ne nécessite aucune approbation ne permet pas de tester ce mécanisme. Consignez les procédures non prises en charge avant d’élargir le pilote.

Si le déploiement change le fournisseur des utilisateurs actuels, testez sur chaque client pris en charge une nouvelle conversation et une conversation créée avant le changement. Notez si les utilisateurs peuvent consulter la conversation existante, la poursuivre ou créer une branche à partir de celle-ci. Fournissez-leur une procédure de récupération pour chaque opération bloquée. Ne partez pas du principe que le changement de fournisseur par défaut entraîne la migration de l’historique des conversations.

Une fois ces vérifications réussies, préparez les informations à transmettre aux développeurs.

Distribuer la configuration

Pour que tous les postes se connectent de la même manière, distribuez l’URL de base de la passerelle, l’identifiant du fournisseur, l’alias de modèle approuvé et les paramètres d’authentification.

Éléments à distribuer

Pour OAuth natif de la passerelle, distribuez la table du fournisseur et la table [model_providers.<id>.gateway_oauth] décrites dans le guide de connexion, avec les valeurs d’enregistrement recueillies précédemment. Conservez requires_openai_auth = false et omettez env_key, experimental_bearer_token et la table auth d’authentification par commande si OAuth est le seul moyen d’authentification auprès de la passerelle.

Pour un assistant d’authentification, distribuez le bloc config.toml suivant via la couche de configuration choisie. Utilisez un modèle reconnu par votre version de Codex ou fournissez le catalogue correspondant, comme indiqué plus haut. Installez le programme de récupération du jeton au chemin configuré pour la commande :

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

Pour utiliser une clé de test statique de courte durée, supprimez le bloc d’authentification, placez env_key = "CODEX_GATEWAY_API_KEY" dans [model_providers.enterprise-gateway] et définissez cette variable en dehors du fichier TOML. Ne combinez pas env_key avec l’authentification par commande.

Distribuer les paramètres par défaut et les paramètres imposés

Si vos utilisateurs ne se connectent pas à Codex avec ChatGPT, vous pouvez distribuer les paramètres de l’équipe depuis votre propre serveur. Codex récupère ces paramètres indépendamment du routage des requêtes vers les modèles.

Consultez l’ordre de priorité des configurations pour choisir où distribuer les paramètres par défaut. Pour les paramètres imposés et les charges utiles MDM sur macOS, consultez la section Configuration gérée.

Pour définir les paramètres par défaut à l’échelle d’une machine sous macOS ou Linux, utilisez /etc/codex/config.toml. Sous Windows, placez config.toml dans %ProgramData%\OpenAI\Codex\. Les utilisateurs et les profils peuvent remplacer ces valeurs par défaut. Les documents cités précisent quels paramètres peuvent être imposés et où placer les fichiers correspondants.

Distribuez séparément les exécutables des assistants et les fichiers de catalogue locaux auxquels la configuration fait référence.

Pour imposer l’URL d’un catalogue distant, placez la définition complète du fournisseur dans requirements.toml sous [model_providers.<id>]. Une définition imposée remplace la table du fournisseur correspondant dans la configuration ordinaire. Incluez donc son base_url, ses paramètres d’authentification et les autres champs requis. Utilisez model_provider comme paramètre imposé si vous devez également imposer le choix du fournisseur.

model_catalog_json indique le chemin d’un fichier JSON local. Si vous imposez ce paramètre via requirements.toml, seul le chemin est fixé. Vous devez distribuer le fichier séparément. Placez le catalogue à ce chemin absolu avant le démarrage de Codex.

Dans le fichier TOML, écrivez les chemins Windows sous leur forme absolue, après résolution des variables. Codex ne remplace pas %ProgramData% par sa valeur dans model_catalog_json ni dans la valeur de command pour l’authentification du fournisseur. Par exemple, utilisez les chemins suivants uniquement si votre déploiement a placé les fichiers à ces emplacements :

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

Une CLI exécutée dans WSL utilise les chemins Linux et la valeur de CODEX_HOME définie sous Linux. Elle n’hérite pas automatiquement de la configuration Windows native.

Distribuer les en-têtes de routage

Si votre passerelle achemine les requêtes en fonction de la configuration ou de l’outil, ajoutez les en-têtes qu’elle attend à la définition du fournisseur dans votre fichier requirements.toml géré. L’exemple suivant fournit un identifiant de configuration de routage et désigne Codex comme client :

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

Utilisez env_http_headers pour les valeurs d’en-tête fournies par l’environnement du client. Envoyez une requête de test et vérifiez la route sélectionnée dans les journaux de la passerelle. Pour connaître les options relatives aux en-têtes, consultez Fournisseurs de modèles personnalisés.

Transmettre les valeurs de configuration aux développeurs

Donnez aux développeurs une seule procédure de configuration, celle que vous avez testée lors du pilote. Communiquez les informations suivantes, même si vous distribuez la configuration de manière centralisée :

Pour les postes gérés, orientez les développeurs vers Vérifier s’il existe déjà une configuration. Pour une configuration manuelle, orientez-les vers Configurer le fournisseur.

Si ce déploiement change le fournisseur, joignez les instructions que vous avez testées pour les conversations existantes. Gardez la configuration précédente qui fonctionnait à la disposition du responsable du déploiement au cas où le pilote révélerait un problème.

Une configuration manuelle ne permet pas d’imposer des paramètres. Le fichier .codex/config.toml propre au projet ne peut pas remplacer les clés sensibles qui déterminent le routage vers le fournisseur ou le mode d’authentification.

Vérifier la configuration depuis le poste d’un développeur

Pour vérifier que le poste d’un développeur a bien reçu les paramètres distribués :

1. Vérifiez que le client approuvé ainsi que les éventuels assistants ou fichiers de catalogue requis sont installés. Redémarrez Codex et effectuez les étapes de connexion communiquées aux développeurs.
2. Vérifiez que le fournisseur et le modèle attendus sont actifs. Dans la CLI, utilisez /status. Si les paramètres effectifs diffèrent de ceux communiqués aux développeurs, utilisez /debug-config pour examiner les couches de configuration.
3. Exécutez le test rapide de la section Se connecter à une passerelle.
4. Posez une question complémentaire pour vérifier que l’échange se poursuit, puis recherchez la requête de ce développeur dans les journaux de la passerelle.

Élargissez l’accès une fois le pilote réussi pour chaque combinaison de client et de méthode d’authentification que vous prenez en charge. Conservez la configuration testée et les résultats avec vos instructions de déploiement pour pouvoir répéter les vérifications après une mise à jour du client, de la passerelle ou des règles appliquées.

Résoudre les problèmes de déploiement

À partir du problème observé, déterminez si vous devez intervenir sur la configuration, les identifiants ou la passerelle :

Réutiliser une passerelle déjà déployée

Si votre organisation utilise déjà Claude Code via une passerelle, vous pourrez peut-être réutiliser la passerelle, le chemin réseau, la journalisation et l’accès à Bedrock. Conservez la configuration existante qui fonctionne et ajoutez une route Responses pour Codex, un identifiant d’accès, des alias de modèles et un fichier config.toml. Les paramètres du client Claude et le contrat de /v1/messages ne configurent pas Codex.

Pour effectuer la migration en toute sécurité, suivez ces étapes dans l’ordre :

1. Recensez les éléments de la connexion Claude actuelle : URL de la passerelle, source des identifiants, en-têtes requis, alias des modèles, correspondances avec les profils Bedrock et canal de distribution géré.
2. Ajoutez en parallèle une route Responses pour Codex ainsi que les alias de modèles correspondants.
3. Choisissez OAuth natif de la passerelle, une clé API ou un assistant d’authentification et autorisez un utilisateur de test. Pour un identifiant statique, rendez-le accessible via env_key. Pour un assistant, implémentez et testez le contrat de récupération des jetons par commande de Codex.
4. Configurez le fournisseur pour ce développeur avec la méthode d’authentification choisie à l’étape 3. Pour un déploiement géré, adaptez la charge utile aux chemins et à l’ordre de priorité de Codex décrits dans Déployer une passerelle.
5. Effectuez le test de connexion rapide dans la CLI ou l’application de bureau qu’utilise réellement le développeur. Effectuez ensuite toutes les vérifications de la section Tester Codex via la passerelle concernant la transmission en continu, la poursuite des échanges, les appels d’outils, les erreurs, la journalisation et le routage des alias.
6. Une fois le test pilote réussi, distribuez la configuration aux autres développeurs.

Référence du catalogue de modèles

Créer un premier catalogue local avec un fichier models.json

Commencez par configurer et sélectionner votre fournisseur de passerelle sur la machine où vous exécutez Codex.

Enregistrez ce catalogue sous le nom models.json sur la machine qui exécute Codex. Remplacez gateway-model par l’identifiant exact du modèle accepté par votre passerelle. Le nom d’affichage est le libellé que les utilisateurs voient dans le sélecteur de modèles.

{
  "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": []
    }
  ]
}

Pour un exemple plus complet, consultez le catalogue de modèles de Codex.

Attribuez à model_catalog_json dans config.toml le chemin absolu du fichier. Redémarrez Codex, sélectionnez Gateway model et envoyez une requête. Vérifiez que la passerelle a reçu l’identifiant du modèle que vous avez indiqué dans slug.

Pour créer un alias d’un modèle livré avec Codex, copiez son entrée complète depuis le catalogue de votre version de Codex et modifiez ses champs slug et display_name. Si l’alias n’a pas de cible de migration, définissez upgrade sur null. Vous conservez ainsi la fenêtre de contexte, les options de raisonnement et les paramètres des outils du modèle.

Mettre un catalogue à la disposition des clients

Cette page s’adresse aux développeurs qui implémentent le format Codex Models. Ce format définit le catalogue de modèles qui alimente le sélecteur de modèles. Si vous développez un service d’inférence, par exemple une passerelle ou un service cloud, utilisez cette spécification pour que l’application de bureau et la CLI de Codex puissent découvrir vos modèles et utiliser leurs instructions ainsi que les paramètres de leurs fonctionnalités.

Si vous administrez Codex en entreprise et souhaitez contrôler le catalogue de modèles, consultez les instructions de configuration de model_catalog_url.

Pour prendre en charge ce format, implémentez un point de terminaison de catalogue qui exige une authentification. Récupérez auprès de votre fournisseur en amont les valeurs par défaut actuelles correspondant à la version de Codex à l’origine de la requête, appliquez vos personnalisations, puis renvoyez le catalogue obtenu.

Implémenter le point de terminaison du catalogue

Par défaut, le point de terminaison du catalogue se trouve au chemin /models, sous l’URL base_url du fournisseur. Par exemple, avec base_url = "https://gateway.example.com/v1", Codex envoie la requête suivante :

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

La découverte au chemin par défaut prend en charge l’authentification par commande et l’authentification via le backend de Codex, par exemple avec ChatGPT. Pour un fournisseur personnalisé qui utilise une clé API sans authentification par commande, définissez explicitement model_providers.<id>.model_catalog_url pour activer la découverte à distance. Une clé API seule ne déclenche pas la découverte au chemin par défaut.

Utilisez model_catalog_url pour indiquer l’URL complète du catalogue, par exemple https://gateway.example.com/codex/models. Cette URL peut aussi pointer vers le point de terminaison par défaut /v1/models. Codex utilise directement cette URL sans y ajouter /models. Pour la découverte par clé API, laissez features.api_key_model_discovery activé, comme il l’est par défaut. Les en-têtes personnalisés seuls ne permettent pas la découverte.

Codex transmet les informations d’authentification et les en-têtes configurés pour le fournisseur sélectionné. Il ajoute à l’URL client_version et les éventuels query_params du fournisseur. Hébergez le catalogue sur un service autorisé à recevoir ces identifiants.

Authentifiez l’appelant, récupérez les valeurs par défaut correspondantes en amont, appliquez vos personnalisations et renvoyez directement l’objet JSON ModelsResponse complet. Attribuez à chaque entrée un slug unique et non vide. Lorsqu’une URL est définie explicitement dans model_catalog_url, Codex refuse les redirections et les réponses de plus de 1 Mio. Continuez à contrôler les droits d’accès aux modèles pour chaque requête d’inférence.

Sur les clients qui utilisent ce point de terminaison, supprimez tout paramètre model_catalog_json qui s’applique. Le fichier local est prioritaire et empêche la récupération du catalogue distant.

Respecter le schéma du client

Lisez le paramètre de requête client_version dans la requête de catalogue. Codex transmet la version de sa CLI au format major.minor.patch, sans suffixe de préversion. Pour l’application de bureau, il s’agit de la version de la CLI intégrée.

Utilisez le tag rust-v<version> correspondant dans le dépôt public de Codex ou, pour une compilation personnalisée, le commit exact du code source. Les liens suivants pointent vers rust-v0.162.1. Sélectionnez la révision qui correspond à votre client :

• Consultez les types de réponse ModelsResponse et ModelInfo pour connaître le schéma.
• Consultez le fichier models.json livré avec Codex pour un exemple complet. Ce fichier contient les données du catalogue. Il ne s’agit pas d’un document JSON Schema.

Le fichier livré avec Codex reflète le catalogue au moment de la publication de cette version. Récupérez les valeurs par défaut actuelles avant de produire votre catalogue.

Récupérer les valeurs par défaut actuelles en amont

Les fournisseurs de cloud qui proposent des modèles OpenAI récupèrent leurs valeurs par défaut auprès d’OpenAI. Les passerelles lisent le catalogue de leur fournisseur de cloud ou de leur fournisseur en amont afin de conserver les paramètres des modèles déployés et leur disponibilité par compte et par région. Transmettez à chaque étape la version de Codex à l’origine de la requête et authentifiez-vous séparément auprès de chaque point de terminaison.

Pour récupérer les valeurs par défaut directement auprès d’OpenAI, appelez le point de terminaison des modèles Codex avec la même valeur de client_version. Par exemple, avec une clé API OpenAI :

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

Pour une intégration ChatGPT, utilisez le jeton d’accès ChatGPT de l’appelant et, le cas échéant, l’en-tête ChatGPT-Account-ID. Utilisez des identifiants autorisés pour le point de terminaison en amont. La clé API de votre passerelle ne permet pas de s’authentifier auprès d’OpenAI.

Analysez la réponse complète, y compris son tableau models de premier niveau. Ce point de terminaison renvoie des métadonnées Codex telles que les instructions, les paramètres de raisonnement par défaut, les paramètres des outils, les limites de contexte et les offres de service. Le point de terminaison public /v1/models ne fournit pas ce catalogue.

Actualisez ces valeurs par défaut même si la version de Codex n’a pas changé. Limitez la portée des requêtes à l’identité prévue en amont et respectez les directives de mise en cache des réponses : le catalogue peut dépendre des droits de l’appelant. Conservez vos personnalisations séparément pour pouvoir les réappliquer aux valeurs par défaut actualisées.

Appliquer les personnalisations du fournisseur

Modifiez les valeurs des champs en conservant la structure de réponse de la version utilisée :

• Ne conservez que les modèles que l’appelant est autorisé à utiliser. Associez chaque slug à une route d’inférence prise en charge et ajustez display_name, description ou priority. Pour un alias sans migration vers un autre modèle, attribuez à upgrade la valeur null.
• Pour les options de raisonnement, les limites de contexte, les modalités d’entrée et les offres de service, choisissez des valeurs prises en charge à la fois par le modèle et par la route. Choisissez les valeurs par défaut parmi les valeurs prises en charge. Pour une route sans offre de service, videz service_tiers et additional_speed_tiers, puis attribuez à default_service_tier la valeur null.
• Conservez les instructions et les paramètres d’outils fournis en amont, sauf si vous avez testé ceux qui les remplaceront. Les métadonnées n’ajoutent pas de fonctionnalités au modèle et n’accordent pas d’accès à l’inférence.

Si vous utilisez un alias de modèle sur la passerelle, consultez les instructions pour fournir les métadonnées du modèle. Testez le catalogue obtenu avec chaque version de Codex prise en charge.

Utiliser les types Rust publics

Utilisez les crates correspondant au même tag ou commit Git public que le schéma du client :

• Utilisez codex-protocol pour accéder à codex_protocol::openai_models::{ModelsResponse, ModelInfo}. Désérialisez la réponse avec serde_json::from_slice::<ModelsResponse>(), modifiez catalog.models, puis sérialisez l’objet complet avec serde_json::to_vec(). Cet objet gère les champs de compatibilité des instructions du modèle.
• Utilisez codex-models-manager::bundled_models_response() pour charger le catalogue statique livré avec cette révision sous la forme d’un objet ModelsResponse. Cette fonction ne récupère pas les valeurs par défaut actuelles en amont.

Documentation connexe

• Configurer le fournisseur
• MCP
• Plugins
• Configuration gérée