El Equipo de Claude Code Declara Emergencias Cuando Esta Métrica Cae
El equipo detrás de Claude Code acaba de explicar — públicamente, de manera casual, en un tweet — que el prompt caching es la única pieza de infraestructura que hace viable todo el producto. No es una optimización bonita. No es un truco para ahorrar costos. Es la viga maestra.
TL;DR: Cada vez que envías un mensaje a Claude (API o Claude Code), el sistema verifica si ya procesó el inicio de tu prompt. Si sí: 10x más barato, 85% más rápido. Si no: precio completo, espera completa. El equipo de Claude Code monitorea esta métrica como si fuera un latido cardíaco y declara incidentes cuando baja. La mayoría de los devs están rompiendo su cache sin saberlo. Este artículo explica qué es el prompt caching, por qué importa, y los errores que te están costando dinero ahora mismo.
¿Su lema? "Cache Rules Everything Around Me."
Si creciste escuchando Wu-Tang, reconoces la referencia. Si no — CREAM hablaba de que el dinero controlaba todo. La versión de Claude Code es sobre los tensores KV controlando todo. La misma energía, diferente moneda. Y al igual que el original, si ignoras el mensaje, vas a pagar por ello.
La mayoría de los devs con los que hablo no saben qué es el prompt caching. Definitivamente no saben que se han beneficiado de él cada vez que abren una sesión de Claude Code. Y absolutamente no saben que la forma en que estructuran sus prompts puede hacer que peguen en el cache o lo fallen — costándoles velocidad, dinero, o ambos.
Esta es la versión simplificada.
Y sí, probablemente lo estás haciendo mal.
$0.045 vs $0.005 — misma solicitud, mismo modelo, mismo resultado
Empezaré con el número que me hizo realmente preocuparme por este tema.
Uno de mis proyectos de Convex tiene un asistente AI — ~6,000 tokens de system prompt, 12 definiciones de herramientas (auth de Clerk, queries de Supabase, algunas acciones custom), conversaciones típicas de 15–20 turnos. Cosas estándar. Nada exótico.
Revisé mi uso de API después de una semana e hice las cuentas de una conversación de 20 turnos:
- Sin caching: cada solicitud tardía en la conversación procesa ~15,000 tokens de contexto a precio completo. ~$0.045 por solicitud.
- Con caching: solo los últimos ~500 tokens (mensaje nuevo + respuesta anterior) necesitan computación fresca. Todo lo demás pega en el cache. ~$0.005 por solicitud.
Nueve. Veces. Más barato.
Escala eso a 1,000 conversaciones al día y estás viendo $1,350/mes vs $150/mes. No descubrí el prompt caching a través de un blog post o una charla de conferencia. Lo descubrí mirando fijamente un dashboard de Stripe preguntándome por qué mi entorno de pruebas estaba quemando créditos como un niño con dinero de cumpleaños en GameStop. En fin — el punto es que me habría ahorrado dos semanas de confusión si alguien me hubiera explicado esto de la forma en que te lo voy a explicar.
Qué es realmente el prompt caching (la versión Wu-Tang)
Cada vez que llamas a la API de Claude — o cada vez que Claude Code ejecuta una acción por debajo — se ensambla un prompt. Ese prompt tiene cuatro capas:
- El system prompt (tus instrucciones, personalidad, restricciones)
- Definiciones de herramientas (todas las funciones que Claude puede llamar)
- Historial de conversación (mensajes previos en la sesión)
- El nuevo mensaje del usuario (lo que acabas de escribir)
Sin caching, Claude reprocesa cada uno de esos tokens desde cero. Cada vez. ¿Tu system prompt de 8,000 tokens? Reprocesado. ¿Tus 15 definiciones de herramientas? Reprocesadas. ¿Los 40 mensajes previos en la conversación? Todo, desde cero — como un pez dorado leyendo el mismo libro por primera vez, para siempre.
El prompt caching almacena los tensores Key-Value computados (las matemáticas pesadas que hace el modelo durante la fase de "prefill") para un prefijo exacto de tu prompt. ¿Siguiente solicitud con el mismo prefijo? Saltea las matemáticas, reutiliza el resultado almacenado.
El cache vive por 5 minutos por defecto. Los modelos más nuevos Claude 4.5 soportan un TTL de 1 hora a 2x el costo de escritura. Y el matching es exacto — un carácter diferente en tu prefijo e invalida todo el cache. Es como un escáner de huellas que también verifica tu estado de ánimo.
CREAM. Cache Rules Everything Around Me. Cada solicitud que envías o pega en el cache y paga 0.1x el precio de input, o lo falla y paga precio completo. No hay término medio.
Los 3 errores que están quemando tu dinero
Esta es la parte donde dejo de ser amable. Un paper de investigación llamado "Don't Break the Cache" probó estrategias de caching en OpenAI, Anthropic y Google con más de 500 sesiones de agentes. Combinado con lo que compartió el equipo de Claude Code, el patrón es claro: la mayoría de los devs rompen su cache de las mismas tres formas.
Error #1: Inyectar basura dinámica en tu system prompt.
Timestamps. IDs de solicitud. Datos específicos del usuario. Tokens de sesión. Cada vez que metes algo dinámico en tus instrucciones del sistema, todo el prefijo se vuelve único. Cache miss. Precio completo. Cada vez.
Yo he hecho esto. Tenía un "Current time: ${new Date().toISOString()}" en mi system prompt para "contexto." Me costó probablemente $40 en llamadas innecesarias a la API antes de darme cuenta. El fix tomó 8 segundos — mover el timestamp al mensaje del usuario en su lugar.
{
"system": [
{
"type": "text",
"text": "You are a code review assistant for a Next.js + Convex app...",
"cache_control": {"type": "ephemeral"}
}
],
"messages": [
{"role": "user", "content": "Current time: 2026-02-19T14:30:00Z\n\nReview this function..."}
]
}
El tag cache_control le dice a Anthropic: "cachea todo hasta acá." System prompt estático = cacheado. Timestamp dinámico en el mensaje del usuario = no rompe el prefijo. Una reestructuración. 90% de ahorro en ese chunk.
Si quieres el framework completo para estructurar system prompts que no solo cacheen bien sino que realmente produzcan output confiable, escribí sobre Prompt Contracts — misma filosofía, diferente ángulo.
Error #2: Reordenar herramientas entre solicitudes.
Anthropic procesa el prefijo cacheable en un orden específico: tools → system → messages. Si tu código ensambla definiciones de herramientas desde un Map o un Set desordenado, el orden puede mezclarse entre solicitudes. Orden diferente = prefijo diferente = cache miss. No cambiaste ni una sola herramienta. No agregaste ni removiste nada. Solo dejaste que las peculiaridades de ordenamiento de objetos de JavaScript te costaran dinero.
Fix: ordena tus herramientas alfabéticamente o por un índice fijo antes de enviar. Súper aburrido. Extremadamente rentable. Y si te preguntas si realmente necesitas todas esas definiciones de herramientas en primer lugar — los CLIs podrían ser mejor opción que los MCPs. Menos herramientas = prefijo más pequeño = cache hit más fácil.
Error #3: No usar breakpoints para nada (específico de Anthropic).
A diferencia de OpenAI (que cachea automáticamente para prompts de más de 1,024 tokens), Anthropic requiere que marques explícitamente qué cachear con breakpoints de cache_control. Si no los agregas, nada se cachea. Estás pagando precio completo y preguntándote por qué Claude se siente lento.
Para conversaciones multi-turno, obtienes hasta 4 breakpoints en total. La investigación encontró la división óptima: 1 en el system prompt, 3 en mensajes recientes del usuario. Esto cachea tanto tus instrucciones estáticas como tu historial de conversación reciente. Sin los breakpoints en mensajes del usuario, el uso pesado de herramientas entre turnos crea gaps no cacheados que siguen creciendo — como un memory leak pero para tu billetera.
Por qué tus sesiones de Claude Code se sienten rápidas (hasta que no)
Desvío rápido para la gente de suscripción. Si estás en Claude Code (no la API), no configuras nada de esto manualmente. El harness maneja la optimización de cache — es literalmente en lo que el equipo gasta su tiempo de ingeniería, y aparentemente declara emergencias al respecto.
Pero entender cómo funciona explica algunas cosas que probablemente has notado:
El primer mensaje en una sesión nueva siempre es más lento. Esa es la escritura del cache. El system prompt, tu CLAUDE.md, todas las definiciones de herramientas — siendo computadas y almacenadas por primera vez. Cada mensaje después se beneficia del cache. El arranque en frío es el calentamiento.
Cambiar proyectos a mitad de sesión se siente lento. Contexto de proyecto diferente = system prompt diferente = cache miss. El sistema tiene que construir un cache nuevo desde cero. No es un bug. Solo física.
Las sesiones largas generalmente se sienten rápidas. El historial de conversación sigue creciendo pero mayormente pegando en el cache. El turno 30 reutiliza el prefijo cacheado de los turnos 1–29 y solo procesa lo nuevo. Por esto el equipo de Claude Code construyó toda su arquitectura alrededor de esto — sin caching, tu mensaje 50 procesaría 50x más tokens que tu primero. El producto estaría muerto para el mensaje 15. Como un hilo de Slack que carga cada mensaje previo desde cero cada vez que alguien escribe "suena bien" — pero divago.
Y a veces se vuelve lento aleatoriamente. Si el equipo shipea un cambio que accidentalmente modifica el orden de ensamblado de prompts, o si una actualización interna cambia una definición de herramienta, el cache de cada usuario se rompe simultáneamente. Ese es el SEV. Ese es el pager sonando. "Cache Rules Everything Around Me" no es un lema lindo. Es un manual de operaciones.
Qué significa esto realmente para ti
Si estás construyendo en la API de Claude: ve a revisar tus system prompts ahora mismo. Si hay algo dinámico en ellos — una fecha, un ID de usuario, una semilla aleatoria, cualquier cosa que cambie entre solicitudes — muévelo al mensaje del usuario. Agrega breakpoints de cache_control. Ordena tus herramientas. Hazlo hoy. El ROI es inmediato y vergonzoso. Aprendí esto por las malas cuando Anthropic mató mi setup de OpenClaw de $200/mes — una vez que reconstruyes en API en lugar de suscripción, cada dólar de optimización importa.
Si estás usando Claude Code con suscripción: no necesitas hacer nada. Pero ahora entiendes por qué el equipo trata el prompt caching como el suministro de oxígeno en una estación espacial. Y la próxima vez que tu primer mensaje tome 6 segundos y tu décimo mensaje tome 1.5, sabrás exactamente qué pasó.
De cualquier manera, CREAM. El cache controla todo a tu alrededor, sepas o no. La única pregunta es si estás del lado barato o del lado caro.
Los devs que entienden su infra shippean más barato. Los que no subsidian los rate limits de todos los demás.
Próximamente: Anthropic acaba de matar los harnesses de terceros usando suscripciones de Claude. Mi setup de OpenClaw de $200/mes murió de la noche a la mañana. Reconstruí todo por $15 — y el prompt caching es la mitad de la razón por la que funciona.
Cada línea de código cuesta dinero. Descubre cómo los ingenieros de Claude Code optimizan su infraestructura de IA para no quemar presupuesto.