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

claude-opus-4-8 ya está disponible en la pasarela de Synthorai. Si ya usas la caché de prompts con la línea Opus, la noticia principal es tranquilizadora y algo aburrida: nada del contrato de caché o de TTL ha cambiado respecto a 4.7 o 4.6. Los mismos marcadores cache_control, los mismos TTL de 5 minutos y 1 hora, el mismo descuento de lectura, los mismos recargos de escritura. Tu código de caché se reutiliza tal cual.

Hay exactamente una cosa que sí cambió —y cambió en 4.7, no en 4.8— que afecta a tu presupuesto de tokens. Este artículo la mide para que tú no tengas que hacerlo.

Todas las cifras a continuación se midieron contra https://synthorai.io/ (/v1/messages nativo de Anthropic) el 2026-05-29 con un prompt de sistema en inglés de ~8 K caracteres, max_tokens pequeño, una sola ejecución secuencial. Reprodúcelas con tu propio prompt antes de citarlas.

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 y nada más en tu ruta de caché necesita moverse. Los mecanismos detrás de cache_control se cubren en el tutorial de caché; la arquitectura de por qué existe la caché está en la parte 1 de la serie.

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

Ejecutamos la misma secuencia de escritura de caché / lectura de caché / sin caché a lo largo de la línea Opus reciente. La estructura del descuento es idéntica de principio a fin.

Dos invariantes se cumplen en las cuatro versiones:

• Descuento de lectura ≈ 89 %. Una lectura de caché caliente cuesta ~11 % del precio de entrada sin caché. Esta es la tasa de lectura en caché del 10 % documentada por Anthropic, sin cambios.
• Recargo de escritura ≈ 25 %. La primera llamada (en frío) cuesta ~1,25× el precio sin caché para poblar la caché. El punto de equilibrio se alcanza con un solo acierto.

Las cifras absolutas en dólares para 4.7 y 4.8 son más altas que para 4.5/4.6, pero como veremos en un momento, eso es una cuestión de conteo de tokens, no de economía de la caché — los porcentajes se mantienen estables.

Comportamiento del TTL: sin cambios respecto a 4.7/4.6

Opus 4.8 respeta los mismos dos TTL que el resto de la línea: un valor predeterminado deslizante de 5 minutos y una ventana opcional de 1 hora. Aislamos la ruta del TTL con un prefijo único por llamada (para que ninguna entrada de caché obsoleta pudiera contaminar el resultado) y medimos el recargo de escritura para 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 usage informa del segmento de TTL exactamente como antes — cache_creation.ephemeral_5m_input_tokens o ephemeral_1h_input_tokens. La escritura de 1 hora cuesta ~2× sin caché (frente a ~1,25× para la escritura de 5 minutos), y las lecturas se mantienen en ~11 % independientemente del TTL. Idéntico a 4.7. Si elegiste 5m para el chat en vivo y 1h para agentes con pausas con humano en el bucle en 4.7, conserva esas decisiones en 4.8.

Tiempo hasta el primer token: estable en toda la línea

Medimos el TTFT de lectura caliente con una llamada en streaming (5 muestras por modelo tras un calentamiento de la pasarela, mediana reportada). En este prompt de ~8–11 K tokens, el TTFT se sitúa en una banda de ~2,2–2,8 s sin tendencia material por versión — los rangos de muestras se solapan, por lo que las diferencias son ruido, no un efecto de versión.

Dos salvedades que conviene enunciar con claridad:

• No leas un ranking en esto. Los rangos se solapan en gran medida (la muestra alta de 4.8 fue un valor atípico de 4,38 s); con este tamaño de prompt, el TTFT está dominado por el ruido de red y de encolamiento, no por la versión del modelo. Trata ~2,2–2,8 s como la banda caliente para las cuatro.
• La ganancia de TTFT de la caché escala con la longitud del prompt. A ~8–11 K tokens, el prefill ahorrado por un acierto de caché es pequeño, por lo que el TTFT en frío y en caliente están cerca (ambos ~2–3 s en una pasarela calentada). La brecha se amplía notablemente a más de 100 K tokens, donde el prefill domina — ahí es donde una caché caliente convierte una espera de varios segundos en un primer token rápido. Los mecanismos están en la parte 1: cómo funcionan la caché KV y el TTL.

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

Esto es lo que hay que revisar antes de migrar. El mismo texto de sistema reporta ~43 % más tokens de entrada en 4.7/4.8 que en 4.5/4.6.

