Benchmark quotidien pour suivre les baisses de performance de Claude Code

 (marginlab.ai)
9 points par GN⁺ 2026-01-30 | 2 commentaires | Partager sur WhatsApp
  • Système de suivi qui mesure chaque jour les performances de Claude Code Opus 4.5 sur des tâches de SWE afin de détecter des baisses de performance statistiquement significatives
  • Évalue 50 instances de test par jour à partir d’un sous-ensemble sélectionné de SWE-Bench-Pro, avec des résultats qui reflètent les performances réelles du modèle exécuté directement dans un environnement CLI
  • Sur les 30 derniers jours, un taux de réussite moyen de 54 % a été observé, avec une baisse statistiquement significative de 4,1 % par rapport au niveau de référence de 58 %
  • Les résultats quotidiens et hebdomadaires sont analysés à l’aide d’intervalles de confiance à 95 % et de seuils de significativité (±14,0 %, ±5,6 %), afin de distinguer les fluctuations de court terme des tendances de fond
  • Outil exploité par une organisation tierce indépendante pour détecter rapidement les baisses de performance dues à des changements du modèle ou de l’environnement d’exécution

Vue d’ensemble

  • L’objectif de ce tracker est de détecter les baisses statistiquement significatives des performances de Claude Code Opus 4.5 sur des tâches de SWE
    • Une évaluation est réalisée chaque jour à l’aide d’un sous-ensemble résistant à la contamination de SWE-Bench-Pro
    • L’exécution se fait directement dans Claude Code CLI, sans harness personnalisé, afin de refléter les conditions d’usage réelles
  • Organisation tierce indépendante, sans partenariat avec les fournisseurs de modèles frontier
  • Exploité comme ressource pour détecter précocement des cas similaires à la suite du post-mortem d’Anthropic sur la baisse de performance de septembre 2025

Résumé des performances

  • Taux de réussite de référence : 58 %
  • Taux de réussite sur les 30 derniers jours : 54 % (sur 655 évaluations)
  • Taux de réussite sur les 7 derniers jours : 53 % (sur 250 évaluations)
  • Taux de réussite sur le dernier jour : 50 % (sur 50 évaluations)
  • La baisse de performance sur 30 jours est statistiquement significative au seuil p < 0,05
    • Variation sur 30 jours : -4,1 %
    • Seuil de significativité : ±3,4 %
  • Les variations sur 1 jour (-8,0 %) et 7 jours (-4,8 %) ne sont pas statistiquement significatives
Publicité

Tendances quotidiennes et hebdomadaires

  • Tendance quotidienne (Daily Trend)
    • Visualisation du taux de réussite journalier sur les 30 derniers jours
    • Référence à 58 %, zone de significativité ±14,0 %
    • Affichage possible des intervalles de confiance à 95 %, qui s’élargissent lorsque la taille de l’échantillon est faible
  • Tendance hebdomadaire (Weekly Trend)
    • Fournit une tendance lissée via une moyenne mobile sur 7 jours pour atténuer la volatilité quotidienne
    • Référence à 58 %, zone de significativité ±5,6 %
    • Même possibilité d’afficher des intervalles de confiance à 95 %

Aperçu des variations (Change Overview)

  • Variation sur 1 jour (par rapport à hier) : -8,0 %, non statistiquement significative
    • Sur la base de 50 évaluations, une variation de ±14,0 % est nécessaire (p < 0,05)
    Publicité
  • Variation sur 7 jours (par rapport à la semaine dernière) : -4,8 %, non statistiquement significative
    • Sur la base de 250 évaluations, une variation de ±5,6 % est nécessaire (p < 0,05)
  • Variation sur 30 jours (par rapport au mois dernier) : -4,1 %, statistiquement significative
    • Sur la base de 655 évaluations, une variation de ±3,4 % est nécessaire (p < 0,05)

Méthodologie (Methodology)

  • Chaque test est modélisé comme une variable aléatoire de Bernoulli, et des intervalles de confiance à 95 % sont calculés
  • Les écarts statistiques entre les taux de réussite journaliers, hebdomadaires et mensuels sont analysés afin de déterminer s’il existe une baisse de performance significative
  • L’évaluation est réalisée avec 50 instances de test par jour, d’où une certaine volatilité à court terme
  • Les résultats agrégés hebdomadaires et mensuels fournissent des estimations plus stables
  • Permet de détecter aussi bien les baisses de performance dues à des modifications du modèle qu’à des changements du harness d’exécution

