Caché de Claude Fable 5: mismo contrato, factura 2.9x mayor que con Opus 4.6
Contenido
claude-fable-5 ya está disponible en el gateway de Synthorai. Si usas caché con la familia Claude, el contrato de caché y TTL no cambia: los mismos marcadores cache_control, los mismos TTL de 5 minutos y 1 hora, los mismos recargos de escritura y el mismo descuento elevado en las lecturas. Para migrar el código de caché solo hay que cambiar un string.
Lo que debes recalcular no es el funcionamiento de la caché, sino la factura. El precio por token de Fable 5 es 2x el de Opus, y el mismo texto en inglés genera ~45% más tokens que en Opus 4.6 porque usa el tokenizer posterior a 4.6, idéntico al de Opus 4.8. Ambos factores se multiplican. En este artículo medimos su impacto completo.
Antes de migrar, revisa también una restricción ajena a la caché: Fable 5 no puede ejecutarse con retención de datos cero. En todos los proveedores cloud donde está disponible es obligatoria una retención de datos de 30 días.
TL;DR
- Claude Fable 5 mantiene sin cambios el contrato de caché de Anthropic: los mismos marcadores
cache_control, TTL de 5 minutos y 1 hora, recargos de escritura de aproximadamente 1.25x/2x y, según nuestras mediciones, lecturas en caliente a cerca del 6% del precio sin caché. - El mismo texto genera 9,619 tokens en Fable 5 y Opus 4.8, frente a 6,614 en Opus 4.6: un 45% más.
- El precio de Fable 5 es de $10/M para input y $50/M para output, 2x la tarifa de Opus.
- Por tanto, el mismo prompt cuesta 2.9x más que en Opus 4.6 (1.45 tokens x 2.0 precio), según la medición del 2026-06-10.
Todas las cifras siguientes se midieron contra
https://synthorai.io/(endpoint nativo de Anthropic/v1/messages) el 2026-06-10, con un system prompt estable en inglés de ~6.6–9.6K tokens, un valor pequeño demax_tokensy una única ejecución secuencial. Los costes proceden del campousage.costdel gateway. La parte extrapolable son las proporciones —número de tokens, recargo de escritura, descuento de lectura y coste entre modelos—, ya que los importes absolutos dependen del tamaño del prompt. Repite las pruebas con tu propio prompt antes de citar estas cifras.
Disponibilidad
import os
from anthropic import Anthropic
anth = Anthropic(
api_key=os.environ["SYNTHORAI_KEY"],
base_url="https://synthorai.io/", # SDK appends /v1/messages
)
msg = anth.messages.create(
model="claude-fable-5", # the only line that changes
max_tokens=512,
system=[
{"type": "text", "text": SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"}},
],
messages=[{"role": "user", "content": question}],
)
print(msg.usage) # input_tokens, cache_creation_input_tokens, cache_read_input_tokens, cost
Sustituye claude-opus-4-6 → claude-fable-5 y no tendrás que modificar nada más en la lógica de caché. Fable 5 es un modelo nativo de Anthropic con una ventana de contexto de 1M tokens. Hay un comportamiento que debes tener en cuenta: es un modelo de razonamiento y genera thinking tokens por defecto. En nuestras pruebas, incluso una instrucción trivial como «reply OK» devolvió output_tokens_details.thinking_tokens > 0, mientras que Opus 4.6/4.8 devolvieron cero. Incluye esos tokens de output en el presupuesto. El funcionamiento de cache_control se explica en el tutorial de caché, y la arquitectura que justifica la existencia de esta caché se aborda en la Parte 1 de la serie.
El dato clave: Fable 5 usa el nuevo tokenizer
El número de tokens en la familia Opus aumentó a partir de la generación 4.7: el mismo texto en inglés que ocupaba ~6.6K tokens en 4.6 pasa a ~9.6K en 4.8. Fable 5 usa el nuevo tokenizer y devuelve exactamente el mismo número de tokens que Opus 4.8 para un texto idéntico.
| Modelo | Tokens de input (texto idéntico) | Generación del tokenizer |
|---|---|---|
claude-opus-4-6 | 6,614 | anterior a 4.7 |
claude-opus-4-8 | 9,619 | posterior a 4.7 |
claude-fable-5 | 9,619 | posterior a 4.7 (idéntico a 4.8) |
El mismo system prompt ocupa ~45% más tokens en Fable 5 que en Opus 4.6 (9,619 / 6,614 = 1.45). Es la cifra principal que debes tener presente antes de migrar, porque todos los cálculos posteriores —coste, mínimo de 1,024 tokens para poder usar caché y presupuesto por llamada— dependen del número de tokens.
Se trata de una observación medida: con un texto idéntico, Fable 5 y Opus 4.8 devuelven exactamente el mismo número de tokens, ~45% más que Opus 4.6. El resultado encaja con la actualización del tokenizer y del vocabulario introducida en la generación 4.7. Si migras desde 4.6 o una versión anterior, vuelve a medir. Si vienes de 4.7/4.8, el recuento debería ser equivalente.
Comportamiento de la caché: el contrato no cambia
Ejecutamos la misma secuencia sin caché / escritura en frío / lectura en caliente en cada modelo. La estructura de descuentos es idéntica de principio a fin. Fable 5 respeta cache_control y devuelve los mismos campos de uso (cache_creation_input_tokens, cache_read_input_tokens y los buckets ephemeral_5m / ephemeral_1h).
| Modelo | Escritura en caché de 5m | Escritura en caché de 1h | Lectura en caliente |
|---|---|---|---|
claude-opus-4-6 | 1.25x | 2.00x | ~9% del coste sin caché |
claude-opus-4-8 | 1.25x | 2.00x | ~6% del coste sin caché |
claude-fable-5 | 1.24x | 1.99x | ~6% del coste sin caché |
Los tres modelos mantienen dos constantes:
- Recargo de escritura ≈ 1.25x (5m), ≈ 2x (1h). La primera llamada, con la caché en frío, cuesta ~1.25x el precio sin caché al crear una entrada de 5 minutos, o ~2x para una entrada de 1 hora. Basta un acierto para amortizarla.
- Descuento de lectura ≈ 90%+. En Fable 5, una lectura con la caché en caliente costó ~6% de la llamada sin caché, es decir, un descuento de ~94%. El resultado está en línea con la reducción de ~90% documentada por Anthropic para las lecturas en caché, y es ligeramente mejor. Las lecturas conservan este fuerte descuento con ambos TTL.
Los porcentajes son estables en toda la familia. Igual que al pasar de Opus 4.7 → 4.8, el mayor importe absoluto de Fable 5 se debe al precio y al número de tokens, no a la economía de la caché. Lo analizamos en la siguiente sección.
Comportamiento del TTL: admite ambos intervalos
Fable 5 admite los mismos dos TTL que el resto de la familia: un valor predeterminado deslizante de 5 minutos y una ventana opcional de 1 hora. Aislamos cada TTL usando un prefijo único por llamada para evitar que una entrada anterior alterase el resultado. El objeto de uso devolvió el bucket correcto: cache_creation.ephemeral_5m_input_tokens o ephemeral_1h_input_tokens.
# 1-hour TTL — same marker syntax on Fable 5 as on the Opus line
"cache_control": {"type": "ephemeral", "ttl": "1h"}
La escritura con TTL de 1 hora cuesta ~2x el precio sin caché, frente a ~1.25x para la escritura de 5 minutos. Las lecturas mantienen el mismo descuento elevado con ambos TTL, igual que en Opus 4.6/4.8. Si en Opus elegiste 5m para chat en tiempo real y 1h para agentes con pausas de intervención humana, mantén esas opciones en Fable 5.
El coste: precio 2x x tokens 1.45x
Aquí está la diferencia real de Fable 5. La factura aumenta por dos factores que se multiplican.
1. El precio de tarifa es 2x el de Opus.
| Modelo | Input ($/M) | Output ($/M) | Lectura de caché ($/M) |
|---|---|---|---|
claude-opus-4-6 / 4-8 | 5 | 25 | 0.5 |
claude-fable-5 | 10 | 50 | 1 |
2. El mismo texto ocupa ~45% más tokens que en 4.6 debido al cambio de tokenizer descrito anteriormente.
Al multiplicar ambos factores, el mismo prompt en inglés resulta mucho más caro. Estos son los valores medidos con un system prompt idéntico en cada modelo, a partir de usage.cost del gateway y con una única ejecución:
| Comparación | Proporción de tokens | Proporción de precio | Proporción de coste para el mismo prompt (medida) |
|---|---|---|---|
| Fable 5 frente a Opus 4.8 | 1.00x | 2.0x | 2.0x |
| Fable 5 frente a Opus 4.6 | 1.45x | 2.0x | 2.9x |
Frente a Opus 4.8, que usa el mismo tokenizer, Fable 5 cuesta exactamente 2x: la diferencia se debe únicamente al precio. Frente a Opus 4.6, el cambio de tokenizer se suma al cambio de precio y eleva el coste del mismo prompt a aproximadamente 2.9x. El descuento de caché no cambia, pero la base absoluta sobre la que se aplica es ~2.9x mayor que en 4.6. Si calculaste el presupuesto por llamada con 4.6, vuelve a hacerlo.
Hay otra consecuencia práctica: revisa el mínimo de 1,024 tokens para poder usar caché. Anthropic solo almacena en caché prefijos que alcanzan un tamaño mínimo. Un prompt que en 4.6 quedaba justo por debajo del límite, según el tokenizer antiguo, puede superarlo en Fable 5 al generar ~45% más tokens. Lo mismo se aplica en sentido inverso a las estimaciones de tamaño basadas en el recuento anterior. Consulta siempre cache_creation_input_tokens / cache_read_input_tokens en la respuesta real, en lugar de hacer estimaciones con un tokenizer local que puede no coincidir.
Checklist de migración (Opus → Fable 5)
- ✅ El código de caché se reutiliza sin cambios. Los marcadores
cache_control, el número de breakpoints (hasta 4),ttl: "1h"y los nombres de los campos de uso son idénticos. - ✅ Las decisiones sobre TTL se mantienen. 5m para cargas en tiempo real o por sesión; 1h para cargas irregulares o agentes con pausas.
- ✅ La economía del descuento se mantiene. ~90%+ en lecturas, ~1.25x en escrituras de 5m y ~2x en escrituras de 1h.
- ⚠️ Recalcula el coste absoluto. Fable 5 cuesta ~2x más que Opus por token y ~2.9x más que Opus 4.6 para el mismo prompt. El porcentaje de descuento no cambia, pero sí la base sobre la que se aplica.
- ⚠️ Vuelve a medir el número de tokens si migras desde 4.6 o una versión anterior: el mismo texto generará alrededor de un 45% más. Desde 4.7/4.8, el recuento debería ser equivalente.
- ⚠️ Incluye los thinking tokens predeterminados en el cálculo. Fable 5 genera tokens de razonamiento por defecto y se facturan a la tarifa de output ($50/M). Limita o desactiva el razonamiento si no lo necesitas.
Conclusión
Para un equipo que ya utiliza caché con Claude, integrar claude-fable-5 es sencillo: toda la interfaz de caché y TTL se mantiene estable, así que no hay nada nuevo que aprender ni código que reescribir. Sin embargo, sustituir Opus 4.6 no es tan sencillo desde el punto de vista del presupuesto. Al combinar un precio por token 2x mayor con un aumento de ~45% por el nuevo tokenizer, el mismo prompt cuesta ~2.9x más. Confirma tus cifras con el objeto usage real, decide si necesitas los thinking tokens predeterminados y dimensiona los breakpoints de caché según el nuevo número de tokens.
Para consultar la estrategia completa de caché —estructura del prompt, diagnóstico del hit rate y patrones que tienen en cuenta el TTL—, revisa la guía completa de caché de prompts, el primer artículo de la serie, Cómo funcionan KV Cache y TTL, y el tutorial práctico en Python.
Preguntas frecuentes
¿Tengo que cambiar el código de cache_control para usar Fable 5?
No. La sintaxis de los marcadores, el límite de breakpoints y las opciones de TTL son idénticos a los de la familia Opus. Cambia el campo model y no modifiques nada más en la lógica de caché.
¿Ha cambiado el descuento por lectura de caché en Fable 5? No. Una lectura en caliente cuesta una pequeña fracción de un solo dígito del precio de input sin caché, es decir, un descuento de ~90%+. En Fable 5 medimos ~94%, en línea con la economía de lecturas en caché documentada por Anthropic.
¿Fable 5 admite el TTL de 1 hora?
Sí. {"type": "ephemeral", "ttl": "1h"} funciona exactamente igual que en Opus. La escritura de 1 hora cuesta ~2x el precio sin caché; la de 5 minutos, ~1.25x. Las lecturas mantienen un fuerte descuento en ambos casos.
¿Por qué el mismo prompt resulta mucho más caro en Fable 5 que en Opus 4.6? Por dos multiplicadores acumulados: el precio por token de Fable 5 es 2x mayor y el mismo texto en inglés genera ~45% más tokens porque usa el tokenizer posterior a 4.6. En conjunto, un prompt idéntico cuesta ~2.9x más. El descuento de caché no cambia.
¿Fable 5 sustituye directamente a Opus 4.8? Sí en cuanto a caché, TTL y número de tokens. El recuento de tokens es idéntico, por lo que las únicas diferencias son el precio 2x mayor y los thinking tokens predeterminados de Fable 5. No publicamos benchmarks de capacidades que no hayamos ejecutado. Para las afirmaciones sobre calidad y razonamiento, consulta la model card de Anthropic.
Verificación: todas las cifras de tokens, coste, recargo de escritura y descuento de lectura se midieron contra https://synthorai.io/ el 2026-06-10 usando el SDK oficial anthropic, con un único tenant y una única ejecución secuencial. El coste procede del campo usage.cost del gateway. Las proporciones entre modelos y los recargos/descuentos se calcularon a partir de esos costes medidos y no dependen de promociones aplicadas a una cuenta. Las proporciones de descuento y recargo se contrastaron con la documentación de Anthropic sobre caché de prompts. En nuestra ejecución, la latencia de lectura en caliente (TTFT) estuvo dominada por la variabilidad de la red, por lo que se omitió al no ser fiable. Tus cifras variarán según el prompt, la región y la carga.