Anthropic va désormais vous facturer une requête à laquelle il refuse de répondre

Le 24 septembre, à 17 h 11 UTC, le compte développeur d'Anthropic a publié deux paragraphes qui ont modifié une ligne de la documentation de facturation. L'entreprise va reprendre la facturation des requêtes que ses garde-fous bloquent avant que Claude ne réponde. Le changement ne s'applique qu'à trois catégories où elle mesure de faibles taux de faux positifs : la biologie, le développement de grands modèles de frontière et l'extraction de raisonnement, que le billet appelle des attaques par distillation.

Le mécanisme est simple et légèrement inconfortable. Lorsqu'un classifieur de Claude refuse une requête avant de générer quoi que ce soit, l'API ne renvoie pas d'erreur. Elle renvoie un HTTP 200 normal avec `stop_reason: "refusal"`, un tableau de contenu vide et un objet `stop_details` dont le champ `category` nomme le domaine de politique concerné. Le refus ne contient aucun contenu, mais les compteurs de tokens apparaissent toujours dans l'usage, et la requête est toujours décomptée de vos limites de débit. Selon la nouvelle règle, dans ces trois catégories, le refus est également facturé, aux tarifs du modèle qui l'a exécuté.

Anthropic avait supprimé la facturation des refus sans sortie le 2 juin, autour du lancement de son produit Fable. Les refus en cours de génération, où le modèle commence à répondre puis est arrêté, ont toujours été facturés. Les refus avant toute sortie dans d'autres catégories, notamment la cybersécurité et les préjudices généraux, restent gratuits. Le changement s'applique à l'ensemble de l'API Claude, d'Amazon Bedrock, de Claude Platform sur AWS, de Google Cloud et de Microsoft Foundry, et la documentation ajoute un avertissement indiquant que les catégories facturées pourraient encore changer.

Pourquoi la facturation est désormais un contrôle de sécurité

La raison officielle invoquée par l'entreprise est qu'elle a observé des attaques coordonnées contre ses systèmes ces dernières semaines. Une requête bloquée qui ne coûte rien est une sonde gratuite. Un attaquant qui veut cartographier la forme d'un classifieur peut envoyer des milliers de requêtes et apprendre des refus sans payer un centime. Facturer la tentative bloquée dans précisément les trois catégories attaquées augmente le coût de cette cartographie, et Anthropic affirme explicitement que ces frais doivent servir de couche de défense plutôt que de source de revenus.

Deux chiffres accompagnaient l'annonce. Lors de tests récents, 99,7 % des comptes utilisant Claude Code, Claude.ai ou Cowork n'ont rencontré aucun des blocages nouvellement facturables. Les classifieurs qui les sous-tendent sont réglés pour un taux de faux positifs inférieur à 0,1 %, et le billet ajoute que ce chiffre n'est pas nul et que les classifieurs continueront de s'améliorer afin d'interrompre le travail moins souvent.

Les classifieurs s'exécutent sur quatre modèles Claude : Fable 5.1, Fable 5, Opus 5.5 et Opus 5. La documentation nomme cinq catégories. Deux d'entre elles, la cybersécurité et les préjudices généraux, ne sont pas facturées. Les trois qui le sont correspondent à des travaux que les conditions commerciales d'Anthropic restreignent déjà, ce qui explique pourquoi le taux de faux positifs est suffisamment faible pour être mesuré : peu de clients légitimes entraînent des modèles de frontière ou demandent à un modèle de reproduire son propre raisonnement interne.

Les attaques par distillation méritent d'être explicitées, car le nom porte une lourde charge. Le code de la catégorie est `reasoning_extraction`, et le comportement visé consiste à inciter un modèle à exposer son raisonnement interne étape par étape afin que la sortie puisse servir à entraîner un système concurrent. C'est le mécanisme derrière plusieurs litiges de vol de modèle de l'année écoulée, et il est difficile à distinguer des utilisateurs ordinaires qui veulent simplement que le modèle réfléchisse à voix haute.

