Analyse post-mortem de trois récents problèmes de dégradation de la qualité de Claude

• D’août au début septembre, une dégradation de la qualité des réponses de Claude s’est produite en raison de trois bugs d’infrastructure
• Les principales causes étaient respectivement une erreur de routage de la fenêtre de contexte, une corruption de sortie et une erreur de non-compilation du top-k approximatif sur XLA:TPU
• Chaque bug s’est superposé aux autres sur différents matériels et chemins de déploiement, ce qui a rendu le diagnostic encore plus difficile
• Les raisons du retard dans la détection et la résolution incluaient des failles dans le processus de validation ainsi que des restrictions d’accès liées à la politique de confidentialité
• Anthropic cherche à prévenir des incidents similaires en renforçant l’évaluation et la supervision et en développant des outils de débogage plus rapides

---

Vue d’ensemble et contexte

• D’août au début septembre, des baisses intermittentes de la qualité des réponses de Claude ont été signalées
• Au départ, cela a été considéré comme une variation normale dans les retours utilisateurs, mais l’augmentation continue des signalements a déclenché une enquête
• Anthropic précise clairement que le problème n’était lié ni à la demande ni à la charge des serveurs, mais uniquement à des bugs d’infrastructure
• Claude est proposé à des millions d’utilisateurs via plusieurs plateformes (API, Amazon Bedrock, Google Vertex AI, etc.) et applique des critères de validation stricts pour garantir des résultats équivalents sur différents matériels comme AWS Trainium, les GPU NVIDIA et les TPU Google
• Cette analyse post-mortem explique les causes des bugs, les raisons des retards de diagnostic et de résolution, ainsi que les mesures mises en place pour éviter une récidive

Comment Claude est exploité à grande échelle

• Le service Claude maintient un déploiement mondial à travers plusieurs types de matériel (Trainium, GPU, TPU)
• Les critères d’équivalence d’implémentation pour garantir une qualité identique sur chaque plateforme sont stricts
• Lors de changements d’infrastructure, un processus de validation précis est nécessaire sur toutes les plateformes et configurations

Chronologie des principaux incidents

• 5 août : premier bug, affectant environ 0,8 % des requêtes Sonnet 4
• 25 et 26 août : déploiement des deuxième et troisième bugs, respectivement
• 29 août : un changement de load balancing a fortement augmenté le trafic concerné, ce qui a touché davantage d’utilisateurs
• Les symptômes de chaque bug se chevauchaient, rendant le diagnostic extrêmement difficile

Les trois bugs superposés et leur résolution

1. Erreur de routage de la fenêtre de contexte

• Le 5 août, certaines requêtes Sonnet 4 ont été mal routées vers des serveurs destinés à une fenêtre de contexte de 1M de tokens
• Après les changements de load balancing, jusqu’à 16 % des requêtes Sonnet 4 ont été affectées, avec aussi un impact limité sur Amazon Bedrock et Google Vertex AI
• Le mécanisme de routage étant "sticky", une fois qu’une connexion était établie vers un mauvais serveur, elle continuait ensuite à utiliser ce même serveur
• Résolution : amélioration de la logique de routage, patch appliqué à la plateforme d’Anthropic le 4 septembre, déployé sur Google Cloud jusqu’au 16 septembre, et déploiement progressif en cours sur Bedrock

2. Corruption de sortie (bug)

• Le 25 août, une mauvaise configuration a été appliquée aux serveurs TPU de l’API Claude, provoquant des erreurs lors de la génération de tokens
• Des caractères incohérents comme du thaï ou du chinois apparaissaient dans des réponses à des questions en anglais, et des erreurs de syntaxe manifestes étaient insérées dans le code
• Seuls Opus 4.1, Opus 4 et Sonnet 4 ont été affectés ; les plateformes tierces ne l’ont pas été
• Résolution : rollback du changement le 2 septembre et ajout au processus de déploiement de tests détectant les sorties contenant des caractères anormaux

3. Erreur de non-compilation du top-k approximatif sur XLA:TPU

• Le 25 août, un bug latent du compilateur XLA:TPU a été mis en évidence pendant l’amélioration de la méthode de sélection des tokens
• Claude Haiku 3.5, une partie de Sonnet 4 et Opus 3 ont été affectés
• Les plateformes tierces n’ont pas été touchées
• Résolution : rollback de Haiku 3.5 le 4 septembre et d’Opus 3 le 12 septembre ; Sonnet 4 n’a pas pu être reproduit directement mais a aussi été rollbacké par précaution
• En parallèle, Anthropic collabore avec l’équipe XLA:TPU pour corriger le bug du compilateur et passe à une méthode de top-k exacte

