- 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
Aucun commentaire pour le moment.