O modo 'light' que custava seis vezes mais
Um modo de contexto LIGHT prometia economia de tokens. A medição mostrou que custava 6x mais e quebrava um caminho de código. Na mesma sessão, lazy loading das skills cortou 14k tokens por prompt.
O template se chamava LIGHT. Era para ser o caminho econômico. O prompt completo dava uns 4,6k tokens de entrada. O prompt LIGHT bateu 28,6k.
Por quê? Sem restrições explícitas, o agente puxou três skills grandes do disco, uns 90k caracteres de conteúdo, e injetou tudo no contexto. O modo não era mais leve. Era só menos controlado, e menos controle significou mais custo.
Ele também quebrou um caminho de código. Uma linha que mandava o agente usar o terminal com curl estava faltando no template LIGHT. Sem ela, o agente caía num sandbox Python, batia num SyntaxError e travava. Dois bugs pelo preço de uma otimização.
A mesma sessão revelou um segundo problema. Toda chamada de agente injetava o corpo completo de cada skill no prompt: 14k a 15k tokens por chamada, para skills que talvez nunca fossem invocadas naquela sessão. A correção foi lazy loading. Injetar só o frontmatter: nome e descrição. Carregar o corpo completo da skill sob demanda, quando o modelo de fato pedir. O custo caiu bastante.
Os dois problemas tinham a mesma raiz. Alguém chutou o que seria mais leve e não mediu. O template LIGHT acumulava tokens porque não restringia nada. As skills eram carregadas de antemão porque parecia mais seguro do que adiar. Os dois estavam errados.
Custo de token é invisível na inspeção. Um template chamado LIGHT pode ser o caro. Um lazy load que parece complexidade a mais pode eliminar 15k tokens por chamada. O único jeito de saber é rodar e medir.
Lição
Nunca presuma o custo de uma otimização de tokens. Meça: o caminho chamado “light” pode ser o caro.