Analyse détaillée du bug du compilateur XLA

• Lors de la génération de tokens, Claude effectue un calcul de probabilité pour chaque candidat ainsi qu’un échantillonnage
• Les TPU fonctionnent dans un environnement distribué, où les calculs de probabilité des tokens doivent être synchronisés, ce qui ajoute de la complexité
• En décembre 2024, un problème a été découvert : à cause d’erreurs liées à l’usage d’une précision mixte bf16-32 bits, le token de probabilité maximale pouvait être omis ; un correctif temporaire avait alors été déployé
• Le 26 août, lors d’une refonte du code d’échantillonnage visant à résoudre la cause profonde, un bug plus profond a été révélé : dans certains cas, l’opération de top-k approximatif produisait des résultats complètement erronés
• Le correctif temporaire précédent avait masqué ce problème
• De plus, les symptômes du bug de l’opération de top-k approximatif variaient de manière irrégulière selon l’environnement d’exploitation et la taille des batchs
• Au lieu du top-k approximatif, l’équipe est récemment passée à un top-k exact, dont le coût en performance a fortement diminué, et a amélioré les principales opérations en les standardisant en fp32

Pourquoi la détection a été retardée

• Des procédures telles que des évaluations automatisées périodiques et des déploiements préalables sur un groupe restreint étaient déjà utilisées
• Ces incidents ont toutefois mis en évidence des failles du processus d’évaluation. Par exemple, certains tests détectaient mal les situations problématiques, et les politiques internes de protection de la vie privée (les ingénieurs ne pouvant pas accéder aux requêtes utilisateur détaillées) compliquaient une analyse rapide
• Les symptômes variaient selon les plateformes et les versions, rendant l’identification d’une cause unique difficile
• Même lorsque les signalements en ligne ont fortement augmenté, le lien avec un changement standard de load balancing n’a pas été compris immédiatement

Améliorations et mesures à venir

• Développement de tests d’évaluation plus sensibles et renforcement des évaluations automatisées capables de distinguer plus clairement les états corrompus des implémentations normales
• Extension des systèmes d’évaluation et de supervision à l’ensemble de l’environnement de production, avec par exemple des évaluations centrées sur l’exploitation réelle comme les erreurs de routage de fenêtre de contexte
• Mise en place de nouveaux outils de débogage plus rapides et plus précis, ainsi que d’une infrastructure et d’outils sur mesure permettant d’analyser rapidement les retours de la communauté tout en préservant la confidentialité
• Au-delà des évaluations internes, Anthropic souligne l’importance d’une collecte continue et fiable des retours utilisateurs : pour les erreurs ou bugs difficiles à prévoir, les signalements réels des utilisateurs jouent un rôle de signal crucial
• L’usage de la commande "/bug" ou de la fonction « thumbs down », ainsi que l’envoi par e-mail de méthodes d’évaluation de la qualité du modèle, sont activement encouragés

Explications complémentaires

• XLA:TPU est un compilateur qui convertit le code du langage d’optimisation de haut niveau XLA en instructions TPU
• En raison de la taille du modèle, celui-ci est réparti non pas sur une seule puce mais sur plusieurs, et des opérations comme le tri doivent être implémentées sous forme vectorisée
• L’opération de top-k approximatif est utilisée pour améliorer les performances, mais elle peut introduire de graves problèmes, comme l’omission du token ayant la probabilité la plus élevée
• Une méthode de top-k exacte est désormais utilisée, et de légers changements peuvent apparaître dans la manière dont les tokens proches du seuil top-p sont inclus. Selon les cas, les utilisateurs peuvent avoir à ajuster la valeur de top-p

[GN⁺]

Avis Hacker News

