Homebrew a changé de fonctionnement pour désactiver par défaut postinstall et ne l’autoriser qu’à titre d’exception. Je ne sais pas s’il faut parler de chance, mais comme je mets à jour via les tags du dépôt sans passer par npm, cette version m’a épargné. Récemment, il y a aussi eu un cooldown sur npm, donc même si j’avais regardé du côté de npm, il est probable que cela n’aurait pas été publié.

 

Suis-je le seul à penser qu’au début, ils insistaient en disant qu’il n’y avait aucun problème, puis que maintenant que l’affaire a pris trop d’ampleur pour être étouffée, ils la rendent publique ?

 

J’utilise bien gstack. Le temps passé à peaufiner les specs diminue énormément.

 

Affirmer que Codex n'est pas à l'état de l'art, c'est quelque chose que seuls peuvent dire ceux qui ne l'ont pas essayé ou qui ne s'intéressent pas à ce domaine.

 

Au moins, avoir des indicateurs serait bien plus utile, je pense. Ce ne serait pas une mauvaise idée non plus de distinguer seulement la valeur la plus fréquente du reste.

 

Après seulement 2 heures, vous deviendrez daltonien.

 

Des choses comme jouer l’avocat du diable seraient pratiques à configurer avec une fonctionnalité comme Gems de Gemini.

 

Sur le benchmark quotidien SWE-Bench-Pro (jeu de données curé), il y a quelque chose d’intéressant quand on regarde claude code

Sur la période du 10/04 au 20/04, le runtime a été divisé par deux (653s→345s), les tool calls aussi (3.3K→1.8K), les tokens ont baissé de 18 %, alors que le pass rate a au contraire progressé de +16 points. Voir ces quatre indicateurs évoluer tous en même temps dans le bon sens, ce n’est pas un schéma courant

Les trois incidents survenus pendant ce processus correspondent au postmortem du 23/04, et quand on regarde, ils ont tous été causés par des tentatives de réduction des tokens et de la latence

À l’inverse, codex (gpt-5.4-xhigh) a très peu bougé sur la même période. Le pass rate reste pratiquement figé autour de 56 %, et les tokens/runtime/tool calls restent à peu près au double du niveau de claude code

 

Même si personne ne l’utilise, je continue à développer avec acharnement ma bibliothèque npm de compagnie, et je suis en train d’en optimiser les performances.
Les hypothèses auxquelles j’avais pensé se sont presque toutes révélées invalides après avoir lancé des benchmarks, donc je vais essayer d’en tirer d’autres pistes d’optimisation des performances avec ça.

 

Plutôt qu’un « il faut », ce serait peut-être plutôt du genre « ce serait bien de le faire » ~

 

On a aussi l’impression que l’ergonomie de claude.ai s’est un peu dégradée par petites touches… J’ai même désactivé la mémoire pour économiser des tokens.

 

J’ai l’impression que cette annonce me fait encore moins confiance à Anthropic.

Il y a deux articles liés ci-dessus, et ces deux textes ont 7 mois d’écart. Les problèmes sont exactement les mêmes, au nombre de trois.

Post-mortem de trois récents problèmes de dégradation de la qualité de Claude 2025-09-19
Mise à jour concernant les récents signalements sur la qualité de Claude Code 2026-04-24

 

N’est-ce pas plutôt un post-mortem de réduction des coûts qu’un post-mortem d’incident ?

 

C’est la bonne réponse, mais les excuses sont un peu longues lol

 

Je suis énervé à hauteur de 5 $ de crédits !!

 

Comment se fait-il que les trois causes de la panne soient toutes directement liées à la réduction des coûts, lol ?
On dirait qu’ils sont vraiment en grosse pénurie de ressources GPU, au point de dégrader les performances.....

 

En obligeant les employés en interne à utiliser les véritables builds publics, ils réduisent l'écart avec les builds destinés aux tests internes.
mdrrrr

 

Cela fait longtemps qu'il a trouvé sa place au sommet du SOTA..