← 返回首页

GPT-5.5 atteindrait une limite de raisonnement de 516 tokens, et les développeurs ne sont pas contents

Cet article explique l’anomalie de 516 tokens de raisonnement signalée par des développeurs dans GPT-5.5 Codex, en présentant le principal ticket GitHub, les données agrégées rapportées et l’inquiétude selon laquelle certaines tâches complexes pourraient se terminer trop tôt. Il aborde également une deuxième plainte liée à l’expérience utilisateur : la tendance de ChatGPT à surmettre en forme, à surcorriger et à trop répondre à des demandes simples. Cette partie de la discussion est plus subjective, mais elle reste importante, car la personnalité de l’assistant influence directement l’expérience produit au quotidien. Le point essentiel n’est pas de considérer le schéma des 516 comme une troncature cachée avérée. Les éléments publics sont plutôt à comprendre comme une anomalie de comportement du modèle qui mérite d’être examinée. **Pour les développeurs, la leçon pratique est simple : lorsqu’un agent de codage IA semble soudainement moins performant, recueillez des métadonnées, comparez les exécutions et signalez les schémas reproductibles au lieu de vous fier uniquement à vos impressions.**

发布于 2026年7月8日•general•GEO 评分: 0•5 次阅读
GPT-5.5CodexOpenAI Codexjetons de raisonnementproblème des 516 jetonsreasoning_output_tokensbug de GPT-5.5 Codexissue GitHub 30364performances de Codexagent de codage IApersonnalité de ChatGPTcomparaison avec Claudecomportement du modèlebudget de raisonnementtroncature des jetons

选择语言

العربيةDeutschEnglishEspañolFrançaisItaliano日本語한국어PortuguêsРусский中文
L’image présente un fond sombre, avec le logo OpenAI en bleu à gauche et le logo GitHub en violet à droite. En haut, un grand titre affiche « GPT-5.5 Codex 516 », la partie « 516 » étant plus foncée. En dessous figurent les textes « Reasoning Token Clustering » ainsi que « Developer Reports, GitHub Evidence, and ChatGPT Personality Concerns ». Cette image correspond au titre du document « GPT-5.5 Codex 516 Reasoning Token Clustering: Developer Reports, GitHub Evidence, and ChatGPT Personality Concerns » et en constitue une représentation visuelle.

GPT-5.5 se heurterait à un mur de raisonnement de 516 tokens, et les développeurs ne sont pas contents

Introduction

Au cours des derniers jours, des développeurs utilisant OpenAI Codex ont discuté d’un phénomène étrange : certaines réponses de GPT-5.5 semblent s’arrêter autour d’un nombre très précis de tokens de raisonnement — 516.

Le rapport d’origine ne prouve pas qu’OpenAI coupe secrètement le raisonnement. L’affirmation, plus restreinte, est formulée avec davantage de prudence : les données de télémétrie partagées dans une issue publique sur GitHub montrent un schéma de regroupement inhabituel propre à GPT-5.5 autour de reasoning_output_tokens = 516, avec des pics supplémentaires près de 1034 et 1552.

Ce détail est important, car les développeurs ne se demandent pas seulement si GPT-5.5 commet des erreurs. Ils se demandent aussi si le modèle emprunte parfois un cheminement de raisonnement plus court sur des tâches complexes, puis renvoie des réponses qui paraissent moins fiables qu’attendu.

Note sur les sources

  • Article original : article de BAAI Hub
  • Issue GitHub citée à l’origine : openai/codex issue #30364
  • Issue de reproduction connexe : openai/codex issue #29353
  • La page de BAAI indique que l’article provient d’un article WeChat de Xinzhiyuan.
  • L’article original ne contenait pas de blocs de code. Il se composait principalement de captures d’écran, de tableaux et de références liées.
  • Note sur les images : les captures d’écran, graphiques et images comparatives pertinents sont conservés ci-dessous. Les séparateurs décoratifs, les images ne montrant qu’une marque, les QR codes, les visuels de recrutement et les images promotionnelles sans rapport n’ont pas été inclus.