• Le point marquant que j’ai relevé récemment est l’absence de véritables tests unitaires. Même les tests du bug du compilateur XLA se limitaient apparemment à afficher la sortie, ce qui est loin de vrais tests unitaires exécutés dans un harness de test avec suivi de couverture. La réponse semble être de davantage s’appuyer sur les evals. Des tests unitaires complets pour l’ensemble d’un LLM sont irréalistes aujourd’hui, mais la plupart des bugs révélés jusqu’ici se situaient dans de petites parties déterministes du système. Par exemple, l’équilibrage de charge, le calcul des probabilités top-k, etc. sont tous des composants conçus comme n’importe quel autre logiciel et peuvent donc en principe être testés unitairement. Si nécessaire, un simple PRNG injectable devrait suffire. Les bugs d’optimisation non déterministes sont certes pénibles, mais j’ai déjà vu par le passé des suites de tests applicatifs classiques révéler des bugs de compilateur et de base de données. En exécutant beaucoup de tests en boucle dans le CI, même des événements rares peuvent finir par apparaître. Sur un projet personnel, j’exécute tous les tests unitaires en parallèle dans le même processus, et cette méthode m’a permis de détecter efficacement des problèmes rares de thread safety ou des deadlocks en base de données. Il y a quelques jours, dans un fil sur le lancement de Java, j’ai mentionné que si Java est perçu comme plus « enterprise » que Python, c’est notamment parce que le code y est écrit avec un fort accent sur les tests unitaires. Le besoin d’injection de dépendances pousse aussi à davantage d’abstractions. À l’inverse, dans la culture des langages de script, les tests sont souvent absents ou très superficiels (par exemple, ne vérifier que les types). J’ai eu la même impression en apprenant PyTorch : les tutoriels couvrent progressivement des sujets plus complexes, mais parlent très peu des tests ou de la structure du code. C’est une approche adaptée à la recherche ML, où l’objectif est d’améliorer les scores d’évaluation, mais beaucoup moins à des déploiements de production à grande échelle. Je me demande s’il ne faudrait pas davantage de profils SRE ou d’ingénieurs logiciels HA dans les labos d’IA. Personnellement, je doute qu’en production, pousser agressivement les evals soit la meilleure défense contre les bugs
  • J’ai déjà dû fournir à une IA des prompts très détaillés et des exemples pour qu’elle écrive les tests unitaires Python comme je le souhaitais. Je vois souvent aussi des assertions qui ne portent que sur les types. Ce que je veux, ce sont des assertions sur les valeurs elles-mêmes. L’IA a aussi tendance à tout mocker excessivement ; le mocking est utile, mais dans un test unitaire, plus on appelle le vrai code de bout en bout, plus on couvre les interactions du code et les risques liés aux interfaces. Or, les tests unitaires Python générés par l’IA s’obsèdent tellement sur le mocking qu’ils finissent souvent par ne vérifier qu’un code tautologique. Du coup, j’inclus activement dans mes prompts des avertissements contre l’abus de mocking et des exemples de tests minutieux. À noter que Python dispose aussi d’excellents outils pour écrire du code structuré avec injection de dépendances
• J’ai été surpris de lire dans l’article qu’Anthropic pouvait avoir un impact direct sur l’infrastructure AWS Bedrock. Cela irait aussi à l’encontre de la promesse initiale d’AWS. Je pense qu’il en va probablement de même pour Google Vertex AI, mais je ne l’ai pas encore vérifié côté conformité.

Je comprends l’idée que, pour des raisons internes de confidentialité et de sécurité, l’accès des ingénieurs aux interactions utilisateur avec Claude soit limité. Je suis aussi d’accord sur le fait que l’envoi direct de feedback par l’utilisateur reste le plus utile, ainsi que sur l’indication qu’on peut utiliser la commande /bug dans Claude Code. Si ce signalement permet aux ingénieurs d’examiner le contexte, j’aimerais toutefois que cette procédure soit expliquée très clairement du point de vue utilisateur (je ne suis pas utilisateur de Claude Code). L’incitation à utiliser le bouton « thumbs down » dans l’application Claude me préoccupe un peu. La plupart des utilisateurs ne considéreront probablement pas qu’un clic sur ce bouton a le même poids qu’un abandon de confidentialité

• (Employé d’Anthropic, à titre personnel)

Il est faux de dire qu’Anthropic gère directement l’infrastructure AWS Bedrock. Aujourd’hui, c’est AWS qui l’exploite directement. Concernant l’avertissement de confidentialité du bouton « thumbs down », la fenêtre modale indique : « En envoyant ce feedback, l’intégralité de la conversation en cours sera transmise à Anthropic et utilisée pour améliorer le modèle. » Je serais curieux de savoir comment rendre ce message plus clair encore

