Coste de escritura de prompt cache: ¿cuándo compensa el 1.25x?

Una escritura en prompt cache se amortiza con una sola relectura dentro del TTL: la escritura se factura a 1.25x la tarifa de input y la lectura, a 0.1x. Por tanto, con un solo hit, el total de dos llamadas pasa de un recargo del 25% a un ahorro del 32.5%. Aun así, en uno de los cinco escenarios de nuestra suite de agentes, ese mismo recargo produjo una pérdida medida del 6%. La diferencia está en un único dato: la ratio lectura:escritura del tráfico. Este artículo explica cómo medirla antes de que llegue la factura. Todos los datos se obtuvieron a través del gateway de Synthorai usando métricas de facturación reales. Las cifras de los agentes proceden de una suite de 150 episodios; los resultados de TTL y agrupación, de pruebas específicas con salt.

TL;DR

• Las escrituras explícitas en cache se facturan a 1.25x (TTL de 5 minutos) o 2x (1 hora); los breakpoints de GPT-5.6 convergieron en el mismo esquema de 1.25x/0.1x. Basta una relectura para alcanzar el punto de equilibrio.
• En nuestra suite de agentes, el efecto neto del recargo osciló entre +6% (RAG, lectura:escritura de 0.2) y -83% (batch, 15.7).
• Los cache hits renuevan gratis el TTL de Claude: con tráfico continuo, la escritura se paga una vez por cada periodo de inactividad, no por cada ventana.
• El caching implícito abarca comportamientos muy distintos: GPT-5.5 mantuvo 7/8 hits después de una llamada de preparación; Gemini logró 1-3 hits de cada 12 incluso agrupando las llamadas. En ninguno hay recargo.

¿Cuánto cuesta realmente una escritura en cache?

Entre los proveedores que comparamos hay tres modelos de precios, y dos cobran por escribir. En el caching explícito de Claude, crear una entrada cuesta 1.25x la tarifa de input con el TTL predeterminado de 5 minutos y 2x con el nivel de 1 hora; las lecturas cuestan 0.1x. GPT-5.6 adoptó breakpoints explícitos con los mismos multiplicadores de 1.25x para escritura y 0.1x para lectura. Las dos mayores implementaciones explícitas del sector tienen ahora precios idénticos. El tercer modelo es el caching implícito (Gemini, Kimi y los modelos de OpenAI anteriores a 5.6): no hay recargo por escritura, solo lecturas con descuento cuando el proveedor consigue un hit.

Calcular el punto de equilibrio de las escrituras explícitas es sencillo. Un prefijo de P tokens cuesta P a la tarifa normal sin cache. Al almacenarlo, la primera llamada cuesta 1.25P; cada relectura dentro del TTL cuesta 0.1P en lugar de P. Con una sola relectura, el total de las dos llamadas es 1.35P frente a 2P sin cache, un ahorro del 32.5%. Cada hit adicional ahorra el 90% del coste del prefijo. El riesgo no está en el recargo, sino en escribir bloques que nunca vuelven a leerse. Ese riesgo depende del tipo de carga.

¿Cuándo hace perder dinero el recargo de escritura?

Cuando el prefijo cambia más rápido de lo que se repite. Medimos la ratio de tokens leídos frente a escritos en cinco escenarios de agentes, con los mismos modelos y la misma estrategia de marcado. Después calculamos el efecto neto del caching con tarifas de 1.25x/0.1x:

El dato clave es la fila de RAG. Los documentos recuperados cambian en cada consulta, así que cada llamada reescribía un prefijo que la siguiente no podía reutilizar: se escribían cinco tokens por cada token leído desde cache. El recargo de 1.25x acababa generando una pérdida neta. No había ningún error de configuración; este tipo de carga simplemente no permite amortizar la escritura. La solución es trabajar por capas, no renunciar al caching: marca el system prompt y las definiciones de herramientas, que se mantienen estables entre consultas, y deja los documentos recuperados sin marcar después del último breakpoint. La misma regla se aplica a cualquier dato volátil, como timestamps, nombres de usuario y contexto específico de la petición, así como a opciones que invalidan el prefijo sin avisar. Cambiar output_config.effort entre turnos vuelve a renderizar el prompt y rompe la cache, por lo que el esfuerzo debe mantenerse constante durante una sesión con cache. Nuestro estudio de LangChain encontró el mismo problema en el framework: builders que hacen tan fácil marcarlo todo como marcar solo lo correcto.