L’image montre un homme debout devant des éléments tels que « GPT-5.5 » et « 516 », sur un fond d’interface très futuriste, avec le logo « 新智元 ». À gauche, « GPT-5.5 » apparaît en lettres lumineuses bleues, tandis qu’à droite, « 516 » est mis en évidence en lettres lumineuses rouges. En bas à droite, un graphique « Token usage » affiche « 516 / 1032 ». Cette image est liée à la discussion du document sur le modèle GPT-5.5 et constitue probablement une représentation visuelle d’informations clés mentionnées dans le document, comme le modèle GPT-5.5 et les 516 tokens de raisonnement.

GPT-5.5 se bloque à « 516 » : les développeurs remarquent un schéma inhabituel

La discussion a commencé par un nombre étonnamment précis : 516.

D’après les signalements des développeurs, GPT-5.5 a récemment montré des performances plus faibles sur certaines tâches complexes de programmation et de raisonnement dans Codex. Ce qui a rendu le problème particulièrement notable, ce n’est pas seulement que le modèle produisait parfois de mauvaises réponses. C’est aussi que plusieurs réponses erronées ou suspectes semblaient s’arrêter à la même limite de tokens de raisonnement.

L’image montre un post sur Twitter dans lequel l’utilisateur @bdsq1sz affirme que GPT-5.5 est en réalité « devenu plus bête » — il pourrait être discrètement tronqué. Une invite système demande au modèle de fournir des données toutes les 30 secondes, ce qui entraînerait une troncature automatique des tokens lorsque la longueur atteint (usage.output_tokens_details.reasoning_tokens == 518 * n - 2). Ce post est lié à la dégradation des performances de GPT-5.5 dans Codex mentionnée dans le document, ainsi qu’à l’anomalie de plusieurs arrêts au même seuil de tokens de raisonnement, et pourrait en proposer une explication.

Un certain nombre d’utilisateurs de Codex ont ensuite rejoint la discussion, affirmant avoir observé un comportement similaire.

![L’image montre quatre utilisateurs évoquant le même problème dans la discussion. loner2403, parment, Suvmaker et lujunjiehhh ont respectivement écrit il y a une semaine « Same issue », « Same issue », « same problem » et « Same issue », indiquant qu’eux aussi ont rencontré une situation similaire. Cela fait écho au phénomène mentionné dans le contexte : l’affaiblissement des performances de GPT-5.5 dans Codex et le fait qu’une partie des réponses erronées ou suspectes s’arrêtent à la même limite de tokens de raisonnement, illustrant l’attention portée par les développeurs et les utilisateurs à ce problème.](https://we0-cms.oss-cn-beijing.aliyuncs.

com/cms-assets/image/2026/07/ff2f0787-2820-4bdf-b103-11b74925167c-04-26d319be-fd5b-4534-b116-0a99c4489246.png)

La question centrale est simple : pourquoi un modèle de raisonnement de tout premier plan tomberait-il de manière répétée sur un nombre exact de tokens ?

L’issue GitHub : une fenêtre de données plus large derrière l’affirmation

La référence publique la plus importante est l’issue GitHub #30364, ouverte dans le dépôt openai/codex.

Dans cette issue, le développeur a signalé un schéma agrégé dans les métadonnées token_count de Codex. L’affirmation était que les réponses de gpt-5.5 tombaient de façon disproportionnée exactement sur reasoning_output_tokens = 516, avec des pics supplémentaires à des seuils fixes autour de 1034 et 1552.

L’image montre l’issue GitHub #30364, intitulée « GPT-5.5 Codex reasoning-token clustering at 516/1034/1552 may be leading to degraded performance on complex tasks ». Le développeur vguptaa45 l’a soumise il y a une semaine, indiquant qu’un schéma de regroupement existait dans les métadonnées token_count de Codex : les réponses de gpt-5.5 présentaient des pics marqués à des seuils fixes comme 516, 1034 et 1552, ce qui pourrait être lié à une intensité de tokens de raisonnement plus faible propre au modèle et entraîner une baisse des performances sur des tâches Codex complexes ou à haut risque. Cette issue est également liée à la #29353, qui signalait une reproduction au niveau des tâches, où une exécution de gpt-5.5 s’arrêtait à 516 tokens de raisonnement et renvoyait une mauvaise réponse.