• Quand on clique sur « thumbs down », un message indique bien : « En envoyant ce feedback, l’intégralité de la conversation sera transmise à Anthropic », donc je trouve l’avertissement déjà assez clair
• Si un labo du niveau d’Anthropic partage à ce point les détails de son infrastructure, c’est que la situation doit être assez difficile. Le bug de précision côté FMA (multiply-accumulate) est particulièrement regrettable ; les problèmes numériques sont souvent extrêmement déroutants et restent encore hors de portée de l’IA. Dans une situation de pression extrême où des concurrents grignotent des parts de marché en temps réel, l’intervention humaine est inévitable, et il peut falloir des semaines pour identifier la cause
• L’explication dit qu’« un changement d’équilibrage de charge le 29 août a accidentellement envoyé davantage de requêtes à contexte court vers les serveurs de contexte 1M, et que pendant une heure le 31 août, 16 % des requêtes Sonnet 4 ont été affectées ». Cela donne l’impression que les serveurs 1M contexte ont en fait de moins bonnes performances sur les entrées à contexte court. Peut-être que cela vient de mécanismes spécifiques sur ces serveurs, comme la compression du cache KV, l’éviction ou le sparse attention ?
  • C’est dû au scaling de RoPE (rotary positional embeddings). La plupart des frameworks open source connus implémentent static YaRN, où le facteur d’échelle reste fixe quelle que soit la longueur d’entrée, ce qui peut pénaliser les performances sur les textes courts. Il vaut mieux n’ajouter rope_scaling que lorsqu’un long contexte est réellement nécessaire, et ajuster le facteur en fonction de la longueur moyenne d’entrée de l’application. Par exemple, autour de 520 k tokens, un facteur de 2.0 est préférable Source (page de présentation de Qwen3-Next-80B)
  • Le point clé de leur postmortem, c’est que pour deux des trois problèmes, la cause exacte n’a pas été trouvée. D’après ce que je comprends, ma requête peut actuellement partir sur l’un de trois chemins de code complètement différents, chacun avec sa propre stack et son propre tuning. Cette optimisation peut changer soudainement sans rapport avec une mise à niveau du modèle, donc quelque chose qui marchait hier peut casser aujourd’hui. Je trouve même frustrant de voir des gens féliciter ce type de postmortem
