1. 1 - Las palancas que funcionan, medidas y no supuestas.
2. 2 - El catálogo, con números.
3. 3 - La palanca más grande: qué servidores MCP están conectados.
4. 4 - La segunda: --tools, y por qué --disallowedTools no sirve.
5. 5 - La tercera: el archivo de instrucciones.
6. 6 - La cuarta: el esfuerzo de salida.
7. 7 - La palanca A: forzar el prompt caching.
8. 8 - Dos creencias refutadas con grupo de control.
9. 9 - defer_loading no quita ni un byte del cable.
10. 10 - Gemini CLI cobra por skills que en modo headless no puede canjear.
11. 11 - El circuito completo.
12. 12 - Lo que todavía no sabemos.

Las palancas que funcionan, medidas y no supuestas.

Una vez que sabes dónde va cada byte, la siguiente pregunta es evidente: qué se puede hacer al respecto.

Y aquí hay que poner una regla antes de empezar, porque sin ella este capítulo se convierte en una lista de trucos:

Toda optimización cuesta algo. Una que no declara su precio no es una optimización, es una trampa.

Cada fila de las tablas que vienen tiene dos columnas obligatorias: lo que ahorra y lo que renuncias a cambio. Ninguna es gratis, aunque alguna se acerca bastante.

El catálogo, con números.

Todo lo que sigue está medido con este mismo proxy, con sonda idéntica y comparando peticiones del mismo tamaño de historial. No son estimaciones.

Repasemos las que tienen más sustancia.

La palanca más grande: qué servidores MCP están conectados.

Es la primera que reveló la medición y sigue siendo la mayor del catálogo. Y curiosamente no está en el código del proxy: está en la configuración de tu cliente.

Medido sobre el mismo tamaño de historial:

Los tres conectores de Google costaban el 76% del peaje de MCP y no se usaban para nada en un proxy escrito en Rust. Estaban ahí porque se conectaron una vez para otra cosa y nadie los volvió a mirar.

Se arregla con un archivo de configuración reducido:

claude --strict-mcp-config --mcp-config .claude/mcp-lean.json

Y aquí van dos advertencias que cuestan caro si se ignoran, porque las dos las cometimos:

El archivo por sí solo no hace nada. Hace falta --strict-mcp-config. Los conectores de la cuenta no vienen de un archivo local, así que una configuración de proyecto suma servidores, no los quita. Sin el flag estricto, tu archivo “mínimo” se añade a los que ya había.

No lo llames .mcp.json. Ese nombre se auto-carga. Si tu archivo reducido se llama así, el servidor que querías conservar acaba cargado dos veces —una por el plugin y otra por el archivo— además de los tres que querías quitar. Es peor que no hacer nada.

La segunda: --tools, y por qué --disallowedTools no sirve.

Esta es la confusión más cara que encontramos, y merece que se diga con claridad.

--disallowedTools NO reduce el cuerpo de la petición.

Es una puerta de permiso, no de payload. El esquema completo de la herramienta se sigue enviando, se sigue pagando en cada turno y el modelo lo sigue leyendo. Lo único que cambia es que tiene prohibido ejecutarla.

Medido: --disallowedTools "Bash" "Edit" "Write" ahorra −421 B sobre 86.198 B de herramientas. Un 0,5%. Prácticamente nada.

La palanca que sí controla el array de esquemas es --tools <lista>. Con ella, esos mismos 86.198 B bajan a 4.371 B. Un −94,9%, usando solo dos herramientas.

Apilando las dos palancas sobre la misma sonda:

  Claude Code, sin cambios          224.653 B
  + --strict-mcp-config, sin MCP    149.221 B   (−33,6%)
  + --tools Read,Bash                51.540 B   (−77,1%)

El 77% del cuerpo es eliminable si la tarea no necesita más que leer y ejecutar comandos.

Y el coste es real, no simbólico: sin edición, sin escritura y sin delegación a subagentes, ese agente no puede modificar código ni buscar por patrón. No es algo que se desactive sin pensarlo. Pero tampoco toda tarea necesita la capacidad completa: un agente que solo tiene que leer y diagnosticar no necesita poder escribir.

La tercera: el archivo de instrucciones.

En el capítulo anterior vimos que el CLAUDE.md es el 48% del peaje fijo. Recortarlo ahorró 29.509 bytes por petición, y el dato que hizo esa decisión fácil fue este: el 85,1% del archivo era flujo, no regla.

Descripciones de procesos, pasos de un workflow, explicaciones de cuándo hacer qué. Todo eso viaja en cada petición, se ejecute ese flujo o no.

La distinción práctica que sacamos: una regla es algo que el modelo debe respetar siempre y que cabe en una línea. Un flujo es algo que solo importa cuando estás haciendo esa tarea concreta, y pertenece a una skill que se invoca bajo demanda, no al bloque que viaja siempre.

