Corriger GPT-5.6 introuvable dans Codex

Lorsque GPT-5.6 échoue dans Codex, l'erreur vous indique rarement quoi corriger. La clé peut ne pas exposer le modèle, la route /v1 peut être erronée ou une demande de réponses directe peut fonctionner tandis que le fournisseur rejette les métadonnées ajoutées par Codex. L’exécution à nouveau de la même commande reproduit généralement le symptôme ; à lui seul, il n’identifie pas la couche défaillante.

Ce kit gratuit teste ces possibilités couche par couche. Il vérifie les ID de modèle exacts, la sortie des réponses de base, un marqueur de texte SSE exact et un événement response.completed de terminal, ainsi que la fonction nommée avec des arguments JSON exacts. Il exécute ensuite Codex avec les paramètres de fournisseur temporaires à partir d'un répertoire de travail vide et écrit un rapport JSON nettoyé. Les contrôles directs n'envoient que des marqueurs fixes ; le test de fumée Codex laisse votre configuration existante inchangée. Le kit vérifie la compatibilité ; il ne mesure pas la qualité du modèle.

Faites correspondre l'erreur GPT-5.6 avant de modifier la configuration

Ne collez pas une erreur dans une solution de contournement de configuration aléatoire. Un message direct API 404, un avertissement de métadonnées de modèle Codex et un message de fournisseur cooling down décrivent différentes couches. Les vérifications ci-dessous préservent cette distinction.

Ce que prouve le kit

Les contrôles sont délibérément superposés :

1. GET /v1/models confirme que la clé peut voir chaque ID de modèle exact.
2. Un appel Responses minimal sans streaming confirme la génération de base et vérifie l’ID de modèle renvoyé.
3. Une vérification SSE nécessite un marqueur de texte exact et un événement terminal response.completed.
4. Une vérification de fonction stricte nécessite la fonction nommée et les arguments JSON exacts.
5. Une exécution isolée de codex exec teste le Codex CLI installé via le même fournisseur.

Passer une couche n'implique pas que la suivante passe. Cette séparation est la partie utile : si les vérifications directes de API réussissent et que seul codex_cli_smoke échoue, il est peu probable que la modification de la clé API ou de l'ID de modèle résolve le problème réel.

Exécutez-le sans toucher à votre configuration existante

Mettez check.mjs et le lanceur de votre shell dans le même répertoire. Dans Bash ou Zsh, lisez la clé sans mettre sa valeur littérale dans l'historique du 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

Sous 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

L'exécution par défaut teste la sortie des réponses de base sur Sol, Terra et Luna, puis le streaming, l'émission d'appel de fonction et Codex de bout en bout sur Sol. Cela représente cinq générations directes fixes plus un tour Codex isolé lorsque Codex est installé. L'utilisation du API peut être facturée même si le kit est gratuit.

Utilisez --full pour répéter les vérifications plus approfondies sur les trois modèles. Cela fait neuf générations directes et trois tours Codex. Les tentatives directes API et les limites de tentatives des deux fournisseurs Codex sont nulles ; le kit n'essaie pas de fabriquer un 429.. Si un modèle ignore l'instruction fixe sans outil et démarre une boucle d'outil, un tour Codex peut faire une autre demande de modèle et le rapport le marque comme échoué :

./run.sh --full

Pour tester un modèle sans appeler Codex :

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

La clé n'est acceptée que via une variable d'environnement et n'est jamais un argument de ligne de commande. Les commandes d'entrée silencieuses ci-dessus conservent leur valeur littérale en dehors de l'historique du shell ; comme toute variable d'environnement de processus, elle peut toujours être inspectée par des processus locaux avec une autorisation suffisante pendant qu'elle est définie. Avant d'écrire le rapport, le script rédige la clé exacte ainsi que les formulaires Bearer et sk-... courants de chaque champ de chaîne contrôlé par le fournisseur.

Ce que le rapport enregistre

Chaque rapport comprend la version du kit, l'horodatage UTC, l'origine du point de terminaison et le chemin de base, le système d'exploitation, l'architecture, les versions Node et Codex, les modèles sélectionnés, les deux valeurs de délai d'attente et les limites explicites de zéro tentative. En fonction de la couche et du résultat, les champs de vérification applicables incluent :

• ID de modèle demandés et signalés ;
• réussir, échouer ou ignorer le statut ;
• Statut HTTP et en-têtes de réponse sur liste blanche pour les ID de demande et les limites de débit ;
• l'ID de réponse et l'utilisation du jeton lorsque le point de terminaison les renvoie ;
• le temps écoulé et la raison précise de l'échec du contrat ou du saut ;
• une catégorie d'erreur normalisée sans la clé API ni le corps de réponse brut.