• Avec tout le respect dû à l’équipe Anthropic, la qualité de la page de statut de Claude devrait en interne déclencher une alerte rouge. Il y a eu 50 incidents en juillet, 40 en août et 21 en septembre. J’ai déjà vécu des situations où la moitié de ces chiffres suffisait à réorienter brutalement toute l’équipe vers l’uptime et la qualité. Malgré tout, Claude reste un excellent produit, donc je continue à payer. J’ai essayé l’API puis j’ai pris immédiatement l’abonnement Max. Ma productivité a explosé grâce à cela. Mais les dégradations de qualité répétées de ces dernières semaines me font hésiter à conserver l’abonnement. Je remercie l’entreprise d’avoir partagé honnêtement l’état des problèmes, mais du point de vue client, la frustration est réelle. À mon avis, les problèmes comme l’équilibrage de charge ne sont toujours ni entièrement détectés ni entièrement résolus. Concrètement, vers 12 h à l’Est / 9 h à l’Ouest, je sens nettement une baisse de qualité dans Claude Code. J’espère que l’équipe continuera à chercher et corriger ces problèmes. J’ai aussi rencontré beaucoup de bugs complexes en faisant tourner des modèles en local chez moi, donc je sais que ce n’est pas simple. Lien vers la page de statut
  • Je ne peux pas affirmer que Claude soit meilleur ou pire que d’autres entreprises, mais une chose est sûre : beaucoup de pages de statut mentent. En réalité, les pannes sont fréquentes, mais elles n’apparaissent souvent pas sur la page de statut. Aujourd’hui, c’est presque plus surprenant quand une entreprise signale honnêtement un problème. Personnellement, je n’ai pas subi de gros incident avec Claude, mais j’ai peut-être eu de la chance. De mon point de vue, Claude semble plutôt plus rigoureux que d’autres sur le reporting d’incidents. Bien sûr, c’est peut-être simplement un hasard
  • Ce qui est encore plus inquiétant, c’est que de nombreux petits incidents sont omis des pages de statut. Tous les fournisseurs d’IA font à peu près pareil. S’ils publiaient des graphiques de métriques comme la latence token par token en temps réel, les requêtes en échec ou le débit en tokens par seconde, ce serait probablement assez choquant. Les données d’OpenRouter montrent que l’uptime API est loin d’être excellent. Claude Code devient aussi parfois extrêmement lent, au point qu’il faut souvent interrompre manuellement puis relancer. C’est particulièrement marqué entre 16 h et 18 h au Royaume-Uni, quand l’Europe, la côte Est et la côte Ouest des États-Unis se chevauchent. Aujourd’hui encore, Gemini AI Studio a renvoyé des erreurs 503 pour surcharge du modèle, sans que la page de statut n’indique quoi que ce soit. Je me demande si Claude et d’autres ne pourraient pas lisser la demande via des tarifs moins chers en heures creuses. Cela dit, ce genre d’offre pourrait aussi être mal perçu d’un point de vue marketing. Par ailleurs, l’adoption des GPU GB200 semble avoir été bien plus lente que prévu, avec de nombreux défauts matériels et logiciels. Les problèmes de refroidissement liquide n’ont probablement pas aidé non plus (et en cas d’échec, les conséquences sont graves)
  • Le fait même de dire « je paie quand même parce que Claude est trop bon » est un signal important. À ce stade, la qualité de l’IA compte plus pour les clients — moi compris — que la fiabilité du service. Bien sûr, les fournisseurs devront se concentrer davantage sur la fiabilité à terme, mais pourquoi faudrait-il aujourd’hui la prioriser devant la qualité ?
  • La chute récente de qualité m’inquiète beaucoup. Heureusement, je n’utilise pas encore l’IA dans un service de production, mais pendant le développement, quand le modèle devient soudainement « plus bête », c’est très difficile à contourner. À ce stade, je me demande sincèrement si certains fournisseurs sur OpenRouter ne trichent pas discrètement sur la ressource de calcul — par exemple en réduisant subrepticement le contexte, en baissant la quantification ou en diminuant le nombre d’experts actifs
  • C’est précisément pour cela que certaines entreprises adoptent une stratégie consistant à minimiser le nombre d’incidents affichés sur leur page de statut. L’évaluation client se dégrade temporairement, mais avec le temps l’impact négatif s’efface. En revanche, une page de statut bien tenue laisse une trace claire des problèmes. À long terme, il est donc plus avantageux de dissimuler. En pratique, S3 a eu plusieurs pannes avec erreurs sans les rendre publiques, et personne n’en a vraiment fait un sujet. Les gens parlent beaucoup, mais dans leurs actes, ils récompensent ceux qui cachent. Tous les growth hackers de startup le savent déjà très bien
• Il est expliqué que le 25 août, une mauvaise configuration a été déployée sur les serveurs TPU de l’API Claude, provoquant des erreurs pendant la génération des tokens. Les bugs de code me sont familiers, mais comme les LLM ne sont pas écrits directement par des humains, plutôt issus d’un entraînement automatique à grande échelle, je me demande comment ce type de bug peut apparaître. Par exemple, quand un modèle glisse soudain « สวัสดี » (thaï) au milieu d’une requête en anglais, je me demande concrètement comment une telle anomalie peut être injectée au niveau structurel
  • Un LLM s’exécute au final grâce à du code écrit par des humains. À la dernière étape, le modèle produit une distribution de probabilité sur l’ensemble des tokens (un vocabulaire d’environ 200 k éléments). Ensuite, ce sont des humains qui décident comment choisir effectivement le token suivant. Par exemple, on peut toujours prendre le token le plus probable, ou choisir aléatoirement parmi les top-k pour augmenter la créativité. Pour traiter efficacement ce top-k sampling, on compile un kernel via XLA, et il semble qu’un bug dans ce kernel ait parfois permis de sélectionner des tokens hors du top-k
  • Un LLM produit une distribution de probabilité pour le token suivant, puis le résultat réel dépend de la méthode de sampling par exemple. Si, par exemple, on choisit « aléatoirement parmi les 4 tokens les plus probables » et qu’un opérateur (une inégalité) est erroné, on obtient le genre de phénomène décrit dans l’article
  • Entre l’utilisateur et les paramètres du modèle, il existe plusieurs couches de code écrites par des humains
  • Pour simplifier, il y a deux étapes : l’entraînement et l’inférence. L’entraînement est long et automatisé, mais l’inférence est une pile logicielle distincte qui s’exécute immédiatement quand l’utilisateur envoie son prompt. Cette stack reçoit en permanence des mises à jour d’optimisation de performance, et c’est dans ce processus que peuvent apparaître ce genre de problèmes liés à l’inférence
  • Les kernels d’IA effectuent des calculs en virgule flottante ; dans certaines plages numériques inhabituelles, une valeur qui ne devrait pas être négative peut le devenir. Pour des raisons de performance, on désactive parfois des vérifications comme le contrôle de dépassement, puis si une valeur négative surgit, elle peut être traitée comme un très grand nombre (un peu comme si demander l’indice -1 d’un tableau renvoyait son dernier élément)