Les faux positifs sont déjà visibles

Les tickets ouverts sur le dépôt GitHub de claude-code racontent une autre histoire sur ce taux. Un utilisateur a signalé 23 déclenchements dans la catégorie d'extraction de raisonnement sur des tâches ordinaires, notamment de la rédaction de podcasts et des tableurs budgétaires, et a indiqué que sept d'entre eux ont mis fin au tour. D'autres signalements décrivent des tâches de développement logiciel courantes et la propre documentation de workflow de Claude Code déclenchant le même blocage. Anthropic n'a pas expliqué comment fonctionnerait un remboursement pour un blocage qui s'avère erroné, se contentant d'orienter les utilisateurs vers la commande `/feedback`.

Cet écart constitue le problème pratique. Un développeur peut compter les événements `stop_reason: "refusal"` et réessayer sur un modèle de repli, ce qui est la solution de contournement documentée, et le dispositif de crédit de repli reste inchangé. Ce qu'il ne peut pas facilement faire, c'est déterminer, au moment de la facturation, si le blocage était justifié. Si la réponse arrive plus tard, l'argent a déjà été prélevé, et une politique de remboursement non publiée n'est pas quelque chose sur quoi une équipe financière peut budgétiser.

La réaction au billet a été modérée plutôt que courroucée. En environ trois heures, il a recueilli près de 1 511 likes, 64 reposts et 220 réponses sur X, et la soumission sur Hacker News a obtenu cinq points et deux commentaires. L'essentiel des discussions portait sur le principe plutôt que sur le montant, ce qui suggère que celui-ci est assez faible pour que peu d'équipes le remarquent sur une facture.

Ce qu'une équipe peut réellement maîtriser

Deux éléments de la documentation méritent d'être intégrés à un pipeline. Le premier est la catégorie de refus, qui arrive sous forme de champ lisible par machine, de sorte qu'un service peut séparer les refus des erreurs dans ses journaux et les compter par catégorie dans le temps, plutôt que de découvrir le schéma lors d'une revue trimestrielle. Le second est le chemin de repli. Le schéma documenté consiste à réessayer une requête refusée sur un modèle de repli, et Anthropic indique que le dispositif de crédit de repli reste inchangé, ce qui signifie qu'une nouvelle tentative ne paie pas deux fois le même travail.

Aucun des deux ne résout le problème des faux positifs. Lorsqu'une requête légitime est bloquée dans une catégorie facturée, l'enregistrement indique un refus avec un code de catégorie et aucun contenu, et la facture indique des frais. Une équipe qui ne lit jamais ce champ ne découvrira le taux que le jour où quelqu'un demandera pourquoi la facture a bougé.

Le principe est la partie intéressante

Tous les grands fournisseurs de modèles font une version de ce calcul. Les refus consomment du calcul, et un refus qu'un client peut déclencher à volonté est un levier qu'un attaquant peut actionner. Facturer la requête refusée reporte le coût sur celui qui actionne ce levier.

Le problème est que le même levier est accessible à des personnes qui n'attaquent rien. Quelqu'un qui rédige un article de biologie, ou une startup qui travaille sur des techniques de distillation de modèles, se situe dans les catégories facturées par la nature même de son travail plutôt que par intention. La formulation d'Anthropic est que le taux de faux positifs est suffisamment faible pour être accepté, ce qui est un jugement rendu par la partie qui perçoit les frais.

Une conception plus propre est possible, et Anthropic l'a partiellement mise en place. Le champ `stop_details.category` est lisible par machine, de sorte qu'une équipe peut acheminer les refus vers un journal, les compter par catégorie et les auditer de façon agrégée. Les réponses refusées apparaissent aussi dans les enregistrements d'usage avec les compteurs de tokens associés, ce qui signifie que les données nécessaires à un litige sont déjà enregistrées. Que cela devienne une partie normale de l'exploitation de Claude en production, ou reste une note de bas de page que la plupart des équipes ne lisent jamais, détermine ce que ce changement de facturation coûte au-delà de la ligne de facture.