Prompt Caching: costes de primera y solicitud repetida

Qué mide el experimento

Prompt Cache reduce el reprocesamiento de la parte inalterada de la entrada. Puede ser un system prompt, instrucciones, un documento grande o una historia estable. La pregunta que cambia va después del prefijo general.

El experimento requiere tres estados:

A. primera solicitud: prefijo estable + pregunta 1
B. cache hit:         prefijo estable + pregunta 2
C. cache miss:        prefijo cambiado + pregunta 3

A y B usan el mismo modelo, ajustes y cache policy. C cambia un carácter en el área cacheada o se ejecuta tras expirar TTL confirmado. Si cambia modelo, output y longitud de prompt a la vez, el resultado no se puede explicar solo por cache.

¿Quiere comprobar la fórmula con su propio uso? Cree una cuenta BetterToken y API Key, tome las tarifas actuales de la página de precios y haga primera y solicitud repetida con el mismo prefijo. Relacione input, output, cache Token aplicable y consumo en Dashboard, y compruebe antes las reglas de cache y TTL en la referencia API y documentación del provider.

OpenAI y Anthropic cuentan cache de forma distinta

La misma palabra cache no significa el mismo mecanismo.

Prompt caching de OpenAI

En APIs y modelos OpenAI compatibles, caching se aplica automáticamente al prefijo apropiado. Usage muestra tokens cacheados dentro de detalles de input. El código normalmente no crea objeto cache separado, pero debe conservar intacto el prefijo común. Los umbrales, retención y descuentos exactos se consultan en la página oficial Prompt Caching.

Prompt caching de Anthropic

Anthropic Messages permite marcar el límite de cache mediante cache_control. Usage puede mostrar por separado creación y lectura de cache. Tamaño mínimo, TTL, orden de bloques y coste varían según contrato y modelo actuales; compruébelos en la documentación oficial de Anthropic.

No transfiera nombres de campos Usage ni coeficientes entre protocolos. En la tabla del experimento anote exactamente las categorías que devuelve el endpoint actual.

Preparar un prefijo estable

Reúna la entrada en dos partes:

STABLE_PREFIX
  instrucciones del sistema
  definiciones de tools, si son necesarias
  documento de referencia sin cambios

DYNAMIC_SUFFIX
  pregunta actual del usuario

Para la primera experiencia es mejor retirar tools y streaming. No interfieren automáticamente con cache, pero añaden variables a uso y output.

El prefijo debe ser lo bastante largo según reglas del modelo elegido. Si queda bajo umbral mínimo, no tener cache hit será el resultado esperado. No lo alargue con texto sin sentido en producción; use para el experimento un documento real que ya se repite en el problema.

Antes de llamar, guarde el hash de la parte cacheada:

import hashlib

prefix_hash = hashlib.sha256(STABLE_PREFIX.encode("utf-8")).hexdigest()
print(prefix_hash)

El hash confirma que A y B recibieron el mismo prefijo sin publicar contenido.

Qué campos anotar

Para cada solicitud guarde:

• timestamp y request ID;
• Model ID y protocolo;
• prefix_hash;
• regular input tokens;
• cache creation/write tokens, si el contrato los separa;
• cache read/cached tokens, si el contrato los separa;
• output tokens;
• consumo real;
• estado y latencia solo como diagnóstico.

La latencia no prueba precio. Una respuesta rápida puede ser miss y un hit puede esperar cola. La conclusión de coste se basa en usage y tarifa.

Fórmula de primera consulta

Definamos:

I  — regular input tokens
W  — cache write / creation tokens
R  — cache read / cached tokens
O  — output tokens
Pi — precio input regular por 1.000.000 tokens
Pw — precio cache write por 1.000.000 tokens
Pr — precio cache read por 1.000.000 tokens
Po — precio output por 1.000.000 tokens

Para endpoint que separa estas categorías:

cost = I / 1_000_000 × Pi
     + W / 1_000_000 × Pw
     + R / 1_000_000 × Pr
     + O / 1_000_000 × Po

En la primera solicitud, W y R pueden ser mayores que cero. Con caching automático, los campos pueden ser distintos: use input sin cache y cacheado del usage real, sin crear una categoría inexistente.

La primera solicitud puede costar más que una sin cache si la creación se cobra aparte. No es un error por sí mismo. La amortización llega solo después de suficientes lecturas.

Fórmula de repetición y punto de rentabilidad

Sea:

C0 — coste de primera solicitud que crea cache
Ch — coste de una solicitud con cache hit
Cu — coste de una solicitud comparable sin cache
n  — número total de solicitudes

Serie con una creación y n - 1 hits:

C_cached(n) = C0 + (n - 1) × Ch
C_uncached(n) = n × Cu

El menor n en que cache compensa es el primer entero que cumple:

C_cached(n) < C_uncached(n)

No sustituya precios de otro modelo en la fórmula. Si Ch >= Cu, la configuración actual no ahorra; compruebe cache hit, tamaño de prefijo y categorías tarifarias.

Control cache miss

Después de A y B ejecute C. Cambie solo el prefijo cacheado, manteniendo modelo y longitud de respuesta esperada. La categoría cache read debe reducirse o desaparecer según contrato, y deben cambiar procesamiento normal o creación de cache.

Causas de miss inesperado:

• cambió un símbolo o espacio dentro del prefijo;
• definiciones de tools llegaron en otro orden;
• bloque system se movió;
• cambió modelo o endpoint;
• solicitud quedó fuera de TTL;
• prefijo resultó más corto que umbral mínimo;
• cliente serializa los mismos datos en otro orden.

Cambiar la pregunta después de prefijo estable es esperado. Cambiar dentro del prefijo crea identidad de cache distinta.

Por qué no publicamos «resultado en dólares»

Este artículo no tiene acceso a API Key ni uso de una cuenta concreta, por eso no proporciona ejemplo calculado de una prueba realizada. Precios, modelos y reglas cache cambian. Publicar un número aleatorio convertiría rápido un experimento reproducible en publicidad obsoleta.

Para obtener su resultado:

1. Elija un modelo y protocolo.
2. Abra la página actual de precios BetterToken.
3. Ejecute A, B y C.
4. Copie usage y consumo del Dashboard.
5. Calcule C0, Ch, Cu y rentabilidad.
6. Guarde fecha de comprobación y prefix_hash.

FAQ

¿Por qué la primera solicitud con cache puede costar más?

Algunos protocolos cobran creación/write de cache por separado. El recargo inicial solo se compensa con lecturas repetidas. Consulte el precio actual del modelo concreto.

¿Por qué la solicitud repetida no obtuvo cache hit?

Compruebe longitud e inmutabilidad del prefijo, orden de bloques, modelo, endpoint, TTL y umbral mínimo. Compare prefix_hash.

¿Se pueden comparar OpenAI y Anthropic con un campo Usage?

No. Mecanismos, configuraciones y nombres de categoría difieren. Normalice valores en sus propios campos I, W, R y O, conservando los campos originales.

¿Cache siempre reduce coste?

No. Prefijo corto, repeticiones poco frecuentes, cambios frecuentes y baja tasa de hit pueden no compensar crear cache.

¿Dónde compruebo el débito real de BetterToken?

En Dashboard por hora, modelo y estado de solicitud. Tome tarifa de la página de precios y reglas cache de documentación del protocolo correspondiente.