Claude Opus 4.8 en Synthorai: caché y TTL frente a 4.7/4.6

claude-opus-4-8 ya está disponible en el gateway de Synthorai. Si ya usas caché de prompts con la familia Opus, la principal novedad es tranquilizadora y poco emocionante: el contrato de caché y TTL no ha cambiado respecto a 4.7 o 4.6. Se mantienen los mismos marcadores cache_control, los mismos TTL de 5 minutos y 1 hora, el mismo descuento por lectura y los mismos recargos por escritura. Puedes reutilizar tu código de caché sin cambios.

Solo hay un cambio que afecta al presupuesto de tokens. Ocurrió en 4.7, no en 4.8. En este artículo lo medimos para que no tengas que hacerlo.

TL;DR

• Claude Opus 4.8 mantiene sin cambios el contrato de caché de 4.7/4.6: un descuento medido del 89% en lecturas, un recargo de escritura de aproximadamente 1.25x con el TTL de 5 minutos y de alrededor de 2x con el de 1 hora.
• El mismo texto de sistema registra cerca de un 43% más de tokens de entrada en Opus 4.7/4.8 que en 4.5/4.6 (11,394 frente a 7,976 tokens).
• El precio por token es idéntico en toda la familia Opus: la relación de costes entre 4.8 y 4.5, de 1.43, coincide con la relación de tokens de 1.429.
• El TTFT en lecturas con caché caliente se mantiene entre 2.2 y 2.8s en Opus 4.5-4.8; las diferencias son variaciones aleatorias.

Todas las cifras siguientes se midieron contra https://synthorai.io/ (endpoint /v1/messages nativo de Anthropic) el 2026-05-29, con un prompt de sistema en inglés de unos 8K caracteres, un valor bajo de max_tokens y una única ejecución secuencial. Repite las pruebas con tu propio prompt antes de citar estos datos.

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-opus-4-8",            # 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)   # cache_creation_input_tokens, cache_read_input_tokens, cost

Cambia claude-opus-4-7 → claude-opus-4-8; no necesitas tocar nada más en la lógica de caché. El tutorial sobre caché explica cómo funciona cache_control; la arquitectura y el motivo por el que existe la caché se detallan en la primera parte de la serie.

Comportamiento de la caché: sin cambios respecto a 4.7/4.6

Ejecutamos la misma secuencia de escritura en caché, lectura desde caché y llamada sin caché en las versiones recientes de Opus. La estructura de descuentos es idéntica en todas ellas.

Hay dos constantes en las cuatro versiones:

• Descuento de lectura ≈ 89%. Una lectura con caché caliente cuesta cerca del 11% del precio de entrada sin caché. Coincide con la tarifa documentada por Anthropic del 10% para lecturas desde caché y no ha cambiado.
• Recargo de escritura ≈ 25%. La primera llamada, con la caché fría, cuesta aproximadamente 1.25× el precio sin caché para almacenar el contenido. Basta con un hit para amortizarla.

Las cifras absolutas en dólares son mayores en 4.7 y 4.8 que en 4.5/4.6. Como veremos enseguida, se debe al recuento de tokens, no a la economía de la caché: los porcentajes no cambian.

Comportamiento del TTL: sin cambios respecto a 4.7/4.6

Opus 4.8 admite los mismos dos TTL que el resto de la familia: 5 minutos deslizantes por defecto y una ventana opcional de 1 hora. Aislamos las pruebas de TTL con un prefijo único en cada llamada para impedir que una entrada antigua de la caché afectara al resultado. Después medimos el recargo de escritura de cada TTL:

# 1-hour TTL — same marker syntax on 4.8 as on 4.7/4.6
"cache_control": {"type": "ephemeral", "ttl": "1h"}

El objeto de uso informa del tramo de TTL exactamente igual que antes: cache_creation.ephemeral_5m_input_tokens o ephemeral_1h_input_tokens. La escritura con TTL de 1 hora cuesta alrededor de 2× el precio sin caché, frente a aproximadamente 1.25× para la de 5 minutos. Las lecturas siguen costando cerca del 11% independientemente del TTL. Es idéntico a 4.7. Si en 4.7 elegiste 5m para chat en vivo y 1h para agentes con pausas de intervención humana, mantén esas opciones en 4.8.

Tiempo hasta el primer token: estable en toda la familia

Medimos el TTFT de lecturas con caché caliente mediante una llamada en streaming: 5 muestras por modelo tras calentar el gateway, y mostramos la mediana. Con este prompt de unos 8–11K tokens, el TTFT se mantiene en un intervalo aproximado de 2.2–2.8 s, sin una tendencia relevante entre versiones. Los intervalos de las muestras se solapan, así que las diferencias son variaciones aleatorias, no un efecto de la versión.

Hay dos matices que conviene dejar claros:

• No interpretes estos datos como una clasificación. Los intervalos se solapan mucho; la muestra alta de 4.8, de 4.38 s, fue un valor atípico. Con un prompt de este tamaño, el TTFT depende más de las variaciones de red y de las colas que de la versión del modelo. Considera que el intervalo con caché caliente es de aproximadamente 2.2–2.8 s en los cuatro modelos.
• La mejora de TTFT por caché crece con la longitud del prompt. Con unos 8–11K tokens, el prefill que evita un hit de caché es pequeño. Por eso el TTFT con caché fría y caliente es parecido: ambos rondan los 2–3 s en un gateway ya calentado. La diferencia aumenta bastante a partir de 100K tokens, cuando domina el prefill. En ese escenario, una caché caliente convierte una espera de varios segundos en un primer token rápido. La primera parte: cómo funcionan KV Cache y TTL explica el mecanismo.

El único cambio real: la tokenización (desde 4.7)

