Note de l’auteur : ni Codex ni WorkBuddy n’a été conçu spécialement pour Claude. Les erreurs viennent presque toujours de la couche d’intégration. Cet article classe les messages d’erreur en trois catégories — point de terminaison, échanges avec les outils et blocs de réflexion — et associe chacun à sa solution.
Nous sommes nous-mêmes tombés dans le piège. Pour aller plus vite, nous avons d’abord appelé Claude via le protocole compatible OpenAI, autrement dit en le traitant comme un modèle OpenAI. Les conversations simples fonctionnaient, mais dès qu’un outil était appelé, une erreur apparaissait. Réessayer n’y changeait rien. Tout s’est mis à fonctionner lorsque nous sommes revenus au protocole natif Anthropic, avec /v1/messages.
Commencez par vérifier si vous êtes concerné : Codex affiche une erreur liée à wire_api dès le démarrage, WorkBuddy dialogue normalement mais renvoie une erreur 400 à l’appel d’un outil, ou encore les réponses sont inexplicablement vides ? Vous êtes probablement dans l’un des cas décrits ici.
- Le modèle lui-même n’est pas en cause : le problème vient de trois incompatibilités dans la couche d’intégration : point de terminaison, échanges avec les outils et blocs de réflexion.
- La 3e catégorie (blocs de réflexion et budget de sortie) est la plus simple à corriger : il suffit de modifier la façon dont le client lit la réponse et de régler
max_tokens. - La 2e catégorie (échanges avec les outils) est de difficulté intermédiaire : elle se corrige principalement à l’aide d’une couche de traduction ou d’une passerelle.
- La 1re catégorie (point de terminaison) est la plus délicate : il faut changer de client ou ajouter une passerelle de traduction.
La conclusion de l’article tient en cet ordre de préférence : protocole Anthropic natif > traduction en anthropic par une passerelle > chat compatible OpenAI. Pour commencer, utilisez le tableau ci-dessous pour déterminer à quelle catégorie appartient votre erreur.
Les 3 grandes causes d’erreur avec Claude dans Codex et WorkBuddy
Commençons par quelques termes. Responses, Messages et Chat Completions sont trois façons de passer commande : les cuisines préparent le même plat, mais le format du menu change. Codex commande uniquement avec Responses, tandis que Claude n’accepte que Messages et Chat Completions. Le bloc thinking sert de brouillon au modèle ; Anthropic vérifie que ce brouillon n’a pas été modifié.
| Catégorie | Mécanisme en bref | Qui doit corriger ? | Difficulté |
|---|---|---|---|
| 1. Endpoints incompatibles | Codex envoie uniquement des requêtes Responses, un format que Claude n’accepte pas | Changer d’outil ou de passerelle | La plus difficile |
| 2. Échanges d’outils incompatibles | Les identifiants, blocs de contenu ou blocs thinking sont modifiés lors de la traduction | Principalement la passerelle | Moyenne |
| 3. Bloc thinking et budget incompatibles | Le modèle réfléchit à chaque appel, mais le client lit toujours les résultats à l’ancienne | Le client | La plus simple |
Catégorie 1 : incompatibilité des endpoints lorsque Codex appelle Claude
À quoi ressemble l’erreur : Error loading config.toml: wire_api = "chat" is no longer supported. How to fix: set wire_api = "responses".
Cela signifie que wire_api = "chat" n’est plus pris en charge dans la configuration et doit être remplacé par responses.
Pourquoi : selon la documentation officielle de configuration de Codex, wire_api n’accepte désormais que la valeur responses. L’ancienne solution de repli qui consistait à définir wire_api sur chat ne fonctionne plus : les versions récentes de Codex signalent une erreur dès le chargement de la configuration. Même si le fournisseur concerné n’est pas utilisé, la commande codex login status ne peut pas non plus s’exécuter. De leur côté, les modèles Claude sur APIYI apiyi.com ne proposent que les endpoints anthropic et openai, et pas /v1/responses. Les formats ne correspondent donc pas et, sans traduction entre les deux, l’erreur est inévitable.
Comment corriger le problème :
1. Client : ouvrez ~/.codex/config.toml et supprimez les anciennes mentions de chat, comme indiqué dans le message d’erreur, pour que Codex puisse démarrer normalement.
2. Changer d’outil : si vous voulez simplement utiliser Claude pour coder, passez à Claude Code, qui utilise l’API Messages native.
3. Passerelle : si vous devez rester sur Codex, ajoutez une passerelle capable de traduire les requêtes Responses en requêtes Messages. Pour l’adresse du fournisseur, privilégiez l’endpoint natif d’Anthropic.
Critères de validation : codex login status s’exécute normalement. Si vous utilisez une passerelle, envoyez une instruction qui nécessite de lire un fichier : Codex doit pouvoir effectuer un appel d’outil complet.
Catégorie 2 : les échanges d’appels d’outils Claude ne correspondent pas
À quoi ressemble l’erreur :
– tool_use ids were found without tool_result blocks immediately after
– An assistant message with 'tool_calls' must be followed by tool messages...
– thinking or redacted_thinking blocks in the latest assistant message cannot be modified
– Invalid signature in thinking block. The block is bound to a different conversation.
La première indique qu’un bloc tool_use n’est pas immédiatement suivi du bloc tool_result correspondant. La deuxième signale le même type de problème au format Chat. La troisième indique que le bloc de raisonnement du tour précédent a été modifié. La quatrième signifie que la signature du bloc de raisonnement ne correspond pas à la conversation en cours.
Pourquoi : la couche de compatibilité doit convertir les blocs de contenu Claude — text, tool_use, tool_result et thinking — en tool_calls et role: tool, puis effectuer la conversion inverse. Une erreur d’identifiant, une fusion de blocs ou le déplacement d’un bloc thinking suffit à provoquer une erreur 400. Le format Responses dispose aussi d’un rôle developer, absent du format Messages : son contenu doit donc être intégré à system. Par ailleurs, claude-opus-5-5 n’accepte pas les anciennes pratiques suivantes : forcer tool_choice (any ou un outil précis), préremplir un message assistant (prefill), ou utiliser temperature / top_p / top_k.
Comment corriger le problème :
1. Passerelle : faites suivre chaque tool_use du tool_result portant le même identifiant, et placez le tool_result au début des blocs de contenu du message user.
2. Passerelle : renvoyez à l’identique le message assistant du tour précédent, y compris les blocs dont le champ thinking est vide ; intégrez le contenu developer à system.
3. Client : ne conservez que auto ou none pour tool_choice, et supprimez le prefill ainsi que les paramètres d’échantillonnage.
4. Client : si une erreur de signature s’est déjà produite, ouvrez directement une nouvelle session. Selon la FAQ officielle d’APIYI, ce type d’erreur peut parfois être présenté sous la forme Request rejected (429). Ce n’est pourtant pas une limitation de débit : les nouvelles tentatives avec temporisation progressive sont donc inutiles.
5. Changer d’outil : si le harness impose un tool_choice forcé et que vous ne pouvez pas le modifier, changez de client.
Pour diagnostiquer une erreur 400 similaire, consultez l’article sur l’erreur 400 de concurrence des appels d’outils dans Claude Code. Il explique comment repérer, étape par étape, les échecs de correspondance entre tool_use et tool_result.
Critères de validation : plusieurs tours consécutifs d’appels d’outils (lecture d’un fichier, modification, puis nouvelle lecture) ne provoquent plus d’erreur 400, et aucune erreur de signature n’apparaît dans la même session.
Catégorie 3 : incompatibilité entre les blocs de réflexion de Claude et le budget de sortie
À quoi ressemble l’erreur : "thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior. Vous pouvez aussi voir "thinking.type.disabled" is not supported for this model. Dans d’autres cas, aucune erreur ne s’affiche, mais la réponse est vide ou tronquée.
Pourquoi : claude-opus-5-5 réfléchit à chaque requête, et sa réponse peut commencer par un bloc thinking. Si le client lit content[0].text en se basant sur sa position, il obtient une valeur vide. Les tokens de réflexion sont facturés comme des tokens de sortie et comptent dans la limite max_tokens. Depuis cette génération, les commentaires entre les appels d’outils sont eux aussi placés dans des blocs thinking. Comme la valeur par défaut de display est omitted, la réponse peut sembler vide.
Comment corriger le problème :
1. Côté client : omettez le paramètre thinking ou utilisez thinking: {"type": "adaptive"}, puis supprimez budget_tokens.
2. Côté client : réglez la profondeur de réflexion avec output_config.effort. Les valeurs possibles sont low / medium / high / xhigh / max ; la valeur par défaut est medium.
3. Côté client : lors de la lecture de la réponse, recherchez le bloc text par son type plutôt que par sa position.
4. Côté client : prévoyez une valeur max_tokens suffisante pour la réflexion et le texte de la réponse. Pour voir les commentaires, définissez thinking.display sur summarized.
Pour bien comprendre ce nouveau mécanisme, consultez le guide d’Adaptive Thinking. Il explique comment passer de budget_tokens aux niveaux d’effort.
Critère de validation : envoyez plusieurs fois la même invite. Le texte de la réponse doit toujours être présent et aucune erreur liée à thinking.type ne doit réapparaître.
Tableau de correspondance rapide des erreurs Claude
| Mots-clés du message d’erreur | Catégorie | Vérification en 5 minutes | Si l’erreur persiste |
|---|---|---|---|
wire_api = "chat" is no longer supported |
Catégorie 1 | Vérifiez qu’il ne reste aucune mention de chat dans config.toml | Tutoriel Magpie |
tool_use ids were found without tool_result |
Catégorie 2 | Vérifiez l’ID et l’emplacement de tool_result | Erreur 400 tool use concurrency dans Claude Code |
must be followed by tool messages |
Catégorie 2 | Vérifiez si les requêtes passent par une couche de compatibilité Chat | Erreur 400 tool use concurrency dans Claude Code |
Invalid signature in thinking block |
Catégorie 2 | Ouvrez une nouvelle session et réessayez | Comprendre Adaptive Thinking |
thinking.type.enabled / réponse vide |
Catégorie 3 | Supprimez budget_tokens et utilisez type pour la lecture | Comprendre Adaptive Thinking |
| Les conversations simples fonctionnent, mais les appels d’outils échouent | Catégorie 2 | Vérifiez le protocole de connexion de WorkBuddy | WorkBuddy prend-il en charge les appels au format natif Claude ? |
Deux approches pour corriger les erreurs d’appel à Claude depuis Codex et WorkBuddy
| Approche | Pour qui ? | Priorité du protocole |
|---|---|---|
| A Revenir à un client natif | Pour ceux qui veulent simplement coder avec Claude | La plus élevée, sans perte liée à la traduction |
| B Ajouter une passerelle de traduction | Pour ceux qui doivent rester sur Codex ou WorkBuddy | En deuxième choix : renseignez anthropic comme adresse du fournisseur |
| Rester durablement sur chat compatible | Déconseillé | La plus faible : les appels d’outils et les blocs de raisonnement risquent de poser problème |
Approche A : si vous voulez utiliser Claude dans Codex, passez plutôt à Claude Code. Dans la configuration officielle des modèles WorkBuddy, seules les options /chat/completions et « protocole personnalisé » sont disponibles : il n’y a pas d’entrée native Anthropic. Ne comptez donc pas sur le raisonnement natif de Claude dans WorkBuddy. Pour en savoir plus, consultez WorkBuddy prend-il en charge les appels au format natif Claude ?. L’article explique pourquoi les conversations fonctionnent alors que les appels d’outils échouent, et comment contourner le problème.
Pour configurer une connexion directe dans WorkBuddy : allez dans « Paramètres → Modèle → Personnalisé », saisissez https://api.apiyi.com/v1 comme Base URL, claude-opus-5-5 comme nom de modèle, et utilisez la clé créée sur la page des jetons APIYI apiyi.com. L’URL doit s’arrêter à /v1 : n’y ajoutez pas /chat/completions vous-même.
Légende : vérifiez surtout que l’URL s’arrête à /v1, que le nom du modèle est claude-opus-5-5 et que l’option « protocole personnalisé » reste désactivée.
Approche B : si vous ajoutez une passerelle à Codex, conservez wire_api = "responses" côté Codex. La passerelle traduit ensuite les requêtes au format Messages avant de les transmettre. Dans WorkBuddy, faites pointer l’URL du modèle personnalisé vers la passerelle locale et renseignez l’endpoint natif Anthropic https://api.apiyi.com comme adresse du fournisseur pour les modèles Claude.
🎯 Conseil technique : une seule clé suffit pour tester à la fois l’endpoint Messages natif et l’endpoint chat compatible. Commencez par comparer les appels d’outils avec les deux protocoles à l’aide des crédits de test sur APIYI apiyi.com, puis choisissez l’approche qui vous convient.
Connecter Codex et WorkBuddy à Claude avec Magpie
Magpie est un outil open source communautaire sous licence MIT. Il lance une passerelle locale sur 127.0.0.1:3425 capable de convertir les requêtes entre OpenAI Chat, Responses et Anthropic Messages, ce qui comble précisément la lacune de la première catégorie. Vous pouvez tout configurer directement dans l’interface graphique de Magpie : renseignez la clé API et la Base URL, puis connectez Codex et WorkBuddy à la même passerelle, sans modifier les fichiers de configuration à la main. Retrouvez toutes les étapes dans le tutoriel Magpie, qui explique comment utiliser une seule passerelle pour accéder aux modèles depuis plusieurs agents.
- Page Fournisseurs : ajoutez la clé. APIYI se trouve dans le groupe « Proxy » ; vous pouvez aussi cliquer sur « + Fournisseur personnalisé » pour saisir les informations manuellement.
- Page Agents : sélectionnez claude-opus-5-5 pour Codex et pour WorkBuddy.
- Ouvrez une nouvelle session, sans reprendre l’historique d’une session existante.
Légende : vérifiez surtout que le fournisseur apparaît comme disponible dans le groupe « Proxy », que la Base URL correspond à l’adresse native Anthropic et que les deux interrupteurs sont activés sur la page Agents.
Prix des appels Claude et coût du cache
Les prix ci-dessous sont indiqués en dollars par million de tokens. Vérifiés le 28 octobre 2026 : consultez la liste des modèles de la plateforme pour connaître les modèles et les prix à jour.
| Modèle | Entrée | Sortie | Lecture du cache | Plateforme disponible |
|---|---|---|---|---|
| claude-opus-5-5 | $4 | $20 | $0.2 | APIYI apiyi.com |
| claude-sonnet-5-5 | $2 | $10 | $0.1 | APIYI apiyi.com |
| claude-haiku-5-5 | $0.1 | $0.5 | $0.01 | APIYI apiyi.com |
L’agent renvoie tout l’historique à chaque tour : les tokens de réflexion de claude-opus-5-5 sont donc facturés au tarif de sortie. Si la couche de traduction modifie l’ordre de system, des tools ou du préfixe, le point de contrôle cache_control devient invalide, ce qui augmente à la fois le coût et la latence. Si le taux d’accès au cache est anormal, consultez Le taux d’accès au cache Claude tombe à 0 (diagnostics) pour comprendre comment identifier la cause de l’invalidation du point de contrôle.
Risques et suspension de compte : à vos propres risques
Les passerelles comme Magpie sont des outils open source communautaires. Elles ne sont pas des composants officiels d’APIYI : nous ne les cautionnons pas et ne fournissons pas de support technique à leur sujet. Transmettre des requêtes via ces outils peut entraîner une limitation des requêtes, voire une suspension de votre compte par le service cible. Vous en assumez les conséquences. Nous vous conseillons de tester d’abord toute la chaîne avec un compte de test, puis d’envisager son utilisation avec un compte de production une fois que tout fonctionne correctement.
Dans ces cas, inutile de vous compliquer la vie
Si vous utilisez Claude dans Codex seulement de temps en temps, si votre entreprise ne vous autorise pas à installer des logiciels supplémentaires ou si vous avez uniquement besoin de Claude, inutile de mettre en place une passerelle. Il sera bien plus simple de changer de client pour utiliser Claude Code, ou de choisir dans Codex un modèle compatible nativement avec Responses.
Questions fréquentes (FAQ)
Q1 : Codex prend-il officiellement en charge Claude ?
Non. Codex utilise uniquement l’API Responses, et Claude ne propose pas ce type de point d’accès. Une couche de traduction est donc nécessaire.
Q2 : Peut-on utiliser Claude sur APIYI avec /v1/responses ?
Non. Sur APIYI apiyi.com, les modèles Claude ne proposent que les points d’accès anthropic et openai.
Q3 : Une erreur 429 signifie-t-elle que le débit est limité ?
Si le message d’erreur contient `Invalid signature in thinking block`, il ne s’agit pas d’une limitation de débit : la vérification de la signature du bloc de réflexion a échoué. Il suffit d’ouvrir une nouvelle session.
Q4 : WorkBuddy peut-il utiliser le protocole natif Anthropic ?
La configuration officielle ne propose pas d’accès natif à Anthropic. Il faut passer par une interface compatible OpenAI ou par une passerelle qui convertit les requêtes.
Q5 : Comment vérifier rapidement que le problème est résolu ?
Utilisez le crédit d’essai d’APIYI apiyi.com pour ouvrir une nouvelle session, lancez plusieurs appels d’outils à la suite et vérifiez que le corps de la réponse n’est pas vide.
Liste de vérification des erreurs Claude dans Codex et WorkBuddy
- La configuration de Codex ne contient plus aucune référence à chat.
- Les requêtes Claude passent par le protocole natif ou par une passerelle qui les traduit vers anthropic, et non par une interface compatible chat.
- Chaque tool_use est immédiatement suivi d’un tool_result avec le même id.
- Le bloc thinking du tour précédent est renvoyé tel quel, sans modification.
- Aucun tool_choice forcé, prefill ou paramètre d’échantillonnage n’est utilisé.
- La réponse est lue selon son type et
max_tokensréserve suffisamment de place pour la réflexion.
En résumé
Les erreurs rencontrées avec Claude dans Codex et WorkBuddy se répartissent généralement en trois catégories : les endpoints, les allers-retours d’appels d’outils et les blocs de raisonnement. Pour les corriger, commencez par ajuster la façon dont le client lit les réponses, puis corrigez la couche de traduction du protocole. En dernier recours, envisagez de changer de client ou d’ajouter une passerelle. Côté protocole, privilégiez le protocole Anthropic natif. Si ce n’est pas possible, utilisez une passerelle pour traduire les requêtes vers le protocole Anthropic, plutôt que de rester durablement sur la compatibilité chat. Nous recommandons d’utiliser la même clé sur APIYI apiyi.com pour comparer les résultats des différents protocoles.
📚 Références
- Référence de configuration de Codex : valeurs possibles de wire_api
- Lien :
developers.openai.com/codex/config-reference - Détail : confirme que wire_api ne prend actuellement en charge que responses
- Exemple d’erreur de chargement de configuration Codex
- Lien :
github.com/openai/codex/issues/41816 - Détail : source du message d’erreur wire_api
- Guide de migration vers Claude Opus 5.5
- Lien :
platform.claude.com/docs/en/models/opus-5-5/migration-guide - Détail : contraintes strictes sur thinking, tool_choice et les paramètres d’échantillonnage
- Dépannage des appels d’outils Anthropic
- Lien :
platform.claude.com/docs/en/agents-and-tools/tool-use/troubleshooting-tool-use - Détail : règles d’association entre tool_use et tool_result
- Configuration des modèles dans WorkBuddy
- Lien :
www.workbuddy.ai/docs/zh/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Model - Détail : accès aux modèles personnalisés et option d’activation du protocole personnalisé
- Dépôt Magpie
- Lien :
github.com/yetone/magpie - Détail : passerelle open source communautaire ; évaluez les risques avant de l’utiliser
Auteur : équipe technique APIYI
Échanges techniques : contactez-nous depuis la page d’accueil d’APIYI apiyi.com. Pour en savoir plus, consultez le centre de documentation docs.apiyi.com.