¿Con qué frecuencia vuelves a pagar la escritura?

Una vez por cada periodo de inactividad, no una vez por cada ventana de TTL, porque los hits reinician el contador gratis. Lo comprobamos con un prefijo de 4,981 tokens y salt en Claude Opus 4.8:

La llamada 4 ocurre mucho después del TTL original de 5 minutos y aun así lee la entrada sin problemas, porque las llamadas 2 y 3 renovaron gratis la ventana. Solo los 7 minutos de inactividad obligaron a reescribirla. En la práctica, si el tiempo entre peticiones de una ruta se mantiene por debajo del TTL, el recargo de escritura solo se paga una vez y el nivel de 5 minutos se comporta como una cache indefinida. El nivel de 1 hora —escritura a 2x, cuya facturación verificamos en su propio bucket ephemeral_1h_input_tokens a través del gateway— sirve para otro tipo de tráfico: pagar 2x una vez en lugar de 1.25x repetidamente. Compensa en cuanto evita una sola reescritura, por lo que encaja en rutas con periodos de inactividad de entre cinco minutos y una hora. Si la inactividad supera una hora, ninguno de los niveles conserva la entrada entre ejecuciones. En un trabajo programado, el presupuesto debe basarse en lo que ocurre dentro de cada ejecución: un cron que hace una sola petición no gana nada escribiendo en cache; si distribuye muchas peticiones con el mismo prefijo, se comporta como un batch y aprovecha la cache del mismo modo.

¿Se puede mejorar el caching implícito ajustando el tráfico?

Depende por completo del proveedor, porque el comportamiento best-effort varía mucho. En el extremo fiable, el caching automático de GPT-5.5 se comportó como un mecanismo predecible: tras una llamada de preparación, la entrada podía leerse dos segundos después. La primera prueba produjo un hit con los dos salts utilizados. En una ráfaga posterior, siete de ocho pruebas leyeron desde cache 4,864 tokens de un prompt de 5,170, sin pagar ningún recargo. Es ahorro puro y solo exige enviar dos veces el mismo prefijo. En el otro extremo está Gemini 3.6 Flash: en la misma suite de agentes donde el caching explícito sirvió desde cache el 77-78% de los tokens de input de Claude, la cache implícita de Gemini sirvió el 4%, pese a que las cargas tenían prefijos que realmente se repetían.

Intentamos mejorar el extremo menos fiable ajustando el tráfico: agrupar llamadas con el mismo prefijo para mantener caliente la cache del proveedor. Doce llamadas consecutivas a Gemini 3.6 Flash produjeron exactamente un hit, en la llamada 10; la llamada 11 volvió a fallar. Ocho llamadas separadas por intervalos de 3 minutos no produjeron ninguno. Para descartar un resultado fortuito, repetimos la prueba agrupada en una segunda ruta de peticiones independiente y en Gemini 3.5 Flash. Obtuvimos tres hits de doce y uno de doce, respectivamente, nunca consecutivos durante mucho tiempo. El único bloque que sí se almacenó regresó con los mismos 4,073 tokens en ambas rutas. La mecánica es coherente; la probabilidad, no.

Parte de los misses se debe a la latencia de ingestión, cuyo valor depende del proveedor. La entrada de GPT-5.5 estaba disponible dos segundos después de prepararla, mientras que la de Gemini tarda decenas de segundos en crearse. Por eso, las ráfagas lanzadas justo después de la primera llamada se adelantan a la cache. Ninguna prueba con Gemini produjo un hit antes de la cuarta llamada. Preparar el prefijo una vez y esperar 45 segundos antes de la ráfaga elevó el resultado a 3 hits de 8, el mejor obtenido mediante ajuste del tráfico. Sin embargo, al esperar 90 segundos, el resultado fue cero de 8: cuando volvimos, la entrada ya había desaparecido. Días antes, una prueba de calentamiento más larga con el mismo modelo había mantenido los hits, por lo que la tasa también cambia con el tiempo y la carga. Entre la latencia de creación, la corta duración y esa variación, agrupar llamadas en el extremo menos fiable solo ayuda en el sentido de que tres hits son mejores que uno. (Una nota sobre las pruebas: evalúa las caches implícitas con llamadas espaciadas y con una variante de preparación y espera. Mide también la latencia de creación con una secuencia escalonada posterior a la preparación; lanzar pruebas consecutivas mide tu tasa de peticiones, no la cache.)