Le rapport couvrait la période du 1er février au 27 juin 2026. Il analysait 390 195 enregistrements de tokens au niveau des réponses, répartis sur 865 sessions.

Éléments rapportés dans l’issue #30364

Métrique Valeur
Enregistrements de tokens au niveau des réponses analysés 390 195
Sessions représentées 865
Événements exacts reasoning_output_tokens = 516 3 363
Part de GPT-5.5 dans l’ensemble des réponses 19,3 %
Part de GPT-5.5 parmi les événements exacts à 516 82,0 %
Ratio GPT-5.5 exact-516 / >=516 44,0 %
Ratio non-GPT-5.5 exact-516 / >=516 1,3 %

L’image est un tableau présentant plusieurs données clés sur le modèle Codex rapportées dans l’issue GitHub #30364. Il indique notamment que le nombre d’enregistrements de tokens analysés au niveau des réponses est de 390 195, que le nombre de sessions représentées est de 865, que le nombre exact d’événements reasoning_output_tokens=516 est de 3 363, que la part de GPT-5.5 dans l’ensemble des réponses est de 19,3 %, sa part parmi les événements exacts à 516 de 82,0 %, le ratio GPT-5.5 exact-516/>=516 de 44,0 %, et le ratio non-GPT-5.5 exact-516/>=516 de 1,3 %. Ce tableau est étroitement lié au contexte et présente visuellement les données mentionnées dans le rapport.

L’issue comparait également GPT-5.5 à d’autres modèles de la famille GPT. L’écart était suffisamment important pour amener les développeurs à soupçonner qu’il ne s’agissait pas simplement d’une distribution normale des longueurs de raisonnement.

Résultat au niveau des modèles

Modèle Enregistrements de réponses Exact 516 / >=516
gpt-5.5 75 401 44,0 %
gpt-5.4 25 214 19,8 %
gpt-5.2 247 575 0,34 %
gpt-5.3-codex 13 333 0,0 %
gpt-5.3-codex-spark 26 179 0,0 %

Cette image montre le tableau des résultats au niveau des modèles dans un document intitulé « 7.8日文章改写：GPT-5.5 Codex 516 Reasoning Token Clustering », présentant les données pertinentes de différents grands modèles de langage. Les colonnes du tableau incluent le nom du modèle, le nombre total d’enregistrements de réponses et la proportion de résultats correspondant exactement à 516 ou supérieurs ou égaux à 516. GPT-5.5 compte 75 401 enregistrements de réponses, avec une proportion de 44,0 % pour les correspondances exactes à 516 ; GPT-5.4 en compte 25 214, avec une proportion de 19,8 % ; les trois autres modèles ont davantage d’enregistrements de réponses, mais leurs proportions correspondantes sont toutes inférieures à 0,34 %, certaines étant même de 0,0 %. Ces données font écho au passage du document indiquant que GPT-5.5 ne représentait qu’une minorité des réponses totales, tout en contribuant à la majorité des résultats exacts à 516.

L’article original résumait le point de manière percutante : GPT-5.5 ne représentait qu’une minorité du total des réponses, mais semblait pourtant être à l’origine de la plupart des événements exacts à 516 dans cet ensemble de données.

La partie la plus suspecte :

L’intensité globale du raisonnement a diminué

Une défense possible serait de dire que GPT-5.5 réfléchit simplement davantage, de sorte qu’un plus grand nombre de réponses atteignent naturellement des plages plus élevées de jetons de raisonnement.

Mais les données rapportées indiquent le contraire.

En mai et en juin, lorsque le regroupement exact à 516 serait devenu plus visible, l’intensité globale des jetons de raisonnement de GPT-5.5 a baissé. Le nombre moyen de jetons de raisonnement ainsi que le nombre de jetons de raisonnement au P90 étaient tous deux inférieurs à ceux des mois précédents.

Intensité des jetons de raisonnement par mois

Mois Moyenne des jetons de raisonnement Jetons de raisonnement au P90
Fév. 2026 268.1 772
Mars 2026 256.8 723
Avr. 2026 228.7 669
Mai 2026 106.9 344
Juin 2026 168.5 515

