Cómo reducir el gasto en tokens de Claude: caché de prompts, sobrecarga de MCP, LSP y cambio de modelo
Adónde van de verdad los tokens de Claude: historial reenviado, la ventana de caché de cinco minutos, el coste de los esquemas MCP, grep frente a LSP, una prueba del prompt cavernícola y hábitos que recortan el gasto.
La factura de Claude puede subir aunque nadie se pase a un modelo más grande. Lo más habitual es que la culpa la tenga un montón de herramientas que se cargan y nunca se llaman. La primera pista suele ser una sesión que de repente va lenta, y las cifras de uso cuentan el resto. Los mismos cuatro hábitos se comen el presupuesto de muchísimos desarrolladores, así que vale la pena repasarlos uno por uno.
Adónde va el dinero: los tokens de entrada
El modelo no recuerda el mensaje anterior. En cada turno se vuelve a enviar la conversación entera. Para el vigésimo mensaje, estás pagando por reenviar los diecinueve primeros antes de que se escriba una sola palabra nueva.
Los tokens de salida cuestan aproximadamente cinco veces más que los de entrada, y esa es la cifra que todo el mundo cita. Pero en un chat largo la salida sigue siendo pequeña frente a la entrada, y lo que se acumula es la entrada. Como conversión aproximada, 100 tokens equivalen a unas 75 palabras en inglés. Haz la cuenta de una sesión de una hora y el total se vuelve incómodo muy rápido. Los tokens de entrada se acumulan en cada turno; los de salida, no.
Caché de prompts, el descuento que casi nadie aprovecha
Anthropic guarda en caché la parte inicial de un prompt, siempre que coincida exactamente. Leer de esa caché se cobra a cerca del diez por ciento del precio normal de entrada. Un fallo sale algo más caro que no usar caché, porque crear una entrada en caché lleva un recargo de 1,25x sobre el precio base.
Por defecto la caché dura cinco minutos, y cada acierto la renueva sin coste. Existe una opción de una hora, pero escribir en ella cuesta el doble.
La duración importa mucho. En marzo de 2026, según se informó, Claude Code pasó de la caché de una hora a la de cinco minutos. Un desarrollador revisó sus propias facturas de la API y abrió un issue en GitHub. Con la caché de una hora, alrededor del 1 % del gasto se iba en reescribir la caché. Tras el cambio, esa proporción osciló entre el 15 % y el 53 %.
Otro desarrollador modeló una sesión de Opus de 200K tokens. Si te ausentas más de cinco minutos, al volver hay que escribir todo el contexto de nuevo, unos $1.25 cada vez. A lo largo de un día completo, algunas sesiones acabaron entre un 30 % y un 60 % más caras con exactamente el mismo trabajo. La única diferencia era la ventana de caché.
Vuelve antes de cinco minutos y pagas una décima parte. Pierde la ventana y pagas 1,25 veces.
Hay una trampa: la coincidencia tiene que ser exacta. Cualquier cambio en el prompt de sistema, cualquier herramienta añadida o quitada, o un cambio de modelo a mitad de sesión la borra. Según la documentación de Anthropic, modificar una sola definición de herramienta invalida toda la caché. No está tan claro cuánta tolerancia tiene la coincidencia con mucha carga, ya que las sesiones con mucho tráfico pueden comportarse de forma menos predecible de lo que indica la especificación. El panel de uso es mejor guía que las cuentas mentales.
En la práctica: elige primero el modelo, mantén estable el prompt de sistema y no añadas herramientas a mitad de camino. Si usas la API y las pausas entre turnos superan a menudo los cinco minutos, la caché de una hora puede salir más barata.
Los servidores MCP no son gratis
Cada herramienta conectada añade su esquema al prompt: el nombre, la descripción y todos los parámetros. Ese coste se repite en cada turno mientras la herramienta esté cargada, se use o no.
La entrada de blog de un desarrollador hizo que mucha gente lo comprobara. Al iniciar una sesión de Claude Code con varios servidores MCP, solo las herramientas consumían más de 66.000 tokens antes de escribir una palabra. Eso es un tercio de una ventana de 200K. Al ejecutar /doctor, la cifra real se acercaba a 82.000, y un único servidor de búsqueda con 20 herramientas suponía unos 14.000 tokens.
Hay casos peores. En un issue de GitHub de noviembre de 2025, un servidor MCP de Docker con 135 herramientas consumía por sí solo unos 126.000 tokens, y quien lo reportó recibía un aviso "context low" (poco contexto) en cada comando.
MCP compensa cuando hace falta un acceso estructurado y repetido a un servicio. No compensa cuando está ahí sin usarse, ocupando contexto.
Mejora reciente. En enero de 2026 llegó Tool Search a Claude Code. Si las descripciones de MCP fueran a ocupar más de una décima parte del contexto, sus esquemas completos se quedan fuera del prompt. En su lugar se ofrece una herramienta de búsqueda ligera, y una definición solo se carga en el momento en que se necesita. Anthropic habla de una reducción de alrededor del 85 % en la sobrecarga de tokens de herramientas.
El coste recurrente ha bajado, pero no ha desaparecido. Las configuraciones que no llegan al umbral siguen cargando todos los esquemas de entrada. Otros clientes quizá no aplacen nada. Y acumular herramientas sigue perjudicando la precisión aunque salgan baratas. Ejecutar /context muestra por qué estás pagando realmente.
Las herramientas de línea de comandos esquivan el problema por completo. El modelo ya conoce git, curl y la CLI de GitHub, o puede ejecutar --help. Sin esquema y sin coste fijo. Para algo que solo se necesita de vez en cuando, gana la CLI.
Buscar en el código quema más de lo que parece
Grep ve el código como texto plano. Buscar dónde se define User devuelve todas las menciones: clases, variables, comentarios, imports, selectores de hojas de estilo y columnas de base de datos.
El análisis de un proyecto real registró 847 coincidencias en 203 archivos para exactamente ese tipo de búsqueda, y después el modelo leyó cada una para encontrar la definición verdadera. Tiempos según los logs: hasta un minuto con grep, frente a unos 50 ms cuando respondía un servidor de lenguaje.
El mismo patrón aparece a menor escala. En un repositorio de 30K líneas, grep para renombrar una función dio 733 resultados, y solo 501 importaban. Cada resultado irrelevante se lee y se paga igualmente. Si se dirige al modelo a un LSP, va directo a los 501, lo que ahorró unos 13K tokens en esa única búsqueda. No se sabe si la proporción se mantiene en otros casos, aunque sí se mantuvo en los dos repositorios medidos.
Quienes lo usan desde hace tiempo dan dos avisos:
- Claude recurre a grep por defecto incluso con LSP activado. Un desarrollador vio que el LSP solo se usaba en torno al 1 % de las veces hasta que puso instrucciones explícitas en
CLAUDE.md. - Grep sigue teniendo su sitio. Es la herramienta adecuada para logs, configuraciones, literales de cadena y todo lo que no sea un símbolo de código.
Grep devuelve todas las coincidencias de texto; un LSP devuelve el símbolo que se pidió.
¿Funciona el truco de «habla como un cavernícola»?
Un skill de GitHub muy compartido promete hasta un 65 % menos de tokens de salida obligando a dar respuestas cortadas y sin gramática, y ha reunido decenas de miles de estrellas. Las pruebas normales de chat mostraron mejoras cercanas al 10 %, y en programación o trabajo con agentes apenas cambió nada, porque el código fuente no se puede comprimir como la prosa.
Una comparación controlada de JetBrains le puso cifras: el ahorro anunciado era del 65 %, mientras que en tareas reales de agentes fue del 8,5 %. E incluso ese dato se obtuvo con el skill forzado, algo que el equipo calificó de límite superior y no de resultado típico.
El repositorio ya lo reconoce. El skill solo reduce la salida. Los tokens de entrada y de razonamiento no se tocan, y el propio skill añade entre 1.000 y 1.500 tokens de entrada por turno por el mero hecho de existir. El episodio dice más sobre cómo se venden los ahorros de tokens que sobre lo que de verdad ahorra. Un prompt de seis líneas que pida respuestas concisas consigue casi el mismo efecto.
Cambiar de modelo a mitad de sesión cuesta el doble
De todos estos puntos, este es el que pilla a la gente por sorpresa. Bajar a un modelo más barato a mitad de camino suena ahorrador, pero rara vez lo es. El prompt almacenado pertenece al modelo anterior, así que el nuevo tiene que procesarlo todo otra vez y pagar el recargo de escritura.
Elige el modelo antes de empezar. Si quieres enrutar sin pagar por el cambio, usa un router que elija el modelo antes de que salga la petición, y el problema desaparece del todo.
El hábito con más efecto: la precisión
Di exactamente qué formato, qué campos y qué longitud quieres, y el modelo deja de producir cosas que nadie ha pedido. Compara este prompt:
Return a JSON object with keys: "title", "price", "inStock".
No extra commentary.
con "dame la info del producto". El segundo no es solo perezoso. La vaguedad invita a responder de más. La concreción es el hilo común de casi todas las buenas técnicas de prompting, y está ligada a cuánto le pides al modelo de una sola vez.
En resumen
Nada de esto consiste en elegir un modelo más barato. Se trata de lo que entra en el modelo y de cuántas veces tiene que releerse a sí mismo. La lista es corta:
- mantén estable el prompt de sistema
- quédate con un solo modelo
- ejecuta
/contexty quita las herramientas que no uses - activa el LSP y deja claro en las instrucciones que debe preferirse
- describe con precisión la forma de salida que quieres
Con eso se cubre la mayor parte de la ganancia, y empezar mañana no cuesta nada.
Respuestas rápidas
¿De verdad los tokens de salida cuestan más que los de entrada? Sí, unas cinco veces más por token en los modelos de Claude. Aun así, en una conversación larga domina la entrada, porque todo el historial se reenvía en cada turno.
¿Cambiar de modelo a mitad de conversación siempre encarece? El cambio en sí, no. Lo que duele es la caché rota: la siguiente petición se cobra a tarifa de escritura en lugar de la tarifa reducida de lectura. Decidir el modelo de antemano lo evita.
¿Las herramientas MCP de más son siempre un problema de tokens? No. Tienen sentido cuando un servicio necesita acceso estructurado y repetido, y Claude Code aplaza la carga de esquemas cuando se vuelven grandes. Los problemas aparecen en configuraciones pequeñas, en clientes sin carga diferida y en la precisión cuando el modelo tiene demasiadas opciones.