El cacheado es una coincidencia de prefijo, y ese solo hecho lo decide todo. El primer byte que cambia invalida todos los que van detrás, así que una línea volátil —una marca de tiempo, un identificador de petición, la pregunta del usuario— colocada delante de veinticinco mil tokens estables significa que ninguno de esos tokens se cachea. La solución tiene siempre la misma forma: lo estable delante, lo volátil detrás. Lo que no resulta obvio es el coste de equivocarse, y por eso aquí se le pone un número. Introduce los bloques de tu petición con la frecuencia con que cambia cada uno, y se ordenan, se mide el prefijo y se calcula la diferencia a lo largo de todas las peticiones que hagas.
Características
Bloques ordenados para maximizar el prefijo
Nombra qué bloques estables quedan varados detrás de los volátiles
Mide el prefijo cacheable y la parte que se paga siempre
Avisa cuando el prefijo queda bajo el mínimo y no se cacheará en silencio
Calcula la diferencia a lo largo de una tirada de peticiones
Señala los bloques de cambio ocasional, que invalidan todo lo posterior
Tarifas de lectura de caché por modelo, con su fecha de comprobación
Tamaños de bloque editables para que encajen con tu petición
Cómo usar Planificador de caché
Lista los bloques de tu petición con sus tamaños
Marca con qué frecuencia cambia cada uno
Lee el orden recomendado y lo que ahorra
Mueve tu punto de caché al final del prefijo estable
Ejemplo
Entrada
User question (300) sent first
Salida
29,500 stable tokens cannot be cached
Un bloque volátil al principio invalida todo lo que hay detrás.
Errores comunes y solución de problemas
Mi tasa de acierto es cero. — Algo volátil está dentro del prefijo. Una marca de tiempo, un identificador de petición o una lista de herramientas sin orden estable bastan por sí solos.
El prefijo queda bajo el mínimo. — Los prefijos cortos no se cachean en absoluto, y nada te lo dice. O agrandas el prefijo, o asumes que el cacheado no se aplicará.
A veces cachea y a veces no. — Suele ser un bloque de cambio ocasional colocado pronto. Cada cambio invalida todo lo posterior, así que un cambio ocasional es una petición ocasional a precio completo.
Reordenar cambiaría el significado. — Entonces es un compromiso real. Lo que deba quedarse donde está es una restricción; la herramienta muestra lo que cuesta para que la decisión sea informada y no accidental.
Preguntas frecuentes
¿Cómo funciona realmente el cacheado de prompts?
La petición se compara por prefijo con lo cacheado. Todo hasta la primera diferencia se sirve desde la caché a una fracción del precio; todo lo posterior se cobra entero. Por eso el orden lo es todo.
¿Qué invalida una caché en silencio?
Cualquier cosa que cambie bytes pronto: una marca de tiempo en el prompt de sistema, un identificador de petición, una lista de herramientas construida desde un mapa sin orden, un campo por usuario. Ninguno da error: la tasa de acierto simplemente cae.
¿Por qué hay un prefijo mínimo?
Por debajo de un tamaño que depende del modelo, el cacheado no se aplica. Falla en silencio, así que un prompt de sistema pequeño que creías cacheado puede no haberlo estado nunca.
¿Dónde va el punto de caché?
Al final del último bloque estable. Todo lo anterior se reutiliza; todo lo posterior es nuevo cada vez, que es exactamente el corte que produce el orden de aquí.
¿Siempre compensa cachear?
Cuando hay un prefijo grande realmente reutilizado, sí: la tarifa de lectura es una fracción de la de entrada. No compensa retorcer una petición que no tiene ningún prefijo estable, que es lo que te dice el error de aquí.
Herramientas relacionadas
Coste de un bucle de agente — Calcula el coste turno a turno, con el historial reenviado y la caché aplicada.
Planificador de contexto — Reparte la ventana entre prompt, herramientas, historial y respuesta.