El conteo de tokens da un salto en la generación 4.7 y se traslada a 4.8. El coste sigue al conteo de tokens casi exactamente: la relación de coste (4.8 / 4.5) es 1,43, y la relación de tokens es 1,429. En otras palabras, el precio por token es el mismo en toda la línea — la factura más alta en 4.7/4.8 proviene enteramente de que el mismo texto cuenta como más tokens.

Dos consecuencias prácticas:

1. Recalcula el presupuesto sobre el coste absoluto, no sobre el descuento. Tu descuento de caché no ha cambiado (~89 % en lectura), pero el mismo prompt en inglés es ~43 % más caro en términos absolutos en 4.7/4.8 de lo que era en 4.6. Si dimensionaste un presupuesto por llamada según los conteos de tokens de 4.6, quedará desajustado.
2. Vuelve a comprobar el umbral de elegibilidad de caché de 1.024 tokens. Anthropic solo almacena en caché prefijos de un tamaño igual o superior a un mínimo. Un prompt que quedaba justo por debajo del umbral en 4.6 puede superarlo en 4.7/4.8 (más tokens), y un prompt dimensionado en tokens para el tokenizador antiguo debe volver a medirse. Lee siempre cache_creation_input_tokens / cache_read_input_tokens desde la respuesta en vivo en lugar de estimar a partir de un tokenizador local que puede no coincidir.

Describimos una observación medida —texto idéntico, ~43 % más tokens de entrada reportados en 4.7/4.8— que es lo más coherente con una actualización del tokenizador/vocabulario en la generación 4.7. La conclusión no depende de la causa raíz: vuelve a medir los conteos de tokens cuando migres, porque el cálculo de la caché se basa en tokens.

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

• ✅ El código de caché se reutiliza al pie de la letra. Marcadores cache_control, número de puntos de ruptura (hasta 4), ttl: "1h", nombres de campos usage — todos idénticos.
• ✅ Las decisiones de TTL se reutilizan. 5 min para cargas en vivo/de sesión, 1 h para cargas en ráfaga/agentes con pausas.
• ✅ La economía del descuento se reutiliza. ~89 % en lectura, ~1,25× en escritura (5 min), ~2× en escritura (1 h).
• ⚠️ Vuelve a medir los conteos de tokens. Si vienes de 4.5/4.6, espera ~40 %+ más tokens de entrada para el mismo texto (esto ocurrió en 4.7). Si vienes de 4.7, espera paridad.
• ⚠️ Vuelve a validar los paneles de coste. Confía en usage.cost y en los campos *_input_tokens de la respuesta en vivo, no en una estimación en caché de la generación antigua.

Conclusión

Para un equipo de ingeniería que ya usa caché contra Opus, claude-opus-4-8 es el tipo de actualización fácil: toda la superficie de caché y TTL es estable, así que no hay nada que reaprender ni código que reescribir. Presupuesta el cambio del tokenizador si saltas desde 4.6 o anterior, confirma tus cifras con el objeto usage en vivo y despliega.

Para el manual completo de caché —estructura del prompt, depuración de la tasa de aciertos, patrones que tienen en cuenta el TTL— consulta la serie de cuatro partes que comienza con Cómo funcionan la caché KV y el TTL y el tutorial funcional de Python.

Preguntas frecuentes

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

¿Cambió el descuento de lectura de caché en 4.8? No. Una lectura caliente es ~11 % del precio de entrada sin caché (~89 % de descuento) de 4.5 a 4.8, coincidiendo con la tasa documentada por Anthropic.

¿Cambió el recargo del TTL de 1 hora? No. La escritura de 1 hora cuesta ~2× el precio de entrada sin caché; la escritura de 5 minutos cuesta ~1,25×. Las lecturas son ~11 % independientemente del TTL. Igual que 4.7.

¿Por qué es más caro el mismo prompt en 4.8 que en 4.6? El precio por token es el mismo — el prompt simplemente cuenta como más tokens. Un texto idéntico reportó ~8,0 K tokens en 4.5/4.6 y ~11,4 K en 4.7/4.8 en nuestras mediciones (un aumento de ~43 %), lo más coherente con un cambio de tokenizador en la generación 4.7. El descuento de caché no ha cambiado.

¿Es 4.8 un reemplazo directo de 4.7? En la superficie de caché/TTL, sí — los conteos de tokens y la economía ya estaban en el nivel de 4.7, por lo que la migración desde 4.7 es paridad. No publicamos benchmarks de capacidad que no hayamos ejecutado; para afirmaciones sobre calidad y razonamiento, consulta la ficha del modelo de Anthropic.

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

← Volver al blog