Fonction d’alerte

  • Envoi d’une alerte par e-mail lorsqu’une baisse de performance est détectée statistiquement
  • Les utilisateurs peuvent s’abonner en enregistrant leur adresse e-mail
  • Les alertes sont reçues après confirmation de l’abonnement, avec indication de réessayer en cas d’erreur

À lire aussi

2 commentaires

 
iolothebard 2026-01-31

Ce n’est peut-être pas que Claude Code est devenu plus bête… c’est peut-être aussi que la personne qui l’utilise a simplement appris à mieux s’en servir…
 
GN⁺ 2026-01-30
Réactions sur Hacker News

  • Ici Thariq de l’équipe Claude Code
    Le problème de harness survenu le 26 janvier a été corrigé. Le rollback a été effectué dès le 28 janvier, donc il est recommandé de mettre à jour vers la dernière version avec la commande claude update

    • La version 2.1.x de Claude se bloque souvent ou utilise 100 % du CPU, au point d’être pratiquement inutilisable. Le problème est signalé dans GitHub #18532
    • Claude a gaspillé des tokens ; je me demande s’il y aura une compensation pour cela
    • J’aimerais en savoir plus sur ce que signifie exactement le “harness issue” et sur son impact
    • Le problème existait déjà avant le 26 janvier. C’est à partir de ce moment-là que Claude a commencé à modifier arbitrairement les plans au nom de “l’amélioration”
    • Plus que le modèle lui-même, c’est le système de contrôle qualité qui m’interroge. Je me demande s’il existe un processus interne qui vérifie régulièrement des échantillons de sorties réelles ou surveille les baisses de performance via des benchmarks. Du point de vue de la sécurité de l’IA aussi, ce type de validation est indispensable

  • Coauteur de SWE-bench
    Actuellement, les tests semblent ne porter que sur 50 tâches et n’être exécutés qu’une fois par jour. Pour améliorer la précision, il faudrait tester 300 tâches 5 à 10 fois par jour puis faire la moyenne. Des facteurs aléatoires comme la charge serveur peuvent fortement influencer les résultats

    • La baisse de performance due à la surcharge des serveurs ne devrait-elle pas aussi faire partie de ce qu’on mesure ? À moins que l’objectif ne soit uniquement de mesurer la distillation du modèle
    • Le coût d’exécution du modèle semble probablement être le problème. Ce serait bien si Anthropic apportait un peu de crédit, ou ouvrait un lien de dons
    • Les écarts de performance selon le moment de la journée pourraient être encore plus importants
    • Il y a aussi la difficulté de faire tourner SWE-bench suffisamment souvent, car son coût d’exécution est trop élevé. mafia-arena.com rencontre un problème similaire
    • Dire que “le serveur est surchargé donc la mesure n’est pas exacte” est étrange. Est-ce que cela veut dire qu’il existe quand même des heures de bureau où Claude fonctionne bien ?

  • Résumé des raisons pour lesquelles je ne crois pas qu’Anthropic fournisse intentionnellement un modèle moins bon aux utilisateurs

    1. La baisse de précision est faible et oscille à la hausse comme à la baisse
    2. Il n’y a pas de point de comparaison avec Sonnet 4.5, et sous charge GPU, Opus peut tomber au niveau de Sonnet
    3. Il est très probable que plusieurs checkpoints soient en test A/B. Les mises à jour de version de Claude Code ou la non-déterminisme de l’échantillonnage des tokens peuvent aussi être en cause
    • Je comprends l’explication scientifique, mais à l’usage quotidien on a clairement l’impression que les performances se dégradent
    • Moi aussi, je pense que les tests A/B sont la cause principale. J’aimerais qu’ils communiquent plus clairement sur des choses comme les limites de fenêtre de contexte ou les changements de prompt système. L’idéal serait de permettre aux utilisateurs de choisir eux-mêmes une version et de donner leur retour
    • Je me demande pourquoi le graphique commence le 8 janvier. C’était peut-être un jour anormalement élevé
    • Il est aussi possible qu’ils ajustent automatiquement le compromis performance-coût en fonction de la charge. Ils ont peut-être commencé avec de hautes performances puis réduit progressivement le modèle pour économiser des coûts, par exemple en réduisant le nombre d’experts MoE
    • Dire que “la baisse est trop faible” n’est qu’un jugement subjectif qui ignore la significativité statistique

  • La méthodologie statistique est bizarre
    Ils ne considèrent que l’intervalle de confiance de la valeur précédente pour voir si la nouvelle valeur est en dehors, mais ce n’est pas la bonne façon de tester la significativité statistique d’une différence. Les deux mesures comportent de l’incertitude, donc il faut calculer l’intervalle de confiance de la différence elle-même. De plus, pour une comparaison mensuelle, il faudrait comparer les données d’il y a 60 à 31 jours à celles allant d’il y a 30 jours à hier ; le graphique devrait donc couvrir au moins deux mois

  • Il y a environ une semaine, Claude est tombé en panne pendant une heure. Juste après le rétablissement, probablement parce qu’il y avait moins d’utilisateurs, la vitesse a plus que triplé. Pendant cette heure, j’ai accompli ce qui me prend d’habitude une demi-journée. C’était comme entrevoir brièvement l’avenir sans contrainte de ressources

    • Pendant les jours fériés aux États-Unis aussi, avec l’assouplissement des limites d’usage, tout fonctionnait beaucoup plus fluidement
    • J’ai eu la même expérience il y a quelques jours. C’était tellement rapide que j’ai même cherché “claude speed boost”. C’était une vitesse fulgurante, comme à l’époque des mises à niveau de modem
    • Quand ça va trop vite, c’en devient presque regrettable. Maintenant, j’aime bien sentir que le modèle travaille dur

  • Mesurer la fréquence des grossièretés dans les prompts utilisateurs permettrait de détecter une hausse de l’hostilité des utilisateurs quand les performances du modèle baissent

    • Mais existe-t-il vraiment un moyen de scanner “simplement” les prompts des utilisateurs de Claude ?
    • Il y a une corrélation entre l’augmentation des grossièretés et les sollicitations de feedback du type “How’s Claude Doing This Session?”
    • Moi, je jure souvent de base, donc ça pourrait biaiser les données
    • Moi aussi, ça me rassure
    • Parfois, quand il donne une réponse trop stupide, les insultes sortent toutes seules. C’est une réaction liée à des attentes élevées

  • Il est possible qu’ils quantifient progressivement le modèle au fil du temps. Cela faciliterait la scalabilité et la réduction des coûts, tout en donnant aussi l’impression qu’une nouvelle version paraît “meilleure”

    • Je l’utilise 5 à 10 heures par jour, et cette dernière semaine, il a clairement semblé devenir plus bête. Même s’ils le nient, le changement est perceptible à l’usage
    • Même sans quantification, on peut réduire la charge en raccourcissant la longueur des conversations ou en réduisant le temps de raisonnement
    • Les modèles open GPT-OSS et Kimi K2.x ont eux aussi été entraînés avec des couches en 4 bits. Opus 4.5 coûte 8 fois plus cher par token, donc c’est probablement un modèle plus gros, mais la structure tarifaire par abonnement empêche les comparaisons simples
    • Anthropic ne donne pas l’impression d’être une entreprise à ce point contrainte par les coûts d’infrastructure. Dans un contexte de forte concurrence, dégrader volontairement la qualité serait une mauvaise stratégie. Il se peut plutôt que les utilisateurs perçoivent mieux les défauts après la phase de lune de miel
    • Malgré tout, cette stratégie de dégradation progressive paraît tout à fait plausible. Elle pourrait maximiser l’effet d’amélioration relative d’un nouveau modèle

  • En mode API, dès que Claude dépasse un certain nombre de tokens, il devient soudainement plus bête et se met à faire des choses absurdes, comme dire “il y a un bug à la ligne 23” puis supprimer toute la fonctionnalité. Il échoue même sur des corrections simples que ChatGPT 3.5 peut faire. Je ne comprends pas pourquoi ça arrive

    • C’est probablement dû à des contraintes de ressources. Ils ont sans doute préféré fournir des réponses correctes à peu près acceptables à davantage d’utilisateurs, plutôt que d’excellentes réponses à seulement quelques-uns
    • J’ai eu la même expérience. J’ai l’impression que Claude devient de plus en plus paresseux

  • Depuis une semaine, la qualité du code produit par Claude s’est visiblement dégradée. Par exemple, il propose d’utiliser frozen sur un Enum, ou recommande à nouveau urlparse dans une fonction qui utilise déjà urlparse. Avant, il ne faisait pas ce genre d’erreurs basiques

  • Le manque de constance des capacités de raisonnement chez les fournisseurs de LLM est une grosse source de frustration. ChatGPT aussi a le même problème : au-delà de 45k tokens en entrée, son intelligence chute brutalement ou l’entrée se fait tronquer. Il vaudrait mieux afficher un message de “refus” plutôt que de rétrograder en douce, car cela détruit la confiance. La transparence est vraiment essentielle