Claude Fable 5.1: la noticia no es el benchmark, es que las cache reads bajan un 75%
Anthropic lanzó Claude Fable 5.1 el 1 de septiembre de 2026. Titulares habrá muchos sobre lo que sube en los benchmarks. El dato que de verdad cambia cómo sale la cuenta de un agente en producción es otro y casi nadie lo pone en portada: leer de caché pasa de 1,00 $ a 0,25 $ por millón de tokens, un 75 % menos. Si construyes o mantienes agentes con contexto largo, eso te importa más que cualquier gráfica.
Qué ha pasado
El 1 de septiembre Anthropic presentó Fable 5.1 (y su gemela con menos guardarraíles, Mythos 5.1, solo por acceso restringido). El precio de tokens "normales" no se mueve: sigue en 10 $/millón de input y 50 $/millón de output. La ventana de contexto se mantiene en 1 millón de tokens de entrada y 128K de salida.
Lo que baja es la lectura de caché: de 1,00 $ a 0,25 $ por millón de tokens cacheados, es decir, un 2,5 % del precio del input normal (antes era el 10 %). Anthropic traduce ese cambio a coste efectivo: ~25 % menos para cargas típicas y hasta ~45 % menos para cargas "altamente agénticas" (anuncio oficial). En rendimiento, sí, también mejora —Terminal-Bench 4.0 55,8 % frente a 42,0 % de Fable 5, AutomationBench 31,4 % frente a 17,1 %— pero esa parte es la esperada en cada iteración. La sorpresa es la de la factura.
Por qué las cache reads deciden tu factura (y no el precio de input)
En una llamada de un solo turno —clasificar un texto, extraer un campo— pagas input una vez, output una vez, y se acabó. Ahí el precio de la caché es irrelevante.
Un agente en producción no funciona así. Un bucle agéntico reenvía en cada paso el system prompt, las definiciones de herramientas y todo el historial acumulado. Con prompt caching, ese prefijo estable se cachea y se relee barato en cada iteración. En una tarea de horizonte largo —un agente de coding que ejecuta 40 pasos, un flujo de automatización con muchas tool calls— el volumen de tokens leídos de caché supera con creces al de tokens frescos. Dicho de otro modo: en agentes, la mayor parte de lo que pagas son cache reads, no input nuevo.
Por eso un recorte del 75 % justo ahí no es cosmético. Es la diferencia entre estos dos escenarios para el mismo agente:
| Concepto | Fable 5 | Fable 5.1 |
|---|---|---|
| Input normal (sin caché) | 10 $ / 1M | 10 $ / 1M |
| Lectura de caché | 1,00 $ / 1M | 0,25 $ / 1M |
| Output | 50 $ / 1M | 50 $ / 1M |
| Coste efectivo, carga agéntica | referencia | ~45 % menos |
El precio de portada (10 $/50 $) no ha cambiado. Tu factura, si tu carga es agéntica, sí.
Qué implica para tu producto
El ahorro no llega solo: hay que arquitecturarlo. Ese 45 % es el techo, y solo lo tocas si tu contexto está diseñado para acertar en caché. Tres reglas que aplicamos cuando montamos un agente pensando en coste:
- Prefijo estable y append-only. Todo lo que no cambia —system prompt, herramientas, contexto estático— va primero y no se toca. Lo volátil, al final. Si reordenas o editas algo del principio, invalidas el prefijo cacheado y vuelves a pagar input completo.
- Puntos de corte de caché deliberados, no por defecto. Marca dónde termina la parte reutilizable entre turnos.
- Mide el cache hit rate, no solo el gasto total. Si tu ratio de aciertos es bajo, el problema no es el modelo: es cómo montas el contexto. Es ingeniería de contexto aplicada a la factura.
Esto conecta directamente con lo que ya contamos sobre controlar el coste de tokens en producción: el modelo cambia cada pocas semanas, pero la disciplina de diseñar el contexto para que la caché trabaje a tu favor es la que sobrevive a las iteraciones.
Nuestra recomendación (para quién sí y para quién no)
Sí, mueve la aguja si: tienes agentes multi-turno o de horizonte largo en producción, con un prefijo grande y reutilizable (definiciones de herramientas, documentación, contexto de negocio) que se relee decenas de veces por ejecución. Ahí el recorte de cache reads es dinero real y recurrente, y merece revisar tu diseño de contexto esta misma semana.
No te obsesiones si: tu carga son llamadas cortas de un solo turno o el contexto cambia entero en cada petición. Ahí la caché apenas se usa, el ahorro real se acerca al 25 % "típico", no al 45 %, y reestructurar toda tu arquitectura persiguiendo cache hits es optimizar donde no duele.
Dos matices honestos antes de migrar. Primero: escribir en caché tiene un sobrecoste sobre el input normal, así que cachear solo compensa cuando el prefijo se reutiliza lo suficiente; para prefijos muy variables o tráfico bajo, la caché puede salir más cara que no usarla. Segundo: no migres a ciegas por un titular de coste. Un modelo más barato que te obliga a más reintentos o más verificación puede salir más caro en total. Válidalo contra tus propios evals, no contra el benchmark del vendor.
Nosotros, con un cliente con agentes ya en producción, no cambiaríamos de modelo el lunes por la mañana. Revisaríamos primero el diseño de contexto y el cache hit rate —donde suele estar el ahorro más grande e independiente del modelo— y luego mediríamos Fable 5.1 sobre la tarea real. El orden importa: la arquitectura primero, el precio de lista después.
¿Tienes agentes en producción y no sabes qué parte de tu factura son cache reads mal aprovechadas? Hablémoslo: esa foto suele pagarse sola.
