1. 1 - Tu pregunta es el 0,03% de lo que subes.
2. 2 - Por qué esto no es una anécdota.
3. 3 - Y empeora en cada turno.
4. 4 - Bytes no son euros, y la diferencia es de cuatro veces.
5. 5 - El peaje fijo: lo que cuesta abrir la sesión.
6. 6 - Las skills sí son perezosas, pero invocarlas no.
7. 7 - Lo mismo, comparado entre herramientas.
8. 8 - Lo que no se puede medir desde aquí.
9. 9 - Qué haces con esto.

Tu pregunta es el 0,03% de lo que subes.

Cuando encendimos OxideGate por primera vez sobre una sesión normal de trabajo, esperábamos encontrar algo interesante. No esperábamos encontrar esto.

Una petición real de un agente. 225.798 bytes de cuerpo. Y dentro:

Setenta y cinco bytes. Una línea de texto. Eso era lo que yo había escrito, y era el 0,03% de lo que se envió por el cable.

El 78,2% del cuerpo era maquinaria de contexto: releer y reescribir el prefijo. Solo el 3,0% era input genuinamente nuevo.

Por qué esto no es una anécdota.

La reacción inmediata al ver ese número es pensar que es un caso extremo. Un agente muy cargado, una configuración descuidada, algo que no le pasa a la mayoría.

No lo es, y el motivo es estructural.

Los esquemas de herramientas son declaraciones. Cada herramienta que tu agente puede usar viaja como una definición completa: nombre, descripción, esquema JSON de sus parámetros, descripción de cada parámetro. Un servidor MCP con cinco herramientas puede aportar varios kilobytes. Y viajan se usen o no, en cada petición, porque el modelo no puede elegir una herramienta que no le has declarado.

Ese es el mecanismo. No es un descuido de configuración: es cómo funciona el protocolo.

Y empeora en cada turno.

Aquí está la parte que más nos costó asimilar.

El coste de una conversación crece N², no N.

Cada turno relee el prefijo entero, y el prefijo crece con cada turno. La API no tiene estado: una conversación es su lista completa de mensajes, repetida en cada petición. Turno 1 envía el prefijo. Turno 2 envía el prefijo más el turno 1. Turno 10 envía el prefijo más los nueve turnos anteriores.

Y la caché no lo arregla, aunque es lo primero que uno piensa.

La caché cambia el precio, no la cantidad. Un token cacheado sube igual por el cable, ocupa la misma ventana de contexto y pasa por prefill igual. Lo que cambia es que cuesta el 10% de la tarifa de input en lugar del 100%. En cada turno. Para siempre.

No existe eso de “cachear al abrir el proyecto y olvidarse”. No hay un estado guardado en el servidor del proveedor esperándote. Hay un descuento sobre un prefijo que sigues enviando entero, cada vez.

Bytes no son euros, y la diferencia es de cuatro veces.

Este es el matiz que separa un dato útil de una cifra llamativa, y hay que decirlo antes de que nadie salga a repetir el 0,03% por ahí.

Ese porcentaje es de bytes. Y con la caché activa, los bytes que subes y los tokens que pagas están desacoplados: el prefijo estable se lee al 10% de la tarifa, mientras que tu turno nuevo se paga entero.

Medido sobre 133 peticiones de un mismo modelo, la misma sección cambia de peso según en qué unidad la mires:

Es decir: medir en bytes subestima unas cuatro veces lo que cuesta tu pregunta.

El 0,03% sigue siendo una cifra real, y el argumento se sostiene: la mayor parte de lo que subes no lo escribiste tú. Pero es una cifra de bytes. No es tu factura.

Por eso GET /requests publica dos campos distintos y separados. cache_by_section estima qué cubo cayó dentro del prefijo cacheado, e input_share_by_section dice qué fracción del input pagado es cada bloque. Fracciones, nunca euros: el precio lo pone tu contrato con el proveedor, no el medidor.

Y cache_by_section es el único campo estimado de todo el contrato. Por eso va anidado y lleva su propio method versionado, para que nadie lo confunda con una medición.

El peaje fijo: lo que cuesta abrir la sesión.

Hay una parte del gasto que ocurre antes de que escribas nada. La llamamos el peaje fijo, y medida en un caso real fueron 69.613 bytes en la primera petición, con esta composición:

  CLAUDE.md (instrucciones)  ████████████████  48%
  Hooks                      ██████████        29%
  Listado de skills          ████████          23%
                                       total: 69.613 B

Tres bloques, cada uno con su propia palanca, y ninguno se reduce escribiendo mejor los prompts.