Esto es lo que debes revisar antes de migrar. El mismo texto de sistema registra alrededor de un 43% más de tokens de entrada en 4.7/4.8 que en 4.5/4.6.

El recuento de tokens aumenta en la generación 4.7 y se mantiene en 4.8. El coste sigue casi exactamente la misma proporción: la relación de costes entre 4.8 y 4.5 es 1.43, mientras que la relación de tokens es 1.429. El precio por token es el mismo en toda la familia; la factura aumenta en 4.7/4.8 porque el mismo texto cuenta como más tokens.

Esto tiene dos consecuencias prácticas:

1. Recalcula el presupuesto según el coste absoluto, no según el descuento. El descuento de la caché no cambia: las lecturas siguen teniendo cerca de un 89%. Sin embargo, el mismo prompt en inglés cuesta aproximadamente un 43% más en términos absolutos en 4.7/4.8 que en 4.6. Si calculaste el presupuesto por llamada con los recuentos de tokens de 4.6, ya no será correcto.
2. Vuelve a comprobar el mínimo de 1,024 tokens para poder usar la caché. Anthropic solo almacena en caché prefijos que alcanzan un tamaño mínimo. Un prompt que quedaba justo por debajo del límite en 4.6 puede superarlo en 4.7/4.8 al contar como más tokens. También hay que volver a medir cualquier prompt cuyo tamaño se calculó en tokens con el tokenizador anterior. Consulta siempre cache_creation_input_tokens / cache_read_input_tokens en la respuesta real, en lugar de estimarlos con un tokenizador local que quizá no coincida.

Describimos una observación medida: un texto idéntico registra cerca de un 43% más de tokens de entrada en 4.7/4.8. La explicación más probable es una actualización del tokenizador o del vocabulario en la generación 4.7. La conclusión no depende de la causa: vuelve a medir los recuentos de tokens al migrar, porque los cálculos de la caché se basan en tokens.

Lista de comprobación para migrar (4.6/4.7 → 4.8)

• ✅ El código de caché se reutiliza sin cambios. Los marcadores cache_control, el número máximo de breakpoints (hasta 4), ttl: "1h" y los nombres de los campos de uso son idénticos.
• ✅ Las opciones de TTL se mantienen. 5m para cargas en vivo o basadas en sesiones; 1h para cargas por ráfagas o agentes con pausas.
• ✅ La economía de los descuentos se mantiene. ~89% en lecturas, ~1.25× en escrituras (5m) y ~2× en escrituras (1h).
• ⚠️ Vuelve a medir los tokens. Si migras desde 4.5/4.6, espera más de un ~40% de tokens de entrada para el mismo texto; este cambio apareció en 4.7. Si vienes de 4.7, los recuentos deberían ser equivalentes.
• ⚠️ Valida de nuevo los dashboards de costes. Usa usage.cost y los campos *_input_tokens de la respuesta real, no una estimación guardada de la generación anterior.

Conclusión

Para un equipo de ingeniería que ya usa caché con Opus, claude-opus-4-8 es una actualización sencilla. Toda la interfaz de caché y TTL se mantiene estable, así que no hay nada nuevo que aprender ni código que reescribir. Si vienes de 4.6 o una versión anterior, ajusta el presupuesto por el cambio de tokenizador, confirma las cifras con el objeto usage real y despliega.

La serie sobre caché de prompts cubre la estructura de los prompts, la depuración del hit rate y los patrones que tienen en cuenta el TTL. Empieza por cómo funcionan KV Cache y TTL y continúa con el tutorial práctico en Python.

Preguntas frecuentes

¿Tengo que cambiar mi código de cache_control para usar Opus 4.8? No. La sintaxis de los marcadores, el límite de breakpoints y las opciones de TTL son idénticos a los de 4.7/4.6. Cambia el campo model y nada más.

¿Ha cambiado el descuento por lectura desde caché en 4.8? No. Entre 4.5 y 4.8, una lectura con caché caliente cuesta cerca del 11% del precio de entrada sin caché, es decir, alrededor de un 89% menos. Coincide con la tarifa documentada por Anthropic.

¿Ha cambiado el recargo del TTL de 1 hora? No. La escritura con TTL de 1 hora cuesta aproximadamente 2× el precio de entrada sin caché; la de 5 minutos cuesta alrededor de 1.25×. Las lecturas cuestan cerca del 11% independientemente del TTL, igual que en 4.7.

¿Por qué el mismo prompt cuesta más en 4.8 que en 4.6? El precio por token es el mismo; el prompt simplemente cuenta como más tokens. En nuestras mediciones, un texto idéntico registró cerca de 8.0K tokens en 4.5/4.6 y aproximadamente 11.4K en 4.7/4.8, un aumento de alrededor del 43%. La explicación más probable es un cambio de tokenizador en la generación 4.7. El descuento de caché no ha cambiado.

¿Puedo sustituir 4.7 por 4.8 sin más cambios? Sí, en lo relativo a caché y TTL. Los recuentos de tokens y la estructura de costes ya habían cambiado en 4.7, así que migrar desde 4.7 mantiene el mismo comportamiento. No publicamos benchmarks de capacidades que no hayamos ejecutado. Para consultar afirmaciones sobre calidad y razonamiento, revisa la ficha del modelo de Anthropic.

Verificación: todas las cifras de caché, TTL, recuento de tokens, coste y TTFT se midieron contra https://synthorai.io/ el 2026-05-29 con el SDK oficial anthropic y un único tenant. Las cifras de coste y tokens proceden de una sola ejecución secuencial; el TTFT es la mediana de 5 muestras por modelo tras calentar el gateway. Las relaciones de descuento y recargo se contrastaron con la documentación de Anthropic sobre caché de prompts. Tus resultados variarán según el prompt, la región y la carga.

← Volver al blog