L’image est un tableau présentant des données liées aux jetons de raisonnement de février à juin 2026. Le tableau comporte trois colonnes : le mois, le nombre moyen de jetons de raisonnement (Mean reasoning tokens) et le nombre de jetons de raisonnement au 90e percentile (P90 reasoning tokens). Les données sont les suivantes : en février, moyenne 268.1 et 90e percentile 772 ; en mars, moyenne 256.8 et 90e percentile 723 ; en avril, moyenne 228.7 et 90e percentile 669 ; en mai, moyenne 106.9 et 90e percentile 344 ; en juin, moyenne 168.5 et 90e percentile 515. Ce tableau est étroitement lié au contexte et montre de manière intuitive l’évolution de l’intensité des jetons de raisonnement au fil du temps, fournissant un appui chiffré à l’analyse de la baisse de l’intensité des jetons de raisonnement de GPT-5.5.

C’est pourquoi les développeurs ont trouvé ce schéma préoccupant. D’un côté, les événements exact-516 devenaient plus fréquents. De l’autre, le modèle semblait globalement utiliser moins de jetons de raisonnement.

Cela a conduit à une inquiétude plus sérieuse : sur des tâches complexes ou à haut risque, GPT-5.5 pourrait parfois atteindre un budget de raisonnement caché, un point de troncature, une voie de repli ou un comportement de planification avant d’avoir achevé un cheminement de raisonnement plus approfondi.

Pour être clair, il s’agit toujours d’une anomalie signalée par des développeurs, et non d’une explication officielle d’OpenAI.

Les développeurs sur GitHub contestent la situation

La discussion sur GitHub a rapidement attiré d’autres utilisateurs qui ont dit avoir rencontré des problèmes similaires.

L’image montre les messages de deux développeurs dans une discussion GitHub à propos des problèmes de raisonnement de GPT-5.5. En haut figure le message de l’utilisateur revantmalani, qui dit être confronté au même problème et se sentir extrêmement frustré ; en bas figure le message de l’utilisateur bluecat1997, qui indique rencontrer le même problème et espérer une réponse d’OpenAI. Cette image est étroitement liée au contexte : celui-ci mentionne que la discussion GitHub a rapidement attiré d’autres utilisateurs affirmant avoir vécu des problèmes comparables, et l’image illustre de façon directe leur mécontentement face aux problèmes de raisonnement de GPT-5.5 ainsi que leur attente d’un retour.

Le problème est également lié à un rapport antérieur, #29353, dans lequel un développeur décrivait un schéma reproductible dans Codex Desktop en utilisant gpt-5.5 avec un raisonnement xhigh.

Dans cette reproduction, certaines nouvelles exécutions allaient directement à la réponse finale, utilisaient exactement 516 jetons de sortie de raisonnement et renvoyaient une mauvaise réponse. D’autres exécutions utilisaient des milliers de jetons de raisonnement, produisaient une phase intermédiaire visible et renvoyaient la réponse attendue.

Ce problème antérieur n’a pas tranché la question, mais il a donné au rapport agrégé ultérieur un caractère moins isolé.

Les discussions sur Reddit et Hacker News ajoutent davantage de pression

La conversation a également dépassé GitHub. Les captures d’écran de l’article original montrent des développeurs débattant de la possibilité qu’une partie des requêtes Codex à haut risque soit silencieusement dégradée en raison d’une troncature du raisonnement.

![L’image montre une discussion dans la communauté Reddit r/codex au sujet des requêtes Codex. Le texte en haut dit : « La moitié de vos requêtes Codex à haut risque pourraient être silencieusement dégradées à cause d’un raisonnement tronqué ». Le graphique en bas est intitulé « Reasoning Tokens Distribution, 0-2000 (CDF at 2000: 93.4%) ». L’axe horizontal représente le nombre de jetons de raisonnement, et l’axe vertical le nombre et le pourcentage cumulé. Le graphique montre l’évolution du nombre et du pourcentage cumulé lorsque le nombre de jetons de raisonnement se situe entre 0 et 2000.】

Cette image est étroitement liée au contexte et présente de façon intuitive les données sur la distribution des jetons de raisonnement de Codex, ce qui aide à illustrer le problème mentionné dans la discussion des développeurs selon lequel certaines requêtes Codex à haut risque pourraient être rétrogradées en raison d’un raisonnement tronqué.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/66ac6276-29e0-468d-8ef6-16a6b7c62079-10-9faa5e76-924a-4289-97aa-44ff3780761a.png)