Las instrucciones son el bloque más caro. En un CLAUDE.md real de 33.460 bytes medido en el cable, cuatro secciones eran el 87% del archivo. Y las cuatro eran protocolo de un flujo de trabajo que viaja en cada petición, se use ese flujo o no.

Ese desglose por cabeceras se publica en instructions.by_heading. Los tamaños salen siempre; los nombres de las cabeceras no viajan salvo que los pidas explícitamente con una variable de entorno, porque son texto escrito por una persona y no una etiqueta que el cliente ya estuviera mandando.

Los hooks son el 29%, y aquí la palanca no es “escribe menos”. Ese bloque lo generan tus hooks, muchos de ellos venidos de plugins que instalaste por otra cosa. La decisión no es de redacción, es de inventario: si cada hook vale su peaje.

Las skills son el 23% y tienen un comportamiento propio que merece detalle.

Las skills sí son perezosas, pero invocarlas no.

Este fue uno de los hallazgos que nos obligó a corregir una suposición.

En disco, un conjunto de skills puede ocupar 200.601 bytes. Al cable llegan unos 1,5 kB. Solo viaja el listado, a 138 bytes por skill en Claude Code.

Es decir: declarar skills es barato. Muy barato.

Pero invocar una cuesta el cuerpo entero de su SKILL.md. Y ese cuerpo entra en el historial, que se reenvía en cada turno posterior. Medido: invocar una skill una sola vez equivale, en coste continuado, a declarar 42 skills más.

La diferencia entre declarar e invocar es de dos órdenes de magnitud, y es exactamente la clase de cosa que no se ve sin medir.

Y hay una palanca que aquí sí elimina el coste entero, no lo recorta: marcar una skill con disable-model-invocation: true hace que no se liste, y por tanto que no se pague en ninguna petición. En la máquina donde se midió eran 11 de 22 skills. Es la única palanca del catálogo que lleva un coste a cero en lugar de reducirlo, porque no toca nada: simplemente deja de ofrecer al modelo algo que no debería elegir por su cuenta.

Lo mismo, comparado entre herramientas.

Como el proxy es agnóstico al cliente, la misma pregunta se puede hacer en cuatro agentes distintos. Declarar una skill cuesta:

Y con 66 skills en lugar de 11, el coste por skill en Claude Code sube a 242 B, donde el 86% viene de plugins. El origen no exime: una skill de plugin pesa 182 B, igual que una propia.

Sobre AGENTS.md la medición corrigió otra creencia extendida: Claude Code no lo manda, son 0 bytes. Codex, pi y OpenCode sí lo mandan, con +159 B, +200 B y +160 B respectivamente sobre un archivo de 74 B de contenido.

Fíjate en el detalle: un archivo de 74 bytes cuesta entre 159 y 200 bytes en el cable. El envoltorio pesa más que el contenido.

Lo que no se puede medir desde aquí.

Y esta parte va incluida a propósito, porque una tabla de hallazgos sin sus límites es marketing.

Separar comandos de skills en el listado es imposible desde el cable. Aparecen en el mismo bloque, con el mismo formato, sin ninguna marca que los distinga. Está medido y está declarado como imposible, no como pendiente.

Los bytes de subida no son exactamente bytes de red. En Codex y Gemini se miden descomprimidos, y con la palanca de forzado de caché el cuerpo reenviado es mayor que el original. El campo se llama prompt_bytes y su documentación lo dice antes de que nadie lo interprete mal.

Comparar herramientas sobre una tarea real sigue sin medirse. Gasta cuota y no es determinista. Está declarado como hueco abierto, con su issue, en lugar de rellenarse con una estimación.

Qué haces con esto.

El valor de esta anatomía no es la anécdota del 0,03%. Es que ahora sabes dónde mirar, y en qué orden:

1. El bloque de herramientas es casi siempre el más grande. Se ataca decidiendo qué servidores MCP están conectados.
2. El historial es el que más crece, y el que más pesa en lo pagado. Se ataca cerrando sesiones y empezando limpio en lugar de arrastrar conversaciones de días.
3. El peaje fijo se paga en cada sesión nueva. Se ataca revisando el inventario: qué instrucciones, qué hooks y qué skills merecen viajar siempre.
4. Tu turno nuevo es el 7,8% de los bytes y el 31,1% de lo pagado. Es lo único de la lista que no conviene recortar.

Ese último punto es, para mí, la conclusión más útil de todo el capítulo. La intuición te dice que escribas prompts más cortos. La medición dice que tu prompt es lo más barato que hay en la petición, y que el ahorro está en todo lo demás.

En el siguiente capítulo entramos precisamente en eso: las palancas concretas, con sus números medidos y con lo que cuesta cada una. Porque todas cuestan algo, y una optimización cuyo precio no se declara es una trampa.