La regla debe definirse por proveedor, no por mecanismo: mide si la cache implícita de tu proveedor se comporta como la de GPT-5.5 —prepárala y confía en ella— o como la de Gemini —trata cada hit como una bonificación—. Kimi K3 queda entre ambos: sin recargo, con un mínimo pequeño y un 57-62% del input servido desde cache sin configuración. Hay un dato revelador sobre qué enfoque termina imponiéndose: OpenAI tenía la mejor cache implícita que medimos y, aun así, cambió GPT-5.6 a breakpoints explícitos. Sustituyó un descuento propio sujeto al azar por marcas controladas por el cliente.

¿Qué cargas amortizan el recargo?

La decisión depende de la ratio lectura:escritura y del periodo de inactividad. Ambos pueden obtenerse de tus propios registros de uso antes de adoptar el caching:

Dos reglas finales extraídas de las métricas. Primero, evalúa el caching comparando cache_read con cache_creation en el desglose de tu propio consumo, no por la impresión de que los hits son frecuentes. El escenario RAG parecía adecuado para cache y registró 0.2. Segundo, cuando la ratio es buena, el recargo resulta insignificante: con una ratio lectura:escritura de 3.5, la cifra global de la suite, el gasto del prefijo baja un 64% después de incluir todas las escrituras pagadas.

Preguntas frecuentes

¿Compensa usar prompt caching con RAG?

No para los documentos recuperados. En nuestra medición, RAG escribió cinco tokens por cada token que volvió a leer, lo que convirtió el recargo de 1.25x en una pérdida neta del 6%. Almacena en cache las capas estables —system prompt y definiciones de herramientas— y coloca el contenido recuperado después del último breakpoint. La guía completa de caching explica en detalle cómo estructurar el prompt por capas.

¿Debo usar un TTL de cache de 5 minutos o de 1 hora?

Decide según el periodo de inactividad, no según la duración de la sesión. Los hits renuevan gratis el TTL de 5 minutos, por lo que una ruta con menos de 5 minutos entre peticiones nunca reescribe y el nivel barato se mantiene indefinidamente. Paga la escritura a 2x del nivel de 1 hora solo cuando las pausas sean de entre cinco minutos y una hora; compensa en cuanto evita una reescritura a 1.25x. Si las pausas superan una hora, calcula el presupuesto como si no hubiera cache.

¿El caching implícito cobra por escribir?

No, y por diseño no puede hacerlo: un recargo de escritura solo tiene sentido cuando el cliente decide activarla. Por eso, los recargos existen únicamente en el caching explícito: los multiplicadores de 1.25x/2x de Anthropic, los breakpoints de GPT-5.6 y el modelo de alquiler de almacenamiento de las APIs de contenido almacenado explícitamente, como la tarifa por token-hora de Gemini. Todas las implementaciones implícitas que medimos —Gemini, Kimi y OpenAI anterior a 5.6— y todas las tarifas publicadas por los principales proveedores —DeepSeek, Qwen y Grok— solo aplican descuentos a las lecturas implícitas. Lo que varía es la fiabilidad: la cache implícita de GPT-5.5 mantuvo 7 hits en 8 pruebas preparadas, mientras que la de Gemini sirvió el 4% del input en nuestra suite de agentes y apenas mejoró al agrupar las llamadas. Un descuento fiable sin recargo supera cualquier alternativa; un descuento sin recargo que aparece al azar vale menos que un pequeño recargo por un mecanismo que controlas.

Mediciones realizadas del 2026-07-25 al 2026-07-29 a través del gateway de Synthorai: ratios lectura:escritura de los escenarios obtenidas de 150 episodios de agentes con Claude y desglose de cache por llamada (porcentajes de Gemini y Kimi tomados de sus propias ejecuciones de la suite); pruebas de renovación del TTL y del bucket de 1 hora en claude-opus-4-8 (prefijos con salt de 4,981 y 3,742 tokens); pruebas de cache implícita en gemini-3.6-flash y gemini-3.5-flash (prefijos con salt de ~6,800 tokens; variantes agrupadas, espaciadas y con preparación y espera) y en gpt-5.5 (prompt con salt de 5,170 tokens y ráfaga preparada). Porcentajes de efecto neto calculados a partir de las ratios medidas, con multiplicadores de 1.25x para escritura y 0.1x para lectura. Las tarifas y el comportamiento de la cache pueden cambiar; compruébalos con tus propios registros de uso.

← Volver al blog