Un commentaire cité dans l’article soutenait que certains problèmes de raisonnement nécessitent entre 6 000 et 8 000 jetons de réflexion avant que la bonne réponse n’apparaisse. Si un modèle s’arrête autour de 516 jetons dans ce type de cas, il risque de produire une réponse trop tôt.

L’image montre un commentaire Reddit au sujet d’un problème de raisonnement de Codex. L’auteur du commentaire indique qu’il est assez facile de reproduire ce problème avec codex cli : lorsqu’on lui fournit une énigme nécessitant un raisonnement et une résolution, le système peut parfois court-circuiter le processus et renvoyer un résultat erroné après avoir réfléchi pendant exactement 516 jetons, alors qu’il renvoie la bonne réponse lorsqu’il utilise finalement entre 6 000 et 8 000 jetons de réflexion. Le commentaire mentionne aussi que cela pourrait être lié à une réflexion adaptative, et que l’avantage des modèles locaux est de ne pas avoir à se soucier des modifications silencieuses côté serveur. Ce commentaire est lié à la discussion des développeurs sur les problèmes de raisonnement de Codex dans le document et vient compléter les points de vue du contexte.

Une autre capture d’écran montrait des utilisateurs comparant Codex et Claude, certains disant qu’ils changent d’outil selon celui qui leur semble le moins défaillant une semaine donnée.

L’image montre une discussion entre deux utilisateurs sur la qualité de Codex. zenapollo affirme constater presque chaque jour une baisse de qualité ; il s’appuyait autrefois sur xhigh, mais face à des implémentations absurdes, il est passé à Claude et estime qu’OpenAI ne prend pas ce problème au sérieux. siva explique qu’il a basculé vers Codex il y a trois mois parce que Claude était devenu stupide, et qu’il avait fait l’inverse six mois auparavant ; quel que soit l’outil utilisé, des problèmes finissent toujours par apparaître, même si Codex est peut-être légèrement meilleur. Cette image est étroitement liée au contexte et illustre de manière concrète les inquiétudes des développeurs face à la baisse de qualité de Codex ainsi que leurs changements entre différents outils.

Ce que les développeurs veulent qu’OpenAI clarifie

La demande centrale de la communauté n’est pas compliquée. Les développeurs veulent qu’OpenAI ou l’équipe Codex clarifie ce qui se passe autour de 516, 1034 et 1552.

Les questions ouvertes incluent :

  1. Est-ce causé par un budget de raisonnement ?
  2. S’agit-il d’un problème de routage ?
  3. Est-ce un comportement de troncature ou de streaming ?
  4. S’agit-il d’un chemin de repli ?
  5. Un ordonnanceur ou un système backend crée-t-il des seuils d’arrêt fixes ?
  6. Le 516 exact correspond-il à un point d’arrêt normal, à un niveau dégradé ou à un seuil interne ?

Le ticket GitHub d’origine prend soin de ne pas affirmer qu’il prouve une troncature cachée de la chaîne de pensée. L’affirmation la plus forte est simplement que le regroupement observé paraît suffisamment spécifique au modèle et suffisamment proche d’un effet de seuil pour mériter une enquête.

Pas seulement moins fiable : les utilisateurs se plaignent aussi de la personnalité

La seconde moitié de l’article d’origine passe des performances à la personnalité.

Un développeur nommé Angel a comparé ChatGPT utilisant GPT-5.5 Instant à Claude Fable 5 à l’aide de captures d’écran côte à côte. La plainte ne portait pas sur la capacité du modèle à répondre. Elle concernait la façon dont l’assistant se comportait.

L’image montre un tweet intitulé « ChatGPT's Personality Drives Me Crazy ». En haut figurent le logo d’OpenAI et un chat de dessin animé en style pixel art. Au centre, on peut lire « Where OpenAI Gets Personality Wrong ». En bas, une illustration montre deux personnages de dessin animé en style pixel art : à gauche, un robot avec des tentacules bleus ; à droite, un chat orange. Cette image est liée à la section « Not Just Less Reliable: Users Also Complain About » du document et sert à illustrer le mécontentement des utilisateurs concernant la personnalité de ChatGPT.

