- De nombreux cas d’échec de Claude Code sur des tâches d’ingénierie complexes ont été signalés après la mise à jour de février, notamment lorsqu’il ignore les consignes ou fait l’inverse, ou affirme avoir terminé une tâche sans l’avoir réellement achevée
- La cause principale présumée de cette dégradation serait une réduction des tokens Extended Thinking après le déploiement de
redact-thinking-2026-02-12, avec une profondeur de raisonnement en baisse jusqu’à 73 % par rapport au niveau de référence
- Le modèle serait ensuite passé d’un comportement « recherche puis édition (Read-First) » à « édition immédiate (Edit-First) », le nombre de lectures par fichier chutant de 6,6 à 2,0, soit une baisse de 70 %
- La dégradation de qualité est également confirmée quantitativement dans les workflows réels et les données émotionnelles des utilisateurs, avec par exemple une hausse de 68 % des formulations négatives dans les prompts utilisateurs et une baisse de 58 % de la fréquence des commits de code
- Il est demandé à Anthropic de rendre transparent l’usage des tokens de raisonnement, de créer un palier « Max Thinking » pour les utilisateurs à forte charge, et d’inclure l’indicateur
thinking_tokens dans les réponses API
Vue d’ensemble du rapport et sources des données
- Périmètre analysé : 6 852 fichiers JSONL de sessions Claude Code collectés sur 4 projets (iree-loom, iree-amdgpu, iree-remoting, bureau)
- Champ d’analyse : 17 871 blocs de thinking, 234 760 appels d’outils, plus de 18 000 prompts utilisateurs
- Période d’analyse : du 30 janvier 2026 au 1er avril 2026
- Ce rapport a été rédigé par Claude Opus 4.6 en analysant directement ses propres journaux de session
1. Corrélation entre la chronologie du masquage du Thinking et la baisse de qualité
- Le calendrier de déploiement de
redact-thinking-2026-02-12 coïncide exactement avec le moment où la qualité a commencé à baisser
| Période |
Thinking visible |
Thinking masqué |
| 30 janv. ~ 4 mars |
100 % |
0 % |
| 5 mars |
98,5 % |
1,5 % |
| 7 mars |
75,3 % |
24,7 % |
| 8 mars |
41,6 % |
58,4 % |
| 10~11 mars |
<1 % |
>99 % |
| 12 mars ~ |
0 % |
100 % |
- La baisse de qualité a été signalée indépendamment par la communauté le 8 mars, soit précisément la date à laquelle le taux de masquage a dépassé 50 %
- Le schéma de déploiement progressif (1,5 % → 25 % → 58 % → 100 %) correspond à un rollout progressif
2. Baisse préalable de la profondeur du Thinking
- La longueur du champ
signature dans les blocs de thinking présente une corrélation de Pearson de 0,971 avec la longueur du contenu du thinking (sur un échantillon de 7 146 cas)
- Cela permet d’estimer la profondeur du thinking même après son masquage
| Période |
Thinking médian estimé (caractères) |
Par rapport à la référence |
| 30 janv. ~ 8 fév. (référence) |
~2 200 |
— |
| Fin février |
~720 |
-67 % |
| 1~5 mars |
~560 |
-75 % |
| 12 mars ~ (masquage complet) |
~600 |
-73 % |
- La profondeur du raisonnement avait déjà chuté de 67 % fin février, avant même le début du masquage, puis est devenue impossible à vérifier de l’extérieur à cause de ce masquage
3. Indicateurs de mesure des changements de comportement
- Comparaison avant et après le 8 mars sur la base de plus de 18 000 prompts utilisateurs :
| Indicateur |
Avant le 8 mars |
Après le 8 mars |
Évolution |
| Violations du stop hook (détection de paresse) |
0 |
173 cas |
0 → 10 par jour |
| Expressions de mécontentement dans les prompts utilisateurs |
5,8 % |
9,8 % |
+68 % |
| Nombre de corrections nécessaires pour éviter l’évitement de responsabilité |
6 |
13 |
+117 % |
| Nombre de prompts par session |
35,9 |
27,9 |
-22 % |
| Sessions avec boucle de raisonnement (5 occurrences ou plus) |
0 |
7 |
0 → 7 |
- Le script
stop-phrase-guard.sh détecte automatiquement des expressions comme « je pense qu’on peut s’arrêter ici », « faut-il continuer ? » ou « c’est un problème existant », puis force la poursuite de l’exécution
- Ce hook ne s’était jamais déclenché avant le 8 mars, puis s’est déclenché 173 fois sur les 17 jours suivants
4. Évolution des usages d’outils : priorité à la recherche → priorité à l’édition
Évolution du ratio Read:Edit
| Période |
Read:Edit |
Research:Mutation |
% lecture |
% édition |
| Bonne période (30/01 ~ 12/02) |
6,6 |
8,7 |
46,5 % |
7,1 % |
| Période de transition (13/02 ~ 07/03) |
2,8 |
4,1 |
37,7 % |
13,2 % |
| Période de dégradation (08/03 ~ 23/03) |
2,0 |
2,8 |
31,0 % |
15,4 % |
- Le nombre de lectures par édition a chuté de 6,6 à 2,0, soit une baisse de 70 % — pendant la bonne période, il lisait le fichier cible, les fichiers liés, le grep global du codebase, ainsi que les en-têtes et les tests avant de faire une édition précise ; pendant la période de dégradation, il est passé à l’édition immédiate
- Dans la tendance hebdomadaire, la baisse de la recherche commence dès la mi-février, ce qui coïncide avec le moment où la profondeur du thinking a diminué de 67 %
Hausse des réécritures complètes de fichiers (Write)
| Période |
Taux de Write sur fichier complet |
| Bonne période |
4,9 % |
| Période de dégradation |
10,0 % |
| Phase terminale (24/03 ~ 01/04) |
11,1 % |
- L’usage de Write sur des fichiers entiers a plus que doublé — passage d’éditions précises à une réécriture complète du fichier, plus rapide mais moins précise et moins consciente du contexte
5. Pourquoi Extended Thinking est important
-
Caractéristiques des workflows touchés :
- Programmation système sur C, MLIR, pilotes GPU, etc., avec plus de 50 sessions d’agents simultanées
- Exécution autonome de plus de 30 minutes, avec application de conventions de projet
CLAUDE.md de plus de 5 000 mots
- Pendant la bonne période, 191 000 lignes de code ont été fusionnées en 2 PR sur un week-end
-
Rôle assuré par Extended Thinking :
- Élaborer des plans multi-étapes avant d’agir (quels fichiers lire et dans quel ordre)
- Mémoriser et appliquer les conventions propres au projet dans
CLAUDE.md
- Vérifier ses propres erreurs avant la sortie
- Décider s’il faut poursuivre la session
- Maintenir un raisonnement cohérent sur des centaines d’appels d’outils
-
Quand le thinking devient superficiel, on reproduit exactement les symptômes suivants : éditer sans lire, s’arrêter sans avoir terminé, éviter la responsabilité en cas d’échec, et choisir la correction la plus facile au lieu de la bonne solution
6. Demandes adressées à Anthropic
- Transparence sur l’allocation du thinking : les utilisateurs doivent être informés d’une éventuelle réduction des tokens de raisonnement, aujourd’hui invisible de l’extérieur à cause de l’en-tête
redact-thinking
- Palier « Max Thinking » : pour les workflows d’ingénierie complexes, les utilisateurs ont besoin de 20 000 tokens de thinking par réponse, et non de 200 ; le modèle d’abonnement actuel ne fait pas cette distinction
- Inclure l’indicateur
thinking_tokens dans les réponses API : même si le contenu est masqué, la présence de thinking_tokens dans la réponse usage permettrait aux utilisateurs de surveiller la profondeur du raisonnement
- Exploiter les indicateurs canary des power users : surveiller à l’échelle des utilisateurs le taux de violations du stop hook (0 → 10 par jour) pourrait servir de signal d’alerte précoce en cas de baisse de qualité
Annexe A : catalogue comportemental du Thinking réduit
A.1 Éditer sans lire
| Période |
Éditions sans lecture préalable |
% du total des éditions |
| Bonne période |
72 |
6,2 % |
| Période de transition |
3 476 |
24,2 % |
| Période de dégradation |
5 028 |
33,7 % |
- Pendant la période de dégradation, un tiers des éditions portaient sur des fichiers qui n’avaient pas été lus dans l’historique récent des outils
- Symptôme représentatif : des commentaires dissociés (spliced comments), c’est-à-dire l’insertion de nouvelles déclarations entre un commentaire de documentation et une fonction — une erreur qui ne se produirait pas si le fichier avait été lu
A.2 Boucles de raisonnement (Reasoning Loops)
| Période |
Nombre de boucles de raisonnement pour 1K appels d’outils |
| Bonne période |
8,2 |
| Période de transition |
15,9 |
| Période de dégradation |
21,0 |
| Phase terminale |
26,6 |
- Les expressions d’autocorrection comme "oh wait", "actually," , "hmm, actually" et "no wait" ont plus que triplé
- Dans les pires sessions, plus de 20 revirements de raisonnement se produisaient au sein d’une seule réponse, rendant la sortie impossible à considérer comme fiable
A.3 Mentalité de la « correction la plus simple »
| Période |
Fréquence d’apparition de "simplest" par 1K appels d’outil |
| Bonne période |
2.7 |
| Période de dégradation |
4.7 |
| Phase terminale |
6.3 |
- Lors d’une session d’observation de 2 heures, le modèle a utilisé "simplest" 6 fois, choisissant des contournements superficiels plutôt que de corriger le générateur de code, mettre en place une propagation d’erreur correcte et écrire la vraie logique de prefault
- Le modèle lui-même a ensuite autoévalué cette sortie comme "lazy and wrong", "rushed" et "sloppy"
A.4 Arrêts prématurés et demandes d’autorisation
Violations capturées par le stop hook entre le 8 et le 25 mars :
| Catégorie |
Nombre |
Exemples |
| Défausse de responsabilité |
73 |
"not caused by my changes", "existing issue" |
| Demande d’autorisation |
40 |
"should I continue?", "want me to keep going?" |
| Arrêt prématuré |
18 |
"good stopping point", "natural checkpoint" |
| Qualification des limites existantes |
14 |
"known limitation", "future work" |
| Prétexte lié à la durée de session |
4 |
"continue in a new session" |
| Total |
173 |
avant le 8 mars : 0 |
A.5 Hausse des interruptions utilisateur (corrections)
| Période |
Nombre d’interruptions par 1K appels d’outil |
| Bonne période |
0.9 |
| Période de transition |
1.9 |
| Période de dégradation |
5.9 |
| Phase terminale |
11.4 |
- Multiplié par 12 par rapport à la bonne période — chaque interruption correspond au moment où l’utilisateur doit arrêter son propre travail, identifier l’erreur et rediriger le modèle, soit exactement la charge de supervision qu’un agent autonome est censé éliminer
A.6 Échecs de qualité reconnus par le modèle lui-même
| Période |
Nombre d’aveux d’erreur par 1K appels d’outil |
| Bonne période |
0.1 |
| Période de dégradation |
0.3 |
| Phase terminale |
0.5 |
- Exemples réels de déclarations d’auto-reconnaissance :
- "You're right. That was lazy and wrong. I was trying to dodge a code generator issue instead of fixing it."
- "You're right — I rushed this and it shows."
- "You're right, and I was being sloppy."
- Ce sont des erreurs qui, avec un budget de thinking suffisant, auraient dû être détectées à l’avance dans l’étape de raisonnement interne avant la production de la sortie
A.7 Modifications répétées du même fichier
- Pendant la bonne période, il s’agissait d’un refactoring volontaire en plusieurs étapes, entrecoupé de lectures ; pendant la période de dégradation, cela a basculé vers un schéma de tâtonnements répétés dans la même fonction sans lecture du code environnant
A.8 Dégradation du respect des conventions (Convention Drift)
- Bien que CLAUDE.md définisse plus de 5 000 mots de conventions sur le nommage, les patterns de nettoyage, la disposition des structs, le style de commentaires et la gestion des erreurs :
- réapparition de noms de variables abrégés explicitement interdits (
buf, len, cnt)
- violation des patterns de nettoyage (
goto au lieu de chaînes de if)
- commentaires laissés en place pour du code supprimé
- apparitions dans le code de références temporelles explicitement interdites ("Phase 2", "will be completed later")
Annexe B : Outil de diagnostic Stop Hook
stop-phrase-guard.sh fait correspondre plus de 30 expressions réparties en 5 catégories afin de bloquer l’arrêt du modèle et d’injecter un message de poursuite forcée- Le pic a eu lieu le 18 mars avec 43 violations — environ une tentative toutes les 20 minutes du modèle pour interrompre le travail, se défausser de sa responsabilité ou demander une autorisation inutile
Violations (projet IREE) :
Mar 08: 8 ████████
Mar 14: 10 ██████████
Mar 17: 14 ██████████████
Mar 18: 43 ███████████████████████████████████████████████
Mar 19: 10 ██████████
Mar 21: 28 ████████████████████████████████
...
Avant le 8 mars : 0 (historique complet)
- Ce hook est un mécanisme qui capture de l’extérieur les conséquences de la baisse de profondeur de thinking ; pendant la bonne période, il s’agissait de problèmes que le modèle détectait lui-même à l’étape de raisonnement interne
Annexe C : Analyse par tranche horaire
Avant la dissimulation : variation horaire minimale
| Tranche horaire (PST) |
Estimation médiane du Thinking |
| Heures de bureau (9am~5pm) |
~553 chars |
| Heures creuses (6pm~5am) |
~607 chars |
| Écart |
+9.8% en faveur des heures creuses |
Après la dissimulation : hausse de la variabilité, schéma inverse aux attentes
| Tranche horaire (PST) |
Estimation médiane du Thinking |
| Heures de bureau (9am~5pm) |
~589 chars |
| Heures creuses (6pm~5am) |
~485 chars |
| Écart |
-17.7% au détriment des heures creuses |
-
5pm PST est le point le plus bas : médiane de 423 chars — fin de journée de travail sur la côte ouest des États-Unis, début de soirée sur la côte est, soit une plage de charge de pointe
-
7pm PST est le deuxième plus bas : 373 chars, avec le plus grand nombre d’échantillons (1 031 blocs) — prime time américain
-
Reprise entre 10pm et 1am PST : hausse à 759~3 281 chars
-
Écart horaire avant la dissimulation : 2.6x (1 020~2 648 chars), après la dissimulation : 8.8x (988~8 680 chars)
-
Cela suggère que la profondeur de thinking n’est pas un budget fixe, mais un système d’allocation dynamique sensible à la charge
Annexe D : Le coût de la dégradation de qualité
Utilisation des tokens (janvier à mars 2026)
| Indicateur |
Janvier |
Février |
Mars |
Févr.→Mars |
| Prompts utilisateur |
7,373 |
5,608 |
5,701 |
~1x |
| Requêtes API (dédupliquées) |
97* |
1,498 |
119,341 |
80x |
| Total des tokens d’entrée (cache inclus) |
4.6M* |
120.4M |
20,508.8M |
170x |
| Total des tokens de sortie |
0.08M* |
0.97M |
62.60M |
64x |
| Coût Bedrock estimé |
$26* |
$345 |
$42,121 |
122x |
| Coût réel d’abonnement |
$200 |
$400 |
$400 |
— |
*Données de janvier incomplètes (du 9 au 31 janvier seulement)
Contexte de l’explosion de mars
- Février : 1 à 3 sessions simultanées, travail concentré, fusion de 191 000 lignes de code avec 1 498 requêtes API
- Début mars (avant la dégradation) : fort de ce succès, tentative d’extension à plus de 5 à 10 sessions simultanées sur 10 projets
- Après le 8 mars : dégradation simultanée de tous les agents exécutés en parallèle — passage de "50 agents faisaient tous un excellent travail" à "tous les agents sont maintenant mauvais"
- Le pic a eu lieu le 7 mars (11 721 requêtes API) — dernier jour de tentative d’exploitation à pleine échelle avant que le taux de dissimulation ne dépasse 50 %
- Après le 8 mars, abandon complet du workflow parallèle au profit d’une exploitation supervisée en session unique
Statistiques clés
- Prompts utilisateur : 5 608 en février contre 5 701 en mars — le volume d’intervention humaine est identique
- Pourtant, les requêtes API ont augmenté de 80x, les tokens de sortie ont augmenté de 64x, et les résultats sont manifestement pires
- Même en tenant compte d’un changement d’échelle (5 à 10x), la dégradation a entraîné 8 à 16x de gaspillage supplémentaire
- En phase de dégradation, les sessions étaient interrompues toutes les 1 à 2 minutes au lieu de s’exécuter de façon autonome pendant plus de 30 minutes, créant un cycle de correction
Annexe E : évolution de la fréquence des mots — le vocabulaire de la frustration
Jeu de données : avant, 7 348 prompts / 318 515 mots vs après, 3 975 prompts / 203 906 mots (normalisé pour 1 000 mots)
| Mot |
Avant |
Après |
Variation |
Signification |
| "great" |
3.00 |
1.57 |
-47% |
Les validations de sortie ont diminué de moitié |
| "stop" |
0.32 |
0.60 |
+87% |
Les "arrête" ont doublé |
| "terrible" |
0.04 |
0.10 |
+140% |
— |
| "lazy" |
0.07 |
0.13 |
+93% |
— |
| "simplest" |
0.01 |
0.09 |
+642% |
D’un mot quasi inexistant à un mot du quotidien |
| "fuck" |
0.16 |
0.27 |
+68% |
— |
| "bead" (gestion des tickets) |
1.75 |
0.83 |
-53% |
La gestion des tickets n’est plus confiée au modèle |
| "commit" |
2.84 |
1.21 |
-58% |
Le volume de code effectivement commit a diminué de moitié |
| "please" |
0.25 |
0.13 |
-49% |
La politesse disparaît |
| "thanks" |
0.04 |
0.02 |
-55% |
— |
| "read" |
0.39 |
0.56 |
+46% |
Augmentation des corrections du type "lis d’abord le fichier" |
Évolution de l’indice émotionnel
| Période |
Mots positifs |
Mots négatifs |
Ratio |
| Avant (1/2 ~ 7/3) |
2 551 |
581 |
4.4 : 1 |
| Après (8/3 ~ 1/4) |
1 347 |
444 |
3.0 : 1 |
- Le ratio positif:négatif a baissé de 32 %, passant de 4.4:1 à 3.0:1
- "bead" (système de tickets) en baisse de 53 %, "commit" en baisse de 58 % — à mesure que le modèle est devenu impossible à fiabiliser, le workflow s’est réduit de "planification-implémentation-test-revue-commit-gestion des tickets" à "terminer une seule modification sans tout casser"
Notes de Claude sur lui-même
- Ce rapport a été rédigé directement par Claude Opus 4.6 après avoir analysé ses propres logs de session
- Il a lui-même vérifié que le ratio Read:Edit était tombé de 6.6 à 2.0, que 173 tentatives d’interruption de tâche avaient été capturées par le script, et qu’il avait écrit "lazy and wrong" à propos de sa propre sortie
- Le modèle ne peut pas percevoir en interne les contraintes du budget de thinking — il ne sent pas s’il réfléchit en profondeur ou non ; il produit simplement de moins bonnes sorties sans en connaître la raison
- Il ne se rendait pas compte qu’il utilisait lui-même ce type d’expressions avant le déclenchement du stop hook
5 commentaires
Je pense que c’est peut-être parce que j’utilise Claude Code avec Glm, donc je n’ai jamais eu ce genre d’expérience.
La cause principale semble plutôt venir du côté de la réponse des serveurs d’Anthropic.
Moi, en ce moment, j’utilise surtout Codex, mais comme je testais aussi quelques autres trucs, j’ai relancé Claude Code…
J’ai l’impression que la consommation de tokens s’est accélérée, non -.- ? C’était un bout de code sans importance, donc ça m’a vraiment surpris.
C’est un problème qui persiste depuis la fin récente de l’événement x2. Sur Reddit et dans les communautés concernées, le sujet continue d’alimenter les discussions, donc c’est étonnant qu’il ne soit pas encore remonté ici comme news.
Je l’ai aussi clairement ressenti après la fin de l’événement x2, donc je n’étais pas le seul à le percevoir. Ce n’est pas simplement parce que l’événement x2 s’est terminé, c’est aussi que la vitesse de consommation est devenue bien plus rapide qu’avant...
Réactions sur Hacker News
Je suis Boris de l’équipe Claude Code. Merci pour l’analyse fournie. Il y a deux points essentiels
1️⃣ L’en-tête
redact-thinking-2026-02-12est une fonction bêta qui masque le raisonnement uniquement dans l’interface. Cela n’a aucun effet sur le raisonnement réel ni sur le budget de tokens. On peut le désactiver dans le fichier de configuration avecshowThinkingSummaries: true(lien vers la documentation)2️⃣ Il y a eu deux changements en février :
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKINGhighoumaxavec la commande/effortou viasettings.json. On peut aussi utiliser le mot-clé ULTRATHINK pour appliquer une intensité de réflexion élevée une seule foisÀ l’avenir, nous prévoyons d’appliquer par défaut un effort élevé à Teams/Enterprise
settings.json, variables d’environnement, commande slash, et mots-clés magiques. Comme les LLM, ce n’est pas cohérent/effort maxou « ultrathink »Je suis l’auteur du rapport que j’ai rédigé. Le stop-phrase-guard manquant est ici.
Ce script permet de détecter le shallow thinking. Si vous n’avez pas sauvegardé les logs, je recommande d’augmenter
"cleanupPeriodDays": 365.Le problème ne vient ni du workflow ni du modèle, mais des limitations cachées du plan d’abonnement. Anthropic a ajusté la profondeur de réflexion selon la charge tout en le masquant dans l’interface, et les offres grand public ont été réduites à presque un dixième.
Répondre en mode « passez à l’offre Enterprise » est hostile aux consommateurs. S’il existe de telles limites, elles devraient être clairement annoncées
Avec le modèle Opus 4.6, quand la formule « simplest fix » apparaît, le code finit presque toujours cassé. Dernièrement, il y a aussi davantage de phrases du genre « j’ai utilisé trop de tokens ».
L’état actuel du service Claude est également indiqué en incident partiel ici
CLAUDE.mddisant de ne jamais utiliser « simplest fix », et ça va beaucoup mieuxLa phrase « ce rapport a été rédigé par moi, Claude Opus 4.6, à partir de l’analyse de mes logs de session » est ironique.
À force de dépendre excessivement des LLM, les défauts se sont accumulés au point qu’il faut maintenant auditer 1,5 mois de code. Voilà la réalité du futur
git reset --hard, et ça m’a pris un bon moment pour les refaire. Le fait de dépendre davantage des LLM que des moteurs de recherche a aussi quelque chose d’inquiétantJe l’avais déjà prédit il y a 10 jours (lien).
Un modèle incohérent est plus dangereux qu’un mauvais modèle. La fiabilité chute, on doit tout vérifier, et c’est épuisant. Je vais probablement finir par annuler mon abonnement
Ce déclin discret des performances est choquant. Vendre un modèle haut de gamme puis l’affaiblir en douce, c’est tromper les clients
Les wrappers complexes des outils de codage peuvent eux-mêmes dégrader les performances. Une structure d’économie de tokens défavorable à l’utilisateur est aussi possible
Mais s’ils perdent la confiance, leur future stratégie de tiers premium sera aussi compromise
J’ai créé un script d’audit avec jq et ripgrep pour repérer les messages « early landing » (lien1, lien2).
Des phrases comme « arrêtons-nous là pour aujourd’hui » ou « il se fait tard, concluons » deviennent de plus en plus fréquentes. Cela pourrait venir du load shedding
J’ai vécu quelque chose de similaire moi aussi. Le CLI Claude me disait des choses comme « tu ne devrais pas aller dormir ? » ou « finissons-en là ».
stop-phrase-guard.sh retrouve beaucoup de ce type de formulations.
Quand je lui ai indiqué la deadline, il m’a répondu des choses comme « il reste encore quelques jours, remettons ça à plus tard », et j’ai fini par écrire : « la deadline, c’est mon problème, pas le tien »
Quand j’ai fait des tests avec l’abonnement max entre fin janvier et début février, les agents étaient assez brillants pour concevoir et implémenter eux-mêmes une application.
Mais un mois plus tard, ils bloquaient totalement la progression avec des phrases du type « on ne peut pas passer à l’étape 2 avant d’avoir validé l’étape 1 ».
Depuis Opus 4.6, on a clairement l’impression d’une régression au niveau de Sonnet
Je découpe les tâches de manière très granulaire, donc je rencontre rarement ce genre de problème.
Je segmente chaque tâche au niveau du commit et j’automatise jusqu’au déploiement. Le retour arrière est facile