A Anthropic agora vai cobrar por um pedido que se recusa a responder

Em 24 de setembro, às 17:11 UTC, a conta de desenvolvedores da Anthropic publicou dois parágrafos que mudaram uma linha na documentação de faturamento. A empresa vai voltar a cobrar por solicitações que suas salvaguardas bloqueiam antes que o Claude responda. A mudança se aplica apenas a três categorias em que ela mede baixas taxas de falso positivo: biologia, desenvolvimento de modelos de fronteira e extração de raciocínio, que a publicação chama de ataques de destilação.

A mecânica é simples e um pouco desconfortável. Quando um classificador do Claude recusa uma solicitação antes de gerar qualquer coisa, a API não retorna um erro. Ela retorna um HTTP 200 normal com stop_reason: "refusal", um array de conteúdo vazio e um objeto stop_details cujo campo category nomeia a área de política. A recusa não traz conteúdo, mas as contagens de tokens ainda aparecem no uso, e a solicitação ainda conta para seus limites de taxa. Sob a nova regra, nessas três categorias, a recusa também é cobrada, às tarifas do modelo que a executou.

A Anthropic havia removido as cobranças por recusas com saída zero em 2 de junho, por volta do lançamento de seu produto Fable. Recusas no meio do fluxo, quando o modelo começa a responder e depois é interrompido, sempre foram cobradas. Recusas antes de qualquer saída em outras categorias, incluindo segurança cibernética e danos gerais, permanecem gratuitas. A mudança se aplica à API do Claude, ao Amazon Bedrock, ao Claude Platform na AWS, ao Google Cloud e ao Microsoft Foundry, e a documentação acrescenta um aviso de que as categorias cobradas podem mudar novamente.

Por que o faturamento agora é um controle de segurança

A razão declarada pela empresa é que ela tem visto ataques coordenados contra seus sistemas nas últimas semanas. Uma solicitação bloqueada que não custa nada é uma sondagem gratuita. Um atacante que queira mapear o formato de um classificador pode enviar milhares de solicitações e aprender com as recusas sem pagar um centavo. Colocar um preço na tentativa bloqueada exatamente nas três categorias sob ataque eleva o custo desse mapeamento, e a Anthropic é explícita ao dizer que a cobrança deve funcionar como uma camada de defesa, e não como receita.

Dois números vieram junto com o anúncio. Em testes recentes, 99,7% das contas que usam Claude Code, Claude.ai ou Cowork não atingiram nenhum dos bloqueios recém-cobráveis. Os classificadores por trás deles são ajustados para uma taxa de falso positivo abaixo de 0,1%, e a publicação acrescenta que o número não é zero e que os classificadores continuarão melhorando para interromper o trabalho com menos frequência.

Os classificadores rodam em quatro modelos Claude: Fable 5.1, Fable 5, Opus 5.5 e Opus 5. A documentação nomeia cinco categorias. Duas delas, segurança cibernética e danos gerais, não são cobradas. As três cobradas correspondem a trabalhos que os termos comerciais da Anthropic já restringem, e é justamente por isso que a taxa de falso positivo é baixa o suficiente para ser medida: poucos clientes legítimos estão treinando modelos de fronteira ou pedindo que um modelo reproduza seu próprio raciocínio interno.

Vale detalhar os ataques de destilação, porque o nome carrega muito peso. O código da categoria é reasoning_extraction, e o comportamento visado é instigar um modelo a expor seu raciocínio interno passo a passo para que a saída possa ser usada no treinamento de um sistema concorrente. É o mecanismo por trás de várias disputas de roubo de modelos do último ano, e é difícil separá-lo de usuários comuns que simplesmente querem que o modelo pense em voz alta.

Os falsos positivos já são visíveis

As issues abertas no repositório claude-code no GitHub contam uma história diferente sobre a taxa. Um usuário registrou 23 sinalizações na categoria de extração de raciocínio em trabalho comum, incluindo textos de podcast e planilhas de orçamento, e disse que sete delas encerraram o turno. Outros relatos descrevem tarefas padrão de desenvolvimento de software e a própria documentação de fluxo de trabalho do Claude Code acionando o mesmo bloqueio. A Anthropic não explicou como funcionaria um reembolso para um bloqueio que se revela equivocado, além de apontar os usuários para o comando /feedback.

Essa lacuna é o problema prático. Um desenvolvedor pode contar os eventos de stop_reason: "refusal" e tentar novamente com um modelo alternativo, que é a solução documentada, e o arranjo de crédito para fallback permanece inalterado. O que ele não consegue fazer facilmente é dizer, no momento da cobrança, se o bloqueio estava correto. Se a resposta chegar depois, o dinheiro já se moveu, e uma política de reembolso que não foi publicada não é algo contra o que uma equipe financeira possa orçar.

A reação à publicação foi moderada, e não furiosa. Em cerca de três horas, ela acumulou aproximadamente 1.511 curtidas, 64 reposts e 220 respostas no X, e o envio no Hacker News rendeu cinco pontos e dois comentários. A maior parte da discussão foi sobre o princípio, e não sobre o valor, o que sugere que o valor é pequeno o suficiente para que poucas equipes o notem em uma fatura.

O que uma equipe realmente pode controlar

Duas coisas na documentação valem ser integradas a um pipeline. A primeira é a categoria da recusa, que chega como um campo legível por máquina, de modo que um serviço pode separar recusas de erros em seus logs e contá-las por categoria ao longo do tempo, em vez de descobrir o padrão durante uma revisão trimestral. A segunda é o caminho de fallback. O padrão documentado é tentar novamente uma solicitação recusada com um modelo alternativo, e a Anthropic diz que o arranjo de crédito para fallback não mudou, o que significa que uma nova tentativa não paga duas vezes pelo mesmo trabalho.

Nenhuma das duas resolve o problema dos falsos positivos. Quando uma solicitação legítima é bloqueada em uma categoria cobrada, o registro mostra uma recusa com um código de categoria e nenhum conteúdo, e a fatura mostra uma cobrança. Uma equipe que nunca lê esse campo só vai descobrir a taxa quando alguém perguntar por que a conta mudou.

O princípio é a parte interessante

Todo grande provedor de modelos faz alguma versão desse cálculo. Recusas consomem computação, e uma recusa que um cliente pode acionar à vontade é uma alavanca que um atacante pode puxar. Cobrar pela solicitação recusada devolve o custo a quem está puxando essa alavanca.

O problema é que a mesma alavanca está ao alcance de pessoas que não estão atacando nada. Alguém escrevendo um artigo de biologia, ou uma startup trabalhando com técnicas de destilação de modelos, está nas categorias cobradas pela definição do trabalho, e não pela intenção. A própria formulação da Anthropic é que a taxa de falso positivo é baixa o suficiente para ser aceita — um julgamento feito pela parte que recolhe a taxa.

Existe um design mais limpo disponível, e a Anthropic o construiu em parte. O campo stop_details.category é legível por máquina, então uma equipe pode encaminhar recusas para um log, contá-las por categoria e auditá-las de forma agregada. Respostas recusadas também aparecem nos registros de uso com contagens de tokens anexadas, o que significa que os dados de que uma disputa precisaria já estão sendo registrados. Se isso se torna uma parte normal de rodar o Claude em produção, ou continua sendo uma nota de rodapé que a maioria das equipes nunca lê, decide quanto a mudança de faturamento custa além da linha da fatura.