• Je pense que réfléchir à rendre l’inférence LLM déterministe pourrait aider à traquer les problèmes. Un article récent soutient d’ailleurs que l’explication habituelle — « tout vient de l’ordre d’association des flottants » — n’est pas en réalité la cause centrale Présentation de l’article
  • Le trafic réseau et la charge machine sont intrinsèquement non déterministes. À court terme, un déterminisme complet (par exemple pour l’audit) n’est réaliste que pour des traitements batch peu sensibles aux coûts. En pratique, même Google Search ou le chargement des compteurs de recommandations sur les réseaux sociaux ne sont pas du tout déterministes. Dans les systèmes distribués, le conseil clé est le graceful degradation, c’est-à-dire le maintien partiel du service ; dans un système entièrement déterministe, ce type de réponse devient impossible
  • Une conception déterministe dégrade les performances. Au final, il reste surtout une approche de type « test de QI » consistant à créer un autre modèle pour surveiller et alerter sur la qualité du modèle existant
• Je comprends l’idée selon laquelle « sur Google Cloud Vertex AI, le mauvais routage entre le 27 août et le 16 septembre est resté inférieur à 0,0004 % ». En pratique, j’utilise Claude Code dans le cadre du travail avec ce compte et je n’ai jamais ressenti de baisse de qualité. Dans l’ensemble, même si ces bugs sont sérieux, ils m’ont semblé beaucoup plus rares que ce que laissent penser les retours en ligne. La période d’incident était en réalité concentrée pour l’essentiel sur une à deux semaines. La proportion de requêtes affectées restait aussi relativement faible par rapport au total
  • Mais l’article de l’entreprise dit aussi que « 30 % des utilisateurs de Claude Code ont été routés au moins une fois vers le mauvais serveur et ont subi une baisse de qualité de réponse ». Le routage est « sticky », donc une fois affecté au mauvais serveur, les requêtes suivantes continuent d’y être envoyées. Si 30 % des utilisateurs de Claude Code ont subi une baisse de qualité, c’est un bug énorme
  • Ces derniers temps, même lors de pannes mondiales, les entreprises ont souvent tendance à employer des formules euphémiques du type « une petite partie des utilisateurs a constaté une hausse des erreurs », puis à n’actualiser la page de statut qu’après validation du CTO, ce qui me rend peu enclin à leur faire confiance. Une entreprise qui communiquerait vraiment avec franchise aurait un vrai avantage sur le marché
• Dans les services LLM, le fait de les rendre déterministes pourrait aider à remonter les problèmes. On mentionne aussi un article récent montrant que les causes qu’on attribuait seulement à l’ordre d’association des opérations en floating point relèvent en réalité d’un ensemble plus large de facteurs de rupture du déterminisme. Lien vers l’article
• J’ai récemment constaté sur la conception de webapps que Claude provoquait un phénomène grave où du texte aléatoire s’affiche n’importe où dans le DOM. Cela semble se produire spécifiquement lorsqu’il est utilisé avec Svelte ; je ne sais pas si c’est lié aux phénomènes décrits ici, mais je n’avais jamais connu auparavant une dégradation de qualité aussi sévère
• J’aurais aimé que le billet inclue des cas d’échec concrets. Dans Claude Code, j’ai souvent eu des cas où tout s’arrêtait complètement après un appel d’outil, et je me demande si cela correspond à l’un des bugs mentionnés ici
  • Moi aussi, je rencontre de plus en plus le même problème depuis quelques jours. Je pense que c’est peut-être distinct des bugs mentionnés dans l’article (même si c’est toujours un bug), mais j’espère me tromper. La fréquence à laquelle je dois renvoyer des messages du type « Pourquoi vous êtes-vous arrêté ? Continuez. » a clairement augmenté