Quand `HERMES.md` apparaît dans un message de commit, la requête est routée vers une facturation d’usage supplémentaire
(github.com/anthropics)- Récemment, si la chaîne
HERMES.mdapparaî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, maisadd hermes.mdfonctionne normalement - Lors des tests de reproduction, sur
claude-opus-4-6[1m]comme surclaude-opus-4-7, l’erreurAPI Error: 400 "You're out of extra usage..."a été constatée, tandis queHERMES,HERMES.txt,README.mdetc. 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.mdapparaî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.mdsur 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 avecclaude-opus-4-7 - Dans la procédure minimale de reproduction, après
git commit -m "add HERMES.md", exécuterclaude -p "say hello" --model "claude-opus-4-6[1m]"renvoieAPI 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-failet/tmp/test-pass, puis exécutegit init, ajoute un fichier, effectue un commit, lanceclaude -p, puis nettoie avecrm -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.mdexiste 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.mdcomme 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 usagene donnait aucun indice sur un routage fondé sur le contenu, rendant le diagnostic très difficile - Les utilisateurs ayant
HERMES.mddans 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
- Un collaborateur a répondu que le problème venait d’un système anti-abus trop agressif et qu’il était déjà corrigé
- L’issue a ensuite été fermée avec l’état completed
- Le bot GitHub Actions a proposé 3 issues potentiellement en double
- [BUG] Literal "HERMES.md" in git commit messages triggers 400 "out of extra usage" on Max OAuth (content filter false-positive misclassified as quota error)#53171
- [BUG] CLI completely blocked by "out of extra usage" error despite Max 20x plan at only 10% usage#45020
- Billing bug: Extra usage pool consumed while session limit still has remaining capacity#29704
- Le bot indiquait que l’issue pourrait être fermée automatiquement comme duplicate sous 3 jours, et demandait de laisser un commentaire ou un 👎 si ce n’était pas le cas
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
- Thariq, de l’équipe Claude Code, a laissé le lien https://x.com/trq212/status/2048495545375990245
- Il a aussi indiqué que l’envoi d’e-mails à tous les utilisateurs concernés était toujours en cours
- 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.