Claude Code gasta tokens antes de leer tu código: MCP, caché y thinking

Un desarrollador ha medido dónde se va el dinero en Claude Code capturando las peticiones reales que salen hacia la API, en lugar de leer los logs locales a posteriori. El análisis reparte el gasto en cinco componentes y viene acompañado de cost-xray, una herramienta open source que hace esa captura y atribuye tokens y coste a cada fuente.

Los trackers habituales solo dan el total al final de la sesión, y eso no dice cómo se montó la petición antes de que corriera el modelo. Con captura por proxy local se ven los payloads que se envían por el cable, y ahí aparece el desglose.

Los cinco puntos

Los esquemas de herramientas MCP se comen el contexto desde el primer turno. Cada servidor MCP configurado añade su esquema JSON completo a cada petición. Con cuatro o cinco servidores activos se van entre 15.000 y 25.000 tokens de entrada por turno solo en definir herramientas, antes de que el modelo lea una línea de código.

El fallo de la caché de prompt es el segundo. Cuando cambian las definiciones de herramientas o se reordena el contexto, se pierde el descuento del 90% de la caché. Un turno que debería costar 0,03 dólares puede saltar a 0,35 si hay que reescribirla entera.

El thinking extendido pesa más de lo que parece. En refactors complejos los bloques de razonamiento pueden cuadruplicar la salida de código real. Y como los tokens de salida cuestan más que los de entrada, el razonamiento se lleva a menudo más de la mitad del coste en dólares de un turno.

Luego está la salida de herramientas que se acumula sin necesidad. Un grep o unos tests que sueltan 500 líneas de logs se quedan en la ventana de contexto activa en todos los turnos siguientes hasta que entra la compactación.

Y, por último, el impuesto de la compactación: resumir el historial obliga a enviar el contexto inflado entero al modelo de una vez.

Un proxy local para ver la factura

cost-xray captura el tráfico local tanto de Claude Code como de Codex, atribuye tokens y coste a fuentes individuales (servidores MCP, system prompts, bloques de thinking, lecturas y escrituras de caché) y dibuja la ocupación de la ventana de contexto por turno. Va entero en local, sin telemetría ni claves de API externas, y el código está en el repositorio del proyecto.

Para quien mantiene varios servidores MCP activos en un proyecto mediano o grande, la diferencia entre saber que una sesión se ha comido los créditos y saber qué los ha consumido es la diferencia entre apagar un servidor o cambiar cómo se montan las peticiones. Las cifras son las que reporta el autor, no una medición independiente, y cada configuración variará. Lo que sí aporta es una forma de mirar el problema por componente en vez de por total.