El desglose por cabeceras de instructions.by_heading es lo que hace posible esa decisión sin adivinar: te dice qué sección concreta pesa qué.

La cuarta: el esfuerzo de salida.

Esta es la primera palanca del catálogo que recorta en lugar de reorganizar, y la primera que el proxy aplica por sí mismo.

Con OXIDEGATE_FORCE_EFFORT=low, el proxy fija el parámetro de esfuerzo en las peticiones a Anthropic. Medido: −20,0% de tokens de salida y −22,0% de tiempo de reloj.

En exactitud: 45 aciertos de 45 sobre preguntas de respuesta cerrada. Cero pérdida medida.

Con un límite declarado, y esto es importante: las tareas abiertas no se han medido. Que no pierda exactitud respondiendo preguntas con una respuesta correcta única no dice nada sobre si pierde calidad escribiendo código o razonando sobre un diseño. Ese hueco está declarado, no rellenado con una suposición.

Va apagada por defecto, falla cerrado ante un valor desconocido y se anuncia al arrancar. Y la fila de telemetría publica dos campos distintos: requested_effort, lo que pidió el cliente, y effort_forced, lo que impuso el proxy. Separarlos es lo que impide confundir un ahorro del cliente con una intervención del medidor.

La palanca A: forzar el prompt caching.

Muchos clientes no marcan sus peticiones para caché, simplemente porque no lo implementan. Con OXIDEGATE_FORCE_CACHE=true, el proxy inyecta las marcas de control de caché por ellos.

Va detrás de un flag y apagada por defecto, porque es una mutación de la petición, y el proxy tiene como principio no tocar el cuerpo. Junto con la inyección de stream_options.include_usage en la ruta compatible con OpenAI, son las dos únicas mutaciones que existen en todo el código. Las dos están documentadas y las dos se anuncian.

El efecto se comprueba con el propio monitor: baseline antes, cambio, y el panel de delta enseña el cache-hit subiendo.

Dos creencias refutadas con grupo de control.

Y aquí es donde la medición devuelve más valor: no diciéndote qué funciona, sino desmontando lo que dabas por hecho.

defer_loading no quita ni un byte del cable.

Marcar una herramienta como diferida cuesta 21 bytes y no quita ninguno.

El esquema viaja completo. Y tiene todo el sentido cuando entiendes el mecanismo: la búsqueda de herramientas corre en el servidor del proveedor y busca sobre las herramientas declaradas en la petición. Si no están ahí, no hay nada que buscar.

La carga diferida ahorra contexto, es decir lo que el modelo carga por adelantado. Nunca ahorra cable, es decir lo que viaja en cada petición.

Son dos monedas distintas, y confundirlas es el error más caro de este terreno. Volveremos sobre él en el capítulo de la lente, porque es literalmente la razón por la que ese reporte existe.

Gemini CLI cobra por skills que en modo headless no puede canjear.

Medida más rara del catálogo, y una de las más divertidas.

Gemini CLI cobra 288 bytes por skill declarada. Su propio prompt de sistema manda llamar a una herramienta para activarlas. Pero en modo headless, con gemini -p, esa herramienta no está entre las once que envía.

Se paga el listado y no se puede canjear.

En modo interactivo sí: llegan 36 herramientas y la de activación es una de ellas. Dos sondas por modo, resultado consistente. El porqué sigue sin aislarse, y está declarado como tal.

El circuito completo.

Todo lo anterior encaja en un ciclo de cuatro pasos que es, en realidad, la única forma honesta de optimizar:

  1. MIDE          → oxidegate up, y trabaja normal
  2. MARCA         → tecla `b` en el monitor: baseline
  3. CAMBIA        → una palanca, una sola, de la tabla de arriba
  4. COMPRUEBA     → panel Δ desde baseline

Una palanca cada vez. Si aplicas tres a la vez y baja el coste, no sabes cuál sirvió ni cuál te quitó capacidad a cambio de nada.

Y si el cambio no mueve la aguja, se descarta. No se justifica, no se explica, no se deja “por si acaso”. Se descarta.

Lo que todavía no sabemos.

Cierro con la tabla de huecos, que en este proyecto tiene el mismo rango que la de resultados.

• El efecto de effort low en tareas abiertas no está medido. Solo en respuesta cerrada.
• Comparar dos modelos sobre una tarea real no está medido: gasta cuota y no es determinista.
• Repartir la energía entre peticiones solapadas es imposible con los datos actuales, y está declarado como imposible.
• Por qué Gemini declara la herramienta de activación en interactivo y no en headless sigue sin aislarse.

Cada hueco tiene su issue. Declarar la deuda y seguirla son la misma cosa.

En el siguiente capítulo nos vamos a un terreno donde no hay factura que mirar y sin embargo sí se paga: los modelos locales y los vatios.