Le fichier de sortie est créé avec des autorisations de propriétaire uniquement sur les systèmes POSIX. Les ID de demande ne sont pas des informations d'identification, mais examinez le rapport avant de le partager, car ils peuvent aider un fournisseur à retracer une demande.

Le code de sortie 0 signifie que chaque contrôle exécuté est réussi. 1 signifie qu’au moins une vérification exécutée a échoué. 2 signifie que les arguments, l'environnement de clé, l'URL ou une autre condition préalable n'étaient pas valides. Une installation Codex manquante est signalée sous le nom de skip, et non déguisée en échec API.

Les faits vérifiés sur le GPT-5.6

OpenAI documente actuellement ces ID et rôles API exacts :

L’alias gpt-5.6 est actuellement acheminé vers gpt-5.6-sol. Pour le diagnostic, utilisez les ID explicites : un alias ajoute une question de routage dont le test de compatibilité n'a pas besoin.

Les trois pages de modèle actuelles répertorient toutes une fenêtre contextuelle 1,050,000 de jeton API, une entrée maximale 922,000, une sortie maximale 128,000 et une limite de connaissances 2026-02-16. Ils répertorient également la prise en charge des réponses, Chat Completions et Batch, ainsi que le streaming, les sorties structurées et les appels de fonctions. Consultez les pages principales pour Sol, Terra et Luna.

Il s'agit des limites du modèle API, et non d'une promesse que chaque configuration client Codex expose la fenêtre complète. Codex possède son propre catalogue de modèles, model_context_window, et un comportement de compactage automatique. Ce kit n'envoie pas d'invite d'un million de jetons et ne déduit pas une fenêtre Codex efficace à partir du titre API.

Une configuration minimale du fournisseur Codex

La configuration actuelle de Codex utilise un ~/.codex/config.toml au niveau utilisateur pour les fournisseurs personnalisés. La référence de configuration actuelle répertorie responses comme valeur wire_api prise en charge. Un exemple minimal de OmniaKey est :

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 et requires_openai_auth sont des modes d'authentification alternatifs. Documentation d'authentification Codex actuelle indique que requires_openai_auth = true oblige Codex à ignorer env_key ; ne l'ajoutez pas à ce bloc de fournisseur.

Sauvegardez une vraie configuration avant de la modifier :

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

Equivalent PowerShell :

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

Le vérificateur de compatibilité ne vous oblige pas à modifier ce fichier ou à utiliser les paramètres de son fournisseur. Son test de fumée Codex ignore la configuration utilisateur, crée un CODEX_HOME temporaire, transmet les paramètres du fournisseur uniquement à ce processus, utilise un répertoire de travail vide et un bac à sable en lecture seule, puis supprime le répertoire. Il transmet uniquement la clé ainsi qu'une liste autorisée de variables d'environnement d'exécution, de paramètres régionaux, de répertoire temporaire, de proxy et TLS ; le rapport enregistre leurs noms, jamais leurs valeurs.

Le sandboxing en lecture seule empêche les écritures, mais pas toutes les lectures possibles. L'invite fixe sans outil est cochée, mais il ne s'agit pas d'une limite de sécurité stricte. Utilisez --skip-codex ou exécutez le kit dans un conteneur isolé ou une VM si la machine contient des fichiers que le processus Codex ne doit pas pouvoir lire.

Consultez la référence de configuration Codex et le guide de l'agent de codage OmniaKey avant d'apporter des modifications permanentes. Pour prendre une décision concernant le produit plutôt que pour résoudre les problèmes, lisez la comparaison entre Claude Code et Codex.

Si Codex est déjà choisi et que la décision est Sol, Terra ou Luna, utilisez le guide du modèle GPT-5.6 pour Codex.

Pour plus d'informations sur la famille et les tarifs officiels du API, consultez la évaluation du GPT-5.6 ; ce kit reste axé sur le dépannage de compatibilité.

Lisez les échecs par couche, et non par conjecture

Ne regroupez pas 401 et 403 dans le même diagnostic. Un 401 pointe normalement vers l'authentification ; un 403 peut signifier qu'une identité valide ne dispose pas d'autorisation. De même, un 404 peut être un mauvais chemin de base /v1 ou un chemin valide avec un modèle indisponible.

