1 points par GN⁺ 2 시간 전 | Aucun commentaire pour le moment. | Partager sur WhatsApp
  • Récemment, si la chaîne HERMES.md apparaît dans un message de commit git, la requête Claude Code est envoyée vers la facturation extra usage au lieu du quota du forfait Max
  • Ce déclencheur est indépendant de la présence réelle d’un fichier sur le disque et se produit à partir du contenu même du message de commit ; add HERMES.md échoue, mais add hermes.md fonctionne normalement
  • Lors des tests de reproduction, sur claude-opus-4-6[1m] comme sur claude-opus-4-7, l’erreur API Error: 400 "You're out of extra usage..." a été constatée, tandis que HERMES, HERMES.txt, README.md etc. ne provoquent pas le même comportement
  • Dans l’environnement touché, alors qu’il restait du quota hebdomadaire du forfait, 200,98 $ de crédits extra usage ont été consommés ; une fois ces crédits épuisés, plusieurs projets sont devenus inutilisables
  • La cause a été identifiée comme un système anti-abus trop agressif ; le problème a déjà été corrigé, puis l’issue a été clôturée comme completed, avec annonce d’un remboursement et d’un octroi de crédits d’usage supplémentaires

Aperçu du problème

  • Récemment, si la chaîne HERMES.md apparaît dans l’historique récent des commits git, la requête Claude Code est routée vers la facturation extra usage au lieu du quota du forfait Max
  • Cela n’a aucun lien avec la présence d’un fichier HERMES.md sur le disque ; c’est bien le contenu du message de commit git qui agit comme déclencheur
  • Comme Claude Code inclut les commits récents dans le system prompt, il a été établi que la présence de cette chaîne modifiait le routage côté serveur
  • Bien que l’utilisation hebdomadaire incluse du forfait Max 20x n’en soit qu’à 13 %, 200,98 $ de crédits extra usage ont été consommés ; une fois ces crédits épuisés, plusieurs projets sont devenus totalement inutilisables
  • Au même moment, le tableau de bord du forfait affichait encore plus de 86 % de capacité hebdomadaire restante, montrant un décalage entre la voie de facturation réelle et l’état affiché

Conditions de reproduction et résultats

  • L’environnement de reproduction est Claude Code v2.1.119, macOS Apple Silicon, forfait Max 20x à 200 $/mois, modèle claude-opus-4-6[1m], et le problème se reproduit aussi avec claude-opus-4-7
  • Dans la procédure minimale de reproduction, après git commit -m "add HERMES.md", exécuter claude -p "say hello" --model "claude-opus-4-6[1m]" renvoie API Error: 400 "You're out of extra usage..."
  • Avec la même procédure, si le message de commit devient add hermes.md, la requête passe par la voie du quota du forfait et renvoie "Hello!"
  • Le script de reproduction crée les répertoires /tmp/test-fail et /tmp/test-pass, puis exécute git init, ajoute un fichier, effectue un commit, lance claude -p, puis nettoie avec rm -rf
  • Les résultats d’identification du déclencheur montrent un échec avec "HERMES.md" et "test HERMES.md test", tandis que "hermes.md", "HERMES", "HERMES.txt", "AGENTS.md", "README.md" fonctionnent normalement
  • Même si un fichier HERMES.md existe sur le disque, tout fonctionne normalement si le message de commit est propre ; dans le même dépôt, si l’on passe sur une orphan branch sans historique, cela fonctionne aussi normalement

Analyse de la cause et comportement attendu

  • L’analyse a progressé en copiant le dépôt touché, en effectuant un test sur orphan branch, puis en isolant une à une les chaînes présentes dans les messages de commit via une recherche binaire systématique, jusqu’à identifier précisément HERMES.md comme déclencheur
  • La facturation des requêtes API ne devrait pas dépendre du contenu du message de commit git dans le system prompt ; pour les abonnés Max, les requêtes devraient d’abord être routées vers le quota inclus du forfait
  • Le message d’erreur out of extra usage ne donnait aucun indice sur un routage fondé sur le contenu, rendant le diagnostic très difficile
  • Les utilisateurs ayant HERMES.md dans leurs commits récents se retrouvaient dans une situation où leur usage pouvait être silencieusement facturé en crédits supplémentaires

Déroulement du traitement et état final

Remboursement et réponse du support

  • Le texte comprend une réponse du support indiquant qu’en cas de mauvais billing routing dû à une erreur technique, aucune compensation ni remboursement ne pouvait être accordé
  • Ensuite, d’après https://news.ycombinator.com/item?id=47952722, les utilisateurs touchés devaient recevoir un remboursement intégral ainsi que des crédits d’usage supplémentaires d’un montant équivalent à l’abonnement mensuel
  • Le dispositif de support n’était pas prêt à faire remonter ce type de bug complexe vers l’ingénierie, même si une amélioration est en cours
  • L’annonce initiale d’absence de remboursement et la communication ultérieure sur le remboursement coexistent donc dans le même fil, donnant des messages contradictoires

Réactions des utilisateurs et critiques de conception

  • À une période où l’éligibilité au remboursement restait floue, certains sont allés jusqu’à annuler leur abonnement ; l’absence de réponse sur le remboursement et le GIF d’applaudissements joint au message ont été cités comme motifs
  • On voit aussi apparaître une attitude consistant à attendre de voir si la réponse du support débouche réellement sur un remboursement avant de juger à l’avenir
  • En raison des images et mèmes, certains ont compris tardivement que le commentaire de l’auteur original n’était pas un propos personnel mais une citation d’un bot de support
  • En s’appuyant sur le signalement de @bcherny, certains ont interprété le système anti-abus trop agressif comme un mécanisme qui, au lieu de bloquer certaines requêtes, les basculait vers la facturation extra usage
  • Les critiques ont insisté sur le fait que si quelque chose relève de l’abus, il faut le bloquer et non le traiter via une surfacturation ; s’il existe un mode qui contourne le quota tout en laissant passer les requêtes en les majorant, c’est la conception elle-même qui pose problème
  • Certains ont aussi protesté contre l’idée qu’une tentative de l’utilisateur de contrôler directement un client exécuté en local soit traitée comme une forme de breach, et ont soutenu qu’il devrait être possible de déléguer des autorisations à un software agent agissant pour le compte de l’utilisateur
  • D’autres ont souligné qu’il y avait un décalage entre la promesse commerciale de vendre un agent personnel et le message implicite selon lequel seule la combinaison personne+agent serait réellement la bienvenue

Mention de modèles alternatifs

  • Des modèles open weight chinois sont évoqués comme alternatives, pouvant être hébergés sur du matériel local et exécutés de manière autonome dès lors que l’on dispose du matériel nécessaire
  • Ces modèles seraient 10 à 50 fois moins chers qu’Anthropic, avec des performances en code inférieures d’environ 2,7 %

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.