Anthropic ahora te cobrará por una solicitud que se niega a responder

El 24 de septiembre, a las 17:11 UTC, la cuenta de desarrolladores de Anthropic publicó dos párrafos que cambiaban una línea en la documentación de facturación. La empresa reanudará el cobro por las solicitudes que sus salvaguardas bloquean antes de que Claude responda. El cambio se aplica solo en tres categorías donde mide tasas bajas de falsos positivos: biología, desarrollo de modelos grandes de frontera y extracción de razonamiento, que la publicación llama ataques de destilación.

La mecánica es simple y ligeramente incómoda. Cuando un clasificador de Claude rechaza una solicitud antes de generar nada, la API no devuelve un error. Devuelve un HTTP 200 normal con `stop_reason: "refusal"`, un array de contenido vacío y un objeto `stop_details` cuyo campo `category` nombra el área de política. El rechazo no lleva contenido, pero los recuentos de tokens siguen apareciendo en el uso, y la solicitud sigue contando para tus límites de velocidad. Según la nueva regla, en esas tres categorías, el rechazo también se cobra, a las tarifas del modelo que lo ejecutó.

Anthropic había eliminado los cargos por rechazos con cero salida el 2 de junio, en torno al lanzamiento de su producto Fable. Los rechazos a mitad de flujo, en los que el modelo empieza a responder y luego se detiene, siempre se facturaban. Los rechazos antes de cualquier salida en otras categorías, incluida ciberseguridad y daño general, siguen siendo gratuitos. El cambio se aplica en toda la API de Claude, Amazon Bedrock, Claude Platform en AWS, Google Cloud y Microsoft Foundry, y la documentación añade una advertencia de que las categorías facturadas pueden cambiar de nuevo.

Por qué la facturación es ahora un control de seguridad

La razón declarada por la empresa es que ha visto ataques coordinados contra sus sistemas en las últimas semanas. Una solicitud bloqueada que no cuesta nada es una sonda gratuita. Un atacante que quiera mapear la forma de un clasificador puede enviar miles de solicitudes y aprender de los rechazos sin pagar un céntimo. Poner precio al intento bloqueado exactamente en las tres categorías bajo ataque eleva el coste de ese mapeo, y Anthropic afirma explícitamente que el cargo pretende funcionar como una capa de defensa y no como una fuente de ingresos.

Dos cifras acompañaron el anuncio. En pruebas recientes, el 99,7 por ciento de las cuentas que usan Claude Code, Claude.ai o Cowork no alcanzó ninguno de los bloqueos recién facturables. Los clasificadores que hay detrás están ajustados a una tasa de falsos positivos inferior al 0,1 por ciento, y la publicación añade que la cifra no es cero y que los clasificadores seguirán mejorando para interrumpir el trabajo con menos frecuencia.

Los clasificadores se ejecutan en cuatro modelos de Claude: Fable 5.1, Fable 5, Opus 5.5 y Opus 5. La documentación nombra cinco categorías. Dos de ellas, ciberseguridad y daño general, no se facturan. Las tres que se facturan se corresponden con trabajo que los términos comerciales de Anthropic ya restringen, que es la razón por la que la tasa de falsos positivos es lo bastante baja para medirse: pocos clientes legítimos están entrenando modelos de frontera o pidiendo a un modelo que reproduzca su propio razonamiento interno.

Vale la pena detallar los ataques de destilación, porque el nombre hace mucho trabajo. El código de categoría es `reasoning_extraction`, y el comportamiento que apunta es pedir a un modelo que exponga su razonamiento interno paso a paso para que la salida pueda usarse para entrenar un sistema competidor. Es el mecanismo detrás de varias de las disputas por robo de modelos del último año, y es difícil separarlo de usuarios comunes que simplemente quieren que el modelo piense en voz alta.

Los falsos positivos ya son visibles

Las incidencias abiertas en el repositorio de claude-code en GitHub cuentan una historia diferente sobre la tasa. Un usuario registró 23 marcaciones en la categoría de extracción de razonamiento en trabajo ordinario, incluidos textos para pódcast y hojas de cálculo de presupuestos, y dijo que siete de ellas terminaron el turno. Otros informes describen tareas estándar de desarrollo de software y la propia documentación de flujo de trabajo de Claude Code activando el mismo bloqueo. Anthropic no ha explicado cómo funcionaría un reembolso por un bloqueo que resulta ser erróneo, más allá de remitir a los usuarios al comando `/feedback`.

Esa brecha es el problema práctico. Un desarrollador puede contar los eventos `stop_reason: "refusal"` y reintentar contra un modelo de respaldo, que es la solución documentada, y el acuerdo de crédito de respaldo no ha cambiado. Lo que no puede hacer fácilmente es saber, en el momento del cargo, si el bloqueo fue correcto. Si la respuesta llega más tarde, el dinero ya se ha movido, y una política de reembolsos que no se ha publicado no es algo con lo que un equipo financiero pueda presupuestar.

La respuesta a la publicación fue moderada más que enojada. En unas tres horas reunió alrededor de 1511 me gusta, 64 republicaciones y 220 respuestas en X, y el envío a Hacker News obtuvo cinco puntos y dos comentarios. La mayor parte de la discusión fue sobre el principio más que sobre el monto, lo que sugiere que el monto es lo bastante pequeño como para que pocos equipos lo noten en una factura.

Qué puede controlar realmente un equipo

Hay dos cosas en la documentación que vale la pena integrar en un pipeline. La primera es la categoría de rechazo, que llega como un campo legible por máquina, de modo que un servicio puede separar los rechazos de los errores en sus registros y contarlos por categoría a lo largo del tiempo, en lugar de descubrir el patrón durante una revisión trimestral. La segunda es la ruta de respaldo. El patrón documentado es reintentar una solicitud rechazada contra un modelo de respaldo, y Anthropic dice que el acuerdo de crédito de respaldo no ha cambiado, lo que significa que un reintento no paga dos veces por el mismo trabajo.

Ninguna de esas cosas resuelve el problema de los falsos positivos. Cuando una solicitud legítima se bloquea en una categoría facturada, el registro muestra un rechazo con un código de categoría y sin contenido, y la factura muestra un cargo. Un equipo que nunca lee ese campo solo descubrirá la tasa cuando alguien pregunte por qué se movió la factura.

El principio es la parte interesante

Todos los proveedores de modelos grandes hacen alguna versión de este cálculo. Los rechazos consumen cómputo, y un rechazo que un cliente puede activar a voluntad es una palanca que un atacante puede accionar. Cobrar por la solicitud rechazada traslada el coste de vuelta a quien la acciona.

El problema es que la misma palanca está al alcance de personas que no están atacando nada. Alguien que escribe un artículo de biología, o una startup que trabaja en técnicas de destilación de modelos, se sitúa en las categorías facturadas por la definición del trabajo y no por su intención. El propio enfoque de Anthropic es que la tasa de falsos positivos es lo bastante baja como para aceptarla, lo cual es un juicio hecho por la parte que cobra la tarifa.

Hay un diseño más limpio disponible, y Anthropic lo ha construido en parte. El campo `stop_details.category` es legible por máquina, así que un equipo puede enviar los rechazos a un registro, contarlos por categoría y auditarlos de forma agregada. Las respuestas rechazadas también aparecen en los registros de uso con recuentos de tokens adjuntos, lo que significa que los datos que necesitaría una disputa ya se están registrando. Si eso se convierte en una parte normal de ejecutar Claude en producción, o se queda como una nota al pie que la mayoría de los equipos nunca lee, decide cuánto cuesta el cambio de facturación por encima de la línea de la factura.