Claude cobra los rechazos de su API: qué cambia

El 24 de septiembre Anthropic amplió qué rechazos factura la API de Claude: los que llegan antes de escribir una sola palabra ya se cobran cuando la categoría es «bio», «frontier_llm» o «reasoning_extraction». Te toca si tu negocio tiene un asistente o una automatización sobre esa API. Las dos categorías que de verdad puede disparar un negocio normal siguen sin facturarse, así que el cambio se nota poco en la factura y bastante en cómo está programada tu automatización.

Las dos fuentes de este artículo son de Anthropic, están en inglés y la traducción es propia; el original va entre comillas cuando la literalidad importa. Al final está declarado cómo se ha leído cada una.

Qué ha cambiado exactamente

Un criterio de facturación, no un precio. La entrada del 24 de septiembre de las notas de versión de la API de Claude lo dice así: «We're expanding which refusals are billed to include refusals that arrive before any output when stop_details.category is "bio", "frontier_llm", or "reasoning_extraction", the categories where we measure low volumes of false positives». Es decir: se amplía qué rechazos se facturan para incluir los que llegan antes de cualquier salida cuando la categoría es una de esas tres, las categorías donde Anthropic mide pocos falsos positivos.

Para entender por qué esto importa hay que saber qué es un rechazo en la API de Claude, y no es lo que parece. Según la documentación de rechazos y modelo de reserva, «a refusal is a successful HTTP 200 response with stop_reason: "refusal"»: un rechazo es una respuesta correcta, con código 200, en la que el campo stop_reason vale refusal. El contenido llega vacío y la explicación viaja en un objeto llamado stop_details, con dos campos: category, que nombra el área de la política de uso que se activó, y explanation, un texto legible que la propia documentación pide mostrar y no analizar, porque «the text is not stable».

Las cinco categorías, y cuáles se pagan

La documentación enumera cinco categorías de rechazo y marca cuáles se facturan cuando el rechazo llega antes de producir nada. Estas son, con la descripción de Anthropic traducida:

«cyber» — la petición podría facilitar un daño informático, como desarrollar malware o un exploit. No se factura. Y avisa: «Benign cybersecurity work can also trigger this category», el trabajo legítimo de ciberseguridad también puede activarla.
«bio» — la petición podría facilitar un daño biológico, como métodos de laboratorio peligrosos. Sí se factura desde ahora. También puede saltar con trabajo legítimo de ciencias de la vida.
«frontier_llm» — la petición podría ayudar a desarrollar modelos de IA competidores, algo que las condiciones comerciales de Anthropic restringen. Sí se factura desde ahora. Puede saltar con trabajo legítimo de aprendizaje automático.
«reasoning_extraction» — la petición pide al modelo que reproduzca su razonamiento interno en el texto de la respuesta. Sí se factura desde ahora.
«general_harms» — la petición cae en un área de la política de uso fuera de las cuatro anteriores. No se factura. Y la misma advertencia: «Benign work can also trigger this category».

Ahí está el reparto que cambia la lectura del titular. Las tres que empiezan a pagarse son las tres que un negocio corriente no toca: virología, entrenar modelos de la competencia y sonsacarle el razonamiento interno al modelo. Las dos que un asistente de atención al cliente puede disparar por error —cyber con una consulta técnica y general_harms con cualquier cosa rara— siguen sin facturarse.

Qué no cambia

Cuatro cosas, y conviene tenerlas claras antes de mirar la factura con lupa:

Los rechazos a mitad de respuesta ya se cobraban. La nota lo dice: «Mid-stream refusals were already billed». Si el modelo empezó a escribir y se detuvo, se facturan la entrada y lo que ya salió, a tarifa normal.
El crédito del modelo de reserva sigue igual. «Fallback credit is unchanged». Ese crédito compensa el fallo de caché del reintento, para no pagar dos veces por cachear la misma conversación.
Un rechazo siempre consumía cupo. Facturado o no, «the request still counts against your rate limits»: sigue contando contra tus límites de peticiones, como antes.
Si usas Claude desde la aplicación o desde una suscripción, esto no va contigo. La documentación acota las plataformas afectadas: «the Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud, and Microsoft Foundry». Todas son facturación por token. Un plan Pro o Max se paga por cuota mensual y no aparece en esa lista.

Cuánto cuesta de verdad un rechazo

Aquí entra un cálculo propio, y lo marcamos como tal porque Anthropic no publica esta cuenta.

Un rechazo anterior a cualquier salida tiene cero tokens de salida: el ejemplo de la documentación muestra "output_tokens": 0. Y los rechazos facturados se cobran «at the rates of the model that ran it», a la tarifa del modelo que atendió la petición. Traducido: pagas la entrada y nada más.

Pongamos una automatización que envía 3.000 tokens de entrada por llamada, algo normal cuando el mensaje del cliente va acompañado de instrucciones e historial. Con la tarifa oficial de modelos del día de publicación, y sin contar aciertos de caché, que abaratan la entrada:

Con Claude Sonnet 5, a 2 dólares por millón de tokens de entrada, cada rechazo facturado cuesta 0,006 dólares. Cien rechazos, 0,60 dólares.
Con Claude Fable 5.1, a 10 dólares por millón, cada uno cuesta 0,03 dólares. Cien rechazos, 3 dólares.

Los precios de Anthropic están en dólares y no hay tarifa equivalente en euros en esa página, así que los dejamos como están, sin convertir ni añadir impuestos. Y la conclusión es la que parece: para un negocio pequeño, el impacto en la factura de este cambio es de céntimos. El motivo es que las tres categorías que ahora se pagan casi nunca aparecen en un caso de uso comercial.

El problema real no es la factura: es el HTTP 200

Esta es la parte que sí merece veinte minutos esta semana, y no la trae la noticia: la trae el funcionamiento que la noticia obliga a leer.

Un rechazo es una respuesta correcta. Código 200, sin error, con el contenido vacío. Una automatización que solo comprueba si la llamada ha fallado va a interpretar ese rechazo como un éxito, va a coger un contenido que no existe y va a mandarle al cliente un mensaje en blanco, o un error interno con mala cara. No hay traza en el registro de errores, porque para el servidor no hubo ninguno.

Y es un fallo silencioso: nadie se enterará hasta que un cliente lo diga. La documentación avisa además de que si el rechazo llega a mitad de respuesta hay que descartar lo escrito, porque «treat any partial output as incomplete»: tratar cualquier salida parcial como incompleta. Un asistente que envía medio mensaje truncado es peor que uno que no contesta.

Imagínalo en una clínica dental con un asistente de WhatsApp montado sobre la API. Alguien escribe a las once de la noche una consulta larga y confusa, mezcla de síntoma y desahogo. El modelo la clasifica en general_harms y rechaza. No se factura, así que en la factura no hay rastro. El paciente recibe un mensaje vacío, piensa que la clínica no funciona y a la mañana siguiente llama a otra. El coste real de ese rechazo no fueron 0,006 dólares: fue una primera visita.

Qué hacer esta semana

Busca el motivo de parada en el código de tu asistente. El campo se llama stop_reason. Si no aparece en ninguna parte, tu automatización no distingue un rechazo de una respuesta buena. Si no lo mantienes tú, es la pregunta exacta que hay que hacerle a quien lo mantiene.
Guarda la categoría del rechazo en el registro cada vez que haya uno. Es el campo stop_details.category, y es un campo, no un proyecto. Sin él no vas a saber nunca si tus rechazos son de los que se pagan o de los que no, ni si ese reparto cambia.
Escribe un mensaje de reserva para el cliente. Cualquier cosa humana antes que el silencio: que no se ha podido procesar la consulta y que alguien la mira en horario de atención. El silencio no es neutro.
No construyas lógica sobre el texto de la explicación. Ese campo se llama explanation y la documentación dice que su texto no es estable. Decide por la categoría, que sí lo es.
Mira la factura sin alarmarte. Si aparece una subida, este cambio no es la explicación probable. Tres categorías improbables a tarifa de entrada no mueven una factura.

El análisis de PotencIA

Lo primero, separado del hecho: Anthropic explica para qué cobra, y es una frase poco habitual en una nota de facturación. Dice «to disrupt attempts to circumvent Anthropic's safeguards at scale», para frustrar los intentos de burlar sus salvaguardas a gran escala. No es un ajuste de ingresos: es poner un coste a la fuerza bruta. Quien prueba diez mil variantes de la misma petición prohibida hasta que una pasa, paga las diez mil. Quien tiene un negocio no prueba ninguna.

Lo segundo, que es nuestra lectura y no un dato: la lista es provisional y lo dice el propio documento. Las tres categorías facturadas son las de pocos falsos positivos «as of September 2026», a fecha de septiembre de 2026, y «the billed categories may change as Anthropic keeps measuring and refining its safeguards' false positive rates», la lista puede cambiar a medida que Anthropic siga midiendo. Es decir: hoy cyber y general_harms no se pagan porque el clasificador se equivoca demasiado con ellas. El día que afine, pueden entrar. Por eso el punto 2 de la lista de arriba no es burocracia: el registro de categorías que montes hoy es lo que te dirá si ese día te afecta o no.

Y lo tercero, que es el criterio con el que montamos las automatizaciones de WhatsApp con IA de PotencIA: una automatización de negocio no se juzga por lo que hace cuando todo va bien, sino por lo que hace cuando el modelo no contesta. Un rechazo, una caída de la API, un tiempo de espera agotado. Los tres se parecen desde fuera —el cliente no recibe nada— y los tres se arreglan igual: detectarlo, registrarlo y decir algo. Si al conectar el canal con el CRM por la API oficial no queda registrado qué pasó con los mensajes que no se contestaron, esa conversación no existe para el negocio.

Esta noticia es, en el fondo, una buena excusa. Nos ha llegado como un cambio de facturación de céntimos y sirve para revisar el camino de error de una automatización, que es donde casi nadie mira. El otro lado de esa cuenta, el precio por token cuando todo funciona, lo repasamos al cubrir la bajada de precio de la API de OpenAI con GPT-6 Sol y Luna. Y si lo que usas es la aplicación y no la API, el cambio relevante de estas semanas era qué entra y qué no en cada plan de Claude.

Cómo se ha verificado esto

Las dos fuentes se han reabierto hoy, 25 de septiembre, y ambas responden con HTTP 200 a la lectura directa, sin necesidad de rodeos.

Las notas de versión de la API de Claude traen la entrada fechada el 24 de septiembre de 2026 como la más reciente de la página, por delante de la del 23 de septiembre, sobre diagnóstico de caché, y la del 22, sobre el lanzamiento de Claude Opus 5.5. Esa fecha explícita es la que sitúa el cambio dentro de la ventana de 24 horas de este carril; no se ha usado ninguna marca de tiempo relativa.

La documentación de rechazos y modelo de reserva es la que enlaza la propia nota de versión con el texto «See How refusals are billed». De ella salen la definición del rechazo como respuesta 200, el ejemplo con cero tokens de salida, la tabla de cinco categorías con la columna de qué se factura antes de cualquier salida, la lista de plataformas afectadas y las dos advertencias sobre el texto de explanation y las salidas parciales.

Los precios por millón de tokens proceden de la página oficial de tarifas de modelos de Anthropic, consultada hoy. La cuenta de lo que cuesta un rechazo es nuestra, no de Anthropic: multiplica los tokens de entrada del ejemplo por la tarifa de entrada publicada y da por hecho que no hay aciertos de caché. El caso de la clínica dental es un ejemplo construido para explicar el fallo silencioso, no un incidente de un cliente.

No se ha usado ningún medio ni ningún resumen de terceros. Tampoco se ha consultado ninguna herramienta de indexación ni de rendimiento en buscadores para esta pieza.

Fuentes consultadas

Notas de versión de la API de Claude, entrada del 24 de septiembre de 2026, consultada el 25 de septiembre: ampliación de los rechazos facturados a las categorías «bio», «frontier_llm» y «reasoning_extraction», y confirmación de que los rechazos a mitad de respuesta ya se facturaban y el crédito de reserva no cambia.
Rechazos y modelo de reserva, documentación de Claude, consultada el 25 de septiembre: definición del rechazo como respuesta HTTP 200 con stop_reason igual a refusal, las cinco categorías y cuáles se facturan, el apartado «How refusals are billed», las plataformas donde aplica y el aviso sobre las salidas parciales.
Tarifa de modelos de Claude, consultada el 25 de septiembre: precios de entrada y salida por millón de tokens, en dólares, de Claude Sonnet 5 y Claude Fable 5.1.
Gestión de rechazos en respuestas en streaming, documentación de Claude, consultada el 25 de septiembre: comprobación de que el tratamiento de un rechazo a mitad de respuesta tiene guía propia y no se limita a la nota de versión.