El modo 'light' que costaba seis veces más
Un modo de contexto LIGHT prometía ahorro de tokens. La medición mostró que costaba 6x más y rompía una ruta de código. En la misma sesión, el lazy loading de skills recortó 14k tokens por prompt.
El template se llamaba LIGHT. Se suponía que era la ruta económica. El prompt completo rondaba los 4,6k tokens de entrada. El prompt LIGHT llegó a 28,6k.
¿Por qué? Sin restricciones explícitas, el agente sacó tres skills grandes del disco, unos 90k caracteres de contenido, y lo inyectó todo en el contexto. El modo no era más liviano. Solo era menos controlado, y menos control significó más costo.
También rompió una ruta de código. Al template LIGHT le faltaba una línea que le decía al agente que usara la terminal con curl. Sin ella, el agente caía en un sandbox de Python, chocaba con un SyntaxError y se quedaba trabado. Dos bugs por el precio de una optimización.
La misma sesión sacó a la luz un segundo problema. Cada llamada de agente inyectaba el cuerpo completo de cada skill en el prompt: 14k a 15k tokens por llamada, para skills que quizá nunca se invocaran en esa sesión. El arreglo fue lazy loading. Inyectar solo el frontmatter: nombre y descripción. Cargar el cuerpo completo de la skill bajo demanda, cuando el modelo realmente la pida. El costo bajó en picada.
Los dos problemas tenían la misma raíz. Alguien adivinó qué sería más liviano y no lo midió. El template LIGHT acumulaba tokens porque no restringía nada. Las skills se cargaban de entrada porque parecía más seguro que diferirlas. Las dos cosas estaban mal.
El costo en tokens es invisible a simple vista. Un template llamado LIGHT puede ser el caro. Un lazy load que parece complejidad extra puede eliminar 15k tokens por llamada. La única forma de saberlo es correrlo y medir.
Lección
Nunca supongas el costo de una optimización de tokens. Mídelo: la ruta etiquetada como “light” puede ser la cara.