Le [guide des erreurs] de OpenAI(https://developers.openai.com/api/docs/guides/error-codes) recommande de vérifier la forme des requêtes pour détecter les requêtes incorrectes, de réguler les appels en fonction des limites de débit et de réessayer brièvement les erreurs de serveur. Ce kit vous laisse intentionnellement les tentatives afin que le premier échec reste visible.

Le piège actuel du fournisseur personnalisé

Deux rapports Codex ouverts, #31870 et #31882, documentent les échecs GPT-5.6 via des fournisseurs Azure/personnalisés sur Codex 0.144.x. Dans les cas signalés, les appels de réponses directes ont réussi tandis que les requêtes Codex ont échoué avec des erreurs 400 mentionnant X-OpenAI-Internal-Codex-Responses-Lite ou l'espace de noms collaboration réservé.

Ces problèmes sont des rapports de terrain et non une preuve que chaque fournisseur personnalisé échoue. C'est exactement pourquoi le kit fonctionne directement et les couches Codex séparément.

Si votre rapport montre cette répartition :

1. Enregistrez codex_version, la catégorie d'erreur exacte et l'ID de la demande.
2. Mettez à niveau vers la dernière version stable de Codex et réexécutez la même version du kit.
3. Vérifiez si les deux problèmes sont toujours ouverts et si un responsable a publié un correctif.
4. Envoyez le rapport nettoyé à votre fournisseur ou à l'assistance Codex si l'échec persiste.

Le problème n° 31882 décrit un remplacement complet du catalogue de modèles qui désactive les métadonnées Responses-Lite et multi-agents. C'est fragile : le remplacement remplace les métadonnées du catalogue, peut dériver après une mise à niveau et désactiver le comportement sur lequel vous comptez. La version 1.0.0 de ce kit détecte les signatures d'échec signalées mais ne corrige délibérément pas Codex et ne recommande pas une rétrogradation silencieuse.

Ce que ce kit ne mesure pas

Il s'agit d'une sonde de compatibilité, pas d'une référence de qualité de modèle. Il ne compare pas la précision du codage, le comportement dans un contexte long, le taux de réussite du cache, la latence de production, le timing de vidage SSE progressif, le prix facturé, la saisie d'image, les outils hébergés, le travail multi-agents ou une boucle complète de continuation d'appel de fonction. Un rapport vert signifie que les contrats testés ont fonctionné une seule fois avec les versions enregistrées et le point final. Il ne prédit pas chaque charge de travail ni ne fournit une isolation du système de fichiers au niveau des processus.

Pour des raisons de reproductibilité, conservez le rapport généré et les fichiers exacts du kit. Vérifiez les téléchargements avec SHA256SUMS, réexécutez après un Codex ou un changement de fournisseur, et comparez les contrôles individuels plutôt que seulement le statut final.

Questions fréquemment posées

Pourquoi Codex indique-t-il que les métadonnées du modèle n'ont pas été trouvées ?

Codex n'a pas pu faire correspondre le modèle sélectionné aux métadonnées du catalogue et est revenu aux valeurs génériques. Vérifiez si une demande de réponses directes fonctionne avant de modifier les informations d'identification. Si seul Codex échoue, enregistrez la version Codex et exécutez la vérification isolée CLI.

Pourquoi est-ce que je reçois un modèle introuvable ou un 404 pour GPT-5.6 Sol ?

Confirmez que l'URL de base se termine par /v1, puis recherchez dans GET /v1/models l'ID minuscule exact gpt-5.6-sol. Une clé valide ne garantit pas l'accès à tous les modèles.

Pourquoi GPT-5.6 n'est-il pas disponible avec ma connexion ChatGPT Codex ?

Codex authentifié par ChatGPT et une clé API via un fournisseur personnalisé sont des chemins d'accès distincts. La disponibilité dans l’un ne prouve pas la disponibilité dans l’autre.

Dois-je réessayer en cas d'erreur de refroidissement de toutes les informations d'identification ?

Suivez le signal de nouvelle tentative ou de réinitialisation du fournisseur. Les tentatives immédiates répétées ne réparent pas un pool d’informations d’identification épuisé et peuvent ajouter une charge supplémentaire.

Quand dois-je exécuter le kit de compatibilité ?

Exécutez-le lorsque le message seul n'identifie pas si l'accès au modèle, le Responses API ou le Codex échoue. Conservez le rapport nettoyé lorsque vous avez besoin de l'assistance d'un fournisseur ou de Codex.

Sources vérifiées

• Utilisation de GPT-5.6
• Modèles GPT-5.6 dans Codex
• Page modèle GPT-5.6 Sol
• Page modèle GPT-5.6 Terra
• Page modèle GPT-5.6 Luna
• Référence de configuration Codex
• Authentification Codex pour les fournisseurs alternatifs
• Guide d'erreur OpenAI API
• Codex issue #31870 et #31882, tous deux ouverts lorsqu'ils sont cochés