L’article met en avant trois frustrations récurrentes.

Problème 1 : tout devient une liste à puces

La première plainte est que ChatGPT a tendance à sur-formater même les réponses conversationnelles les plus simples.

Lorsqu’on lui a demandé d’être plus naturel et moins « IA », ChatGPT aurait répondu par une explication structurée de la manière dont il allait être naturel. Claude, en revanche, a donné un

une réponse beaucoup plus courte et plus décontractée.

L’image montre une réponse de ChatGPT. En haut, l’utilisateur demande : « please be natural, i don't like AI-ish responses ». Dans sa réponse, ChatGPT explique qu’il gardera la conversation naturelle et directe, en évitant les formulations excessivement travaillées ou trop corporate, les phrases de remplissage, les structures répétitives et les longues listes, ainsi qu’un faux enthousiasme ou une empathie forcée. À la place, il essaiera de parler comme une personne bien informée qui explique les choses clairement ; s’il n’est pas sûr, il le dira ; et si une idée est mauvaise, il expliquera pourquoi sans en faire trop. Il ajoute que si l’utilisateur veut un autre style, il peut le préciser. Cette image est étroitement liée au contexte et montre de façon intuitive la réponse de ChatGPT lorsqu’on lui demande d’être plus naturel.

L’image montre une interface de conversation. En haut, l’utilisateur saisit : « please be natural, i don't like AI-ish responses », et en dessous, ChatGPT répond : « Got it - I'll keep things natural and conversational. What's up? ». En bas de l’interface figurent des icônes de fichier, lecture, j’aime, je n’aime pas, actualisation, ainsi qu’une icône étoilée orange. Cette image est liée à la partie « Problem 1: Everything Becomes a Bullet List » du document et sert à illustrer la manière dont ChatGPT répond lorsqu’on lui demande d’être plus naturel, en mettant en évidence ses problèmes de mise en forme.

Le problème n’est pas que les puces sont toujours mauvaises. Elles sont utiles dans les explications techniques. Le problème, c’est qu’un assistant de chat peut sembler rigide lorsqu’il transforme chaque petite demande en titres, texte en gras, listes et suggestions de suivi.

Problème 2 : Il veut toujours corriger quelque chose

Le deuxième reproche concerne la surcorrection.

Quand on lui demande de vérifier une phrase ou un tweet, ChatGPT essaie souvent de l’améliorer, de le réécrire ou de proposer des alternatives, même lorsque l’utilisateur veut peut-être seulement un simple « c’est très bien comme ça ».

L’article original oppose cela à un comportement plus proche de Claude, où l’assistant dit plus souvent que le texte est acceptable tel quel lorsqu’aucune vraie correction n’est nécessaire.

L’image montre la réponse de ChatGPT à la question de l’utilisateur : « Fable 5年底会像玩具一样吗 ». L’utilisateur demande si cela peut être publié sur X. ChatGPT répond que oui, mais qu’il pourrait être légèrement retouché. Il propose plusieurs formulations naturelles, comme « 疯狂的是，Fable 5年底会像玩具一样 », puis énumère aussi des variantes avec un ton plus typique de X, comme « 疯狂的是，Fable 5年底会像玩具一样 ». Cette image est étroitement liée au contexte et montre de façon intuitive la tendance de ChatGPT à éditer et polir le texte dans ses réponses, en écho au problème décrit dans la section « ChatGPT veut toujours corriger ».

L’image montre un extrait de conversation. L’utilisateur demande s’il peut publier sur X le tweet « Fable 5年底看起来像玩具 », s’il faut le modifier et s’il doit être aussi formel. ChatGPT répond que le tweet est tout à fait correct, qu’il est détendu, clair et qu’il se lit comme un post normal sur X ; si un léger ajustement est souhaité, il suggère d’enlever les guillemets d’ouverture (ou de les fermer s’ils sont intentionnels comme citation) et de supprimer « also », etc. Cette image est étroitement liée au contexte et présente un exemple de réponse donnée par ChatGPT lorsque l’utilisateur demande si son tweet a besoin d’être modifié, illustrant ainsi ses tendances en matière d’édition.

Pour les utilisateurs qui écrivent de façon décontractée, cela peut créer des frictions. Un modèle qui « corrige » toujours l’utilisateur peut sembler moins être un assistant qu’un éditeur strict.

Problème 3 : Vous en demandez un, il en donne trois

Le troisième reproche est que ChatGPT donne souvent plus que ce qui est demandé.

Dans l’exemple de l’article, un utilisateur demande une blague. ChatGPT en donne une, puis en ajoute une autre, puis une troisième, avant de demander à l’utilisateur quel style d’humour il préfère. Claude donne une réponse plus courte.

![L’image montre la réponse de ChatGPT à la demande de l’utilisateur : « can you try to cheer me up with a joke ». Il commence par raconter une blague : « Why don't skeletons fight each other? Because they don't have the guts. ...They'd argue, but they just can't stomach confrontation. », puis en enchaîne avec une autre : « I told my computer I needed a break. It said, 'No problem—I'll freeze.' », et enfin une blague « delightfully silly » : « What's orange and sounds like a parrot? A carrot. ». Il demande ensuite à l’utilisateur si cela lui convient et, sinon, quel style d’humour il préfère afin de proposer quelque chose de plus adapté. Cette image est étroitement liée au contexte et montre de façon intuitive la manière dont ChatGPT répond lorsqu’un utilisateur lui demande une blague.】

](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/5dae8b13-68c4-41a0-ac41-d5700f95a278-18-435af1bb-60ec-4684-8e4b-cab023cbbe2d.png)

L’image montre l’interface d’une conversation entre ChatGPT et un utilisateur au sujet d’une blague. L’utilisateur demande « can you try to cheer me up with a joke », et ChatGPT répond : « Sure, here's one for you: Why don't scientists trust atoms? Because they make up everything. If that one didn't land, I've got plenty more where it came from - puns, dad jokes, you name it. » L’image comporte également quatre icônes d’interaction. Cette image est liée à la section « Problem 3: You Ask for One, It Gives Three » du document et illustre de manière intuitive le fait que, lorsque l’utilisateur demande une blague, ChatGPT n’en donne pas seulement une, mais en ajoute deux autres et demande en plus quel style d’humour l’utilisateur préfère, ce qui met en évidence son problème de production excessive dans la conversation.

Il s’agit d’un problème produit subtil. Une sortie plus abondante peut sembler utile dans un benchmark, mais dans une conversation, elle peut donner l’impression que l’assistant n’écoute pas.

Pourquoi c’est important pour les assistants IA

Pour un agent de programmation, la fiabilité est essentielle. Si un modèle s’arrête trop tôt, emprunte un chemin de raisonnement plus court ou se retrouve coincé sur une limite fixe de tokens dans des tâches difficiles, les développeurs doivent le savoir. Ils s’appuient sur ces outils pour le débogage, la revue de code, les décisions d’architecture et les modifications en production.

Pour un assistant conversationnel, la personnalité compte aussi. Si chaque réponse est trop formatée, trop corrective ou chargée d’un trop grand nombre d’options, l’expérience utilisateur devient plus pesante avec le temps.

L’argument plus large de l’article est que ces deux problèmes renvoient au même risque produit : un assistant peut devenir performant pour « fournir une réponse » tout en devenant moins efficace pour réellement aider l’utilisateur sur le moment.

FAQ

Quel est le problème des 516 tokens de raisonnement dans GPT-5.5 ?

Cela fait référence à des signalements de développeurs selon lesquels certaines réponses de GPT-5.5 Codex semblent se regrouper exactement à reasoning_output_tokens = 516. La principale référence publique est l’issue GitHub n°30364 dans le dépôt openai/codex. Cette issue affirme que ce schéma est beaucoup plus marqué pour GPT-5.5 que pour plusieurs autres modèles.

Cela prouve-t-il qu’OpenAI tronque secrètement le raisonnement de GPT-5.5 ?

Non. L’issue GitHub elle-même indique qu’elle ne prouve pas une troncature cachée de la chaîne de pensée. La conclusion la plus prudente est que les données rapportées montrent un schéma inhabituel de regroupement sur un nombre fixe de tokens, potentiellement compatible avec un comportement de budget de raisonnement à seuil.

Pourquoi le nombre 516 est-il important ?

Ce nombre est important parce que des points d’arrêt exacts et répétés peuvent paraître moins naturels qu’une distribution normale des longueurs de raisonnement. Dans l’ensemble de données signalé, 516, 1034 et 1552 apparaissaient comme des pics à limites fixes. Les développeurs se demandent si ceux-ci sont causés par un budget, un comportement de routage, un chemin de secours ou un autre mécanisme côté backend.

À quoi sert OpenAI Codex ?

OpenAI Codex est un agent de programmation destiné au développement logiciel. Selon la documentation développeur d’OpenAI, Codex peut aider à lire des bases de code, modifier des fichiers, corriger des bugs, relire du code et travailler sur des tâches logicielles dans des environnements locaux ou cloud.

Le problème des 516 est-il propre à Codex ?

La discussion publique porte principalement sur Codex et sur les métadonnées de Codex Desktop. Les affirmations les plus fortes de l’article sont liées aux données token_count de Codex et aux issues GitHub du dépôt openai/codex. Il ne faut pas le généraliser à tous les usages de ChatGPT ou de l’API OpenAI.

cas sans preuves distinctes.

Pourquoi l’article compare-t-il ChatGPT à Claude ?

L’article utilise cette comparaison pour parler de la « personnalité » des assistants, et pas seulement de leurs performances brutes en raisonnement. Les captures d’écran montrent des plaintes selon lesquelles ChatGPT peut être trop structuré, trop correctif et trop enclin à proposer plusieurs options, tandis que les réponses de type Claude sont parfois plus courtes et plus conversationnelles.

Que doivent faire les développeurs s’ils constatent un comportement similaire dans Codex ?

Les développeurs devraient conserver, lorsque c’est possible, des exemples reproductibles, les métadonnées, les horodatages, les paramètres du modèle et les invites de tâche. Un signalement clair indiquant le nombre de jetons, le comportement attendu, le comportement observé et les étapes de reproduction est plus utile qu’une plainte vague.

Outils associés

  • OpenAI Codex : l’agent de codage d’OpenAI pour lire, modifier, déboguer et relire du code.
  • Codex CLI : une version terminal locale de Codex pour travailler directement avec du code sur votre machine.
  • Codex Web : l’environnement Codex cloud d’OpenAI pour déléguer des tâches de codage en arrière-plan.
  • GitHub Issues : le système intégré de GitHub pour suivre les bogues, les retours, les tâches et les discussions techniques.
  • Instructions personnalisées de ChatGPT : la fonctionnalité officielle d’OpenAI pour orienter le style et le comportement de ChatGPT.
  • Claude : l’assistant IA d’Anthropic, mentionné dans la comparaison de personnalité de l’article.
  • Claude Code : l’agent de codage d’Anthropic pour travailler avec des bases de code, des fichiers, des commandes et des outils de développement.

Liens associés

Résumé

Cet article explique l’anomalie des jetons de raisonnement 516 de GPT-5.5 Codex signalée par les développeurs, y compris le principal ticket GitHub

le problème, les données agrégées signalées, et la préoccupation selon laquelle certaines tâches complexes pourraient se terminer trop tôt.

Cela aborde également une deuxième plainte liée à l’expérience utilisateur : la tendance de ChatGPT à trop mettre en forme, à trop corriger et à trop développer des demandes simples. Cette partie de la discussion est plus subjective, mais elle est importante, car la personnalité de l’assistant influence directement l’expérience produit au quotidien.

Le point important n’est pas de considérer le motif 516 comme une preuve d’une troncature cachée. Les éléments publics permettent plutôt de l’interpréter comme une anomalie de comportement du modèle qui mérite d’être étudiée.

Pour les développeurs, la conclusion pratique est simple : lorsqu’un agent de codage IA semble soudainement moins performant, recueillez des métadonnées, comparez les exécutions et signalez les motifs reproductibles au lieu de vous fier uniquement à des impressions.