Claude Fable 5.1: cuándo la caché y el lote reducen el coste por tarea —y cuándo solo desplazan la factura

Alcance: comparar modalidades sin trasladar precios entre canales

Claude Fable 5.1 se ofrece en varios canales, entre ellos Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry y Claude Platform on AWS. La comparación de esta guía se limita a las reglas y precios documentados para la plataforma directa de Anthropic. No es válido copiar esas tarifas a Amazon Bedrock ni a otro proveedor cloud: la documentación de precios indica que Bedrock y Google Cloud aplican precios regionales independientes.

La documentación del modelo sitúa el lanzamiento de Claude Fable 5.1 el 1 de septiembre de 2026, declara una ventana de contexto de un millón de tokens y una salida máxima de 128.000 tokens. Estos límites pueden condicionar tanto el diseño de las solicitudes como la factura: un contexto que cabe en teoría no necesariamente puede enviarse con la frecuencia, concurrencia o plazo requeridos.

Por tanto, el objetivo no es establecer que una modalidad sea universalmente más barata. Es construir un cálculo comparable para una carga concreta y medir el coste de una tarea que termina correctamente. Ese coste incluye tokens, reintentos, validación, recuperación de fallos y, cuando el producto lo necesita, el coste operativo de esperar una respuesta asíncrona. Una factura menor por tokens no prueba por sí sola menor coste total, mejor resultado ni menor revisión humana.

Qué se factura en Claude Fable 5.1

En la plataforma directa, la tabla específica de Claude Fable 5.1 documenta 10 USD por millón de tokens de entrada estándar y 50 USD por millón de tokens de salida. Una escritura de caché con duración de cinco minutos cuesta 12,50 USD por millón de tokens; una escritura de una hora, 20 USD por millón. Las lecturas de caché cuestan 0,25 USD por millón de tokens. Estas cantidades son datos de la documentación aportada y deben volver a verificarse antes de implantar un presupuesto, porque los precios y las condiciones comerciales pueden cambiar.

Una escritura de caché es el procesamiento inicial del prefijo de prompt que queda disponible para reutilización. Una lectura se produce cuando una solicitud posterior coincide con ese prefijo almacenado y puede usarlo. El tiempo de vida empieza cuando la caché se crea. La duración de cinco minutos y la de una hora no son una reserva de capacidad ni garantizan por sí mismas que haya reutilización: si la siguiente llamada llega tarde, cambia el prefijo pertinente o no obtiene un acierto, el ahorro esperado no se materializa.

La salida no recibe por ello una rebaja de caché. Un agente que produce explicaciones, parches o informes extensos puede conservar una factura alta incluso con una tasa de acierto excelente. También hay que contabilizar la parte dinámica del prompt: solo el prefijo realmente reutilizado puede beneficiarse de la lectura; instrucciones o contexto añadidos después continúan facturándose como entrada normal.

Batch API procesa solicitudes de forma asíncrona y la documentación indica un descuento del 50 % respecto a los precios estándar. La caché y Batch pueden acumular descuentos. Sin embargo, un descuento de precio no convierte Batch en sustituto de una ruta interactiva: el lote tiene un plazo de expiración y una disciplina operativa propia. El equipo debe comprobar si el trabajo puede esperar y cuánto cuesta reenviar, corregir o investigar los elementos que no terminen como se esperaba.

La unidad útil: coste por tarea completada correctamente

El coste por llamada es una señal incompleta. Una tarea puede requerir varios turnos, una comprobación automática, revisión de un resultado estructurado, una llamada de recuperación o un reintento por límite de capacidad. Además, una respuesta recibida dentro de un plazo que ya no sirve al producto puede tener poco valor operacional aunque haya sido barata.

Defina una tarea terminada correctamente antes de comparar modalidades. Por ejemplo, en un agente de ingeniería puede ser una propuesta que supera pruebas y validación de política; en un asistente sobre documentos, una respuesta que respeta el formato y tiene evidencia recuperable; en una cola nocturna, un registro procesado antes de la hora de entrega y aceptado por controles posteriores. Registre por separado los errores técnicos, los resultados inválidos y los trabajos que requieren intervención humana.

Para una ventana de análisis, una medida práctica es: coste total de solicitudes, reintentos, validación y recuperación dividido entre tareas aceptadas. Si se desea aislar el coste del modelo, deje fuera salarios y sistemas externos, pero no esconda los reintentos ni las llamadas de corrección. Si se desea decidir arquitectura de producto, añada esos componentes y el coste de incumplir el plazo mediante una hipótesis explícita y revisable.

Modelo parametrizable para llamada normal, caché y lote

Use importes en dólares por token, no por millón, dentro de una hoja de cálculo: entrada estándar e = 10/1.000.000; salida s = 50/1.000.000; escritura de cinco minutos w5 = 12,50/1.000.000; escritura de una hora w60 = 20/1.000.000; lectura r = 0,25/1.000.000. Para cada grupo de solicitudes con el mismo prefijo reutilizable, defina P como tokens del prefijo, D como entrada dinámica media por llamada, O como salida media y N como número de llamadas realizadas antes de expirar la entrada de caché.

Sin caché, el coste del grupo es N multiplicado por P más D, todo por e, más N multiplicado por O por s. Con caché de cinco minutos, el coste aproximado es P por w5, más N por P por r, más N por D por e, más N por O por s. Con caché de una hora se sustituye w5 por w60. Estas fórmulas suponen un acierto de lectura para todas las llamadas posteriores y una sola escritura inicial; son un escenario idealizado, no una garantía.

Para incorporar una tasa observada de acierto H, sustituya N por H multiplicado por N en el término de lectura y añada para las llamadas no acertadas el coste de entrada correspondiente. La implementación exacta debe seguir cómo su aplicación agrupa prefijos y cómo la API reporta el uso. También conviene separar prefijos distintos: promediar un corpus muy reutilizado con solicitudes únicas puede ocultar que la caché solo funciona en una parte de la carga.

Para Batch, aplique el descuento documentado del 50 % a los componentes aplicables del modelo de su canal directo, y agregue el coste de reenvíos y validación. No suponga que todos los trabajos de una cola nocturna son equivalentes: los que vencen, requieren prioridad o sufren correcciones pueden acabar en otra ruta con otra tarifa.

Tres flujos reproducibles para medir el solapamiento real

Caso uno: agente de ingeniería. Separe el prompt en instrucciones y políticas estables, estado de repositorio que cambia con una cadencia conocida y petición puntual del usuario. No asuma que todo el repositorio debe o puede estar en el prefijo. Mida cuántos tokens del bloque estable se repiten de forma idéntica, cuántas acciones ocurren dentro del TTL y cuántos turnos rompen la coincidencia por cambios de estado. Registre también los reintentos causados por validaciones de herramientas, pruebas fallidas o respuestas que exceden el presupuesto de salida.

Caso dos: asistente que responde sobre un corpus estable. Un corpus común y unas instrucciones fijas son candidatos naturales a caché, pero el análisis debe distinguir entre el corpus completo enviado, el fragmento recuperado para cada pregunta y el historial conversacional. Si cada pregunta usa una selección documental distinta, el volumen aparentemente estable puede tener poco solapamiento exacto. Construya grupos por versión de corpus y por prefijo, no una tasa global de aciertos que mezcle comportamientos incompatibles.

Caso tres: análisis nocturno. Agrupe trabajos que no necesiten respuesta interactiva y mida el porcentaje que cumple su hora de entrega usando Batch. Compare el ahorro facturado con el coste de excepciones: elementos urgentes que salen del lote, reenvíos, errores de formato y trabajos que caducan. Si el flujo requiere un resultado antes de iniciar procesos posteriores, el tiempo de cola es parte de su coste operativo aunque no figure como token.

En los tres casos, el contador de tokens de uso es la fuente para reconstruir lo cobrado por modalidad. La documentación de límites explica que varias categorías de tokens cuentan para el presupuesto de tokens de entrada por minuto y proporciona una fórmula para reconstruir la entrada total a partir de los datos de uso. Esa información sirve tanto para prever capacidad como para detectar por qué una estrategia barata en papel provoca esperas o reintentos.

Límites, plazos y condiciones que cambian la elección

La capacidad disponible puede invalidar una decisión basada solo en precio. La documentación de la API distingue límites de solicitudes por minuto, tokens de entrada por minuto y tokens de salida por minuto. Los tokens asociados a caché importan para esos cálculos. Un diseño que concentra muchas escrituras o entradas grandes puede chocar con los límites, aumentar la cola propia o inducir reintentos; en ese caso, el coste observado por tarea puede crecer aunque la tarifa teórica sea baja.

Batch también tiene límites de cola documentados y un plazo de expiración. Antes de migrar una cola, mida su distribución de edades y determine qué parte puede esperar sin afectar dependencias. Establezca una ruta de excepción para los trabajos urgentes y presupuéstela por separado. Una cola única que mezcla trabajos de distinta urgencia hace difícil atribuir tanto el ahorro como el incumplimiento de plazo.

Los aciertos de caché son de mejor esfuerzo y dependen del patrón de tráfico, según la documentación de Batch. Trátelos como un resultado medible, no como una capacidad contratada. Diseñe la aplicación para que una ausencia de acierto siga siendo correcta funcionalmente y para que el presupuesto cubra el escenario con menor reutilización razonable.

La residencia de datos puede introducir un multiplicador de precio según las reglas comerciales documentadas. Si es relevante para su entorno, incorpórelo en todos los términos de la hoja de cálculo antes de comparar alternativas. No se debe aplicar selectivamente a una modalidad para hacerla parecer más atractiva.

Conclusión: un ahorro verificable requiere segmentación y control de resultados

Claude Fable 5.1 puede reducir de forma sustancial la parte de entrada en flujos que reutilizan un prefijo grande, estable y leído varias veces dentro de su TTL. La caché de cinco minutos suele ser el primer punto de comparación cuando las solicitudes están concentradas; la de una hora requiere demostrar que su escritura más cara evita suficientes escrituras o habilita reutilización que de otro modo se perdería. Batch merece una evaluación separada para trabajo diferible, no una conversión automática de toda la carga.

La decisión robusta no parte de un único precio por millón de tokens. Parte de grupos de solicitudes reales, campos de uso de la API, tasa de acierto, tiempo hasta la reutilización, salida, reintentos, trabajos aceptados y plazo. Con estos datos, la organización puede fijar un umbral explícito: adoptar una modalidad solo si reduce el coste por tarea correcta y mantiene el servicio dentro de sus objetivos operativos.

Finalmente, una reducción de factura no permite concluir que el modelo responda con más calidad, que el usuario perciba menos latencia o que disminuya la revisión humana. Esas variables deben medirse con evaluaciones y métricas separadas. Tampoco permite inferir precios equivalentes en Bedrock u otros canales cloud. La incertidumbre debe quedar visible en el tablero y en cualquier decisión financiera basada en esta guía.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.