Experimentando o Headroom para otimização de uso de tokens
6 minutos de leitura
Com a crescente adoção de ferramentas de IA para o desenvolvimento de software, uma nova preocupação começou a ganhar espaço nas equipes de engenharia: produtividade por token consumido.
Hoje, a discussão já não é mais sobre a qualidade do resultado obtido com o uso da IA, mas sim sobre o alto custo dos modelos atuais e o esgotamento acelerado dos limites de uso. Com a busca por melhores resultados, a utilização dos modelos mais recentes e de novas features acaba esgotando a janela de uso muito rapidamente.
Nesse cenário, ferramentas que se propõem a otimizar o uso dos agentes de IA surgem no mercado e acabam ganhando destaque.
Pensando em contribuir com times de desenvolvimento que vivem esse cenário e também aumentar nossa própria eficiência na utilização dos tokens, decidimos testar uma dessas ferramentas, o Headroom.
Para resumir, ele é uma camada de otimização de prompt, ou seja, um proxy que comprime as instruções escritas antes que elas cheguem até a LLM, prometendo menor custo e consumo.
A proposta do teste foi simples: comparar execuções equivalentes (mesmo input prompt) utilizando o Codex com e sem o Headroom, a fim de observar se houve, de fato, redução no consumo de tokens utilizando a ferramenta para atividades comuns do dia a dia de desenvolvimento.
Tarefas
Utilizamos atividades reais de desenvolvimento, como:
- Criação de documentação em Markdown;
- Criação de cards no ClickUp via MCP;
- Implementação de funcionalidades a partir de um plano;
- Melhorias pontuais em código existente;
- Commits de alterações;
- Análise de código para identificação de melhorias;
- Ajustes de testes automatizados.
Antes de analisar os resultados, vale observar a visão consolidada dos dados obtidos. A tabela abaixo resume as principais tarefas executadas.
| Tarefa | Modelo | Tokens Codex em mil | Tokens Headroom em mil | Diferença | % |
| Documentação técnica | gpt-5.4 medium | 21 | 28 | 7 | 34% |
| Criação de cards | gpt-5.4 medium | 49 | 67 | 19 | 39% |
| Implementação | gpt-5.5 high | 202 | 249 | 47 | 23% |
| Melhoria de código | gpt-5.5 high | 143 | 488 | 344 | 241% |
| Commit | gpt-5.5 high | 42 | 61 | 20 | 47% |
| Code Review | gpt-5.4 mini | 22 | 28 | 6 | 29% |
| Ajuste de testes | gpt-5.4 medium | 40 | 130 | 90 | 225% |
Quantidade de tokens extraída ao final de cada sessão do Codex cli.
Resultados
A hipótese inicial era a de que conseguiríamos utilizar menos tokens e obter resultados semelhantes para as mesmas tarefas que já fazem parte do nosso dia a dia. Entretanto, na prática, não foi bem assim.
Observamos que, em todas as tarefas, as execuções com o Headroom evidenciaram um uso maior de tokens e da janela de contexto. Em alguns casos, a diferença foi pequena; já em outros, o consumo chegou a ser mais que o dobro dos tokens gastos na comparação, sem refletir uma melhoria na entrega.
O resultado mais curioso apareceu em uma tarefa relativamente simples de ajustes localizados no código. Enquanto a execução sem o Headroom consumiu aproximadamente 143 mil tokens, a outra ultrapassou 480 mil.
Apesar da diferença superior a 240% no consumo, o resultado final apresentou ganhos limitados. Além disso, utilizando apenas o Codex, verificamos um tempo de trabalho da ferramenta significativamente menor e, adicionalmente, ela exigiu muito menos aprovações do desenvolvedor.
Também conseguimos observar que, em alguns casos, o modelo se perdeu com as instruções comprimidas pelas estratégias do Headroom e, portanto, teve que contornar a situação chamando um mesmo comando mais uma vez (sem otimizações) para receber um retorno satisfatório, resultando em um maior uso dos recursos da IA, o que poderia explicar o maior consumo de tokens e aprovações.
A imagem abaixo evidencia um exemplo desse comportamento. A compressão de contexto utilizada pelo Headroom reduziu excessivamente as informações disponíveis para execução da tarefa.
Como consequência, o modelo precisou de contexto adicional por meio de novas chamadas e por isso, o mecanismo que deveria reduzir o consumo de recursos acabou gerando etapas extras de processamento, aumentando a utilização de tokens e o número de interações necessárias para concluir a tarefa.
Conclusão
Nos testes realizados, o Headroom não entregou o resultado esperado. Em vez de reduzir o consumo de tokens, as execuções apresentaram um custo maior, mais uso de contexto e, na maioria dos casos, demandaram mais interações do desenvolvedor para chegar a resultados semelhantes aos obtidos com o Codex sem a camada de otimização.
Nesse sentido, não temos evidências suficientes para afirmar exatamente o motivo desse comportamento, porém, possivelmente a estratégia de compressão de contexto utilizada pelo Headroom pode ter removido ou simplificado muito as informações importantes para a execução da tarefa.
Com esse teste, aprendemos que otimizar prompts não é apenas uma questão de reduzir texto antes de enviá-lo para a LLM. Quando essa compressão altera o entendimento do modelo ou exige retrabalho, o ganho esperado pode rapidamente se transformar em custo adicional.
Embora a proposta seja interessante, os dados observados mostram que a compressão de prompts nem sempre se traduz em eficiência prática. Pelo menos no nosso cenário, o uso direto do modelo se mostrou mais econômico e previsível.
Este experimento representa apenas um recorte específico de tarefas e ferramenta. Seria interessante repetir o estudo em outros contextos, com diferentes modelos, agentes e tipos de atividade, para entender melhor em quais cenários, estratégias de otimização de contexto podem efetivamente gerar ganhos.
Independentemente dos resultados obtidos neste experimento, está claro que encontrar formas de utilizar melhor a janela de contexto, reduzir desperdícios e aumentar o retorno por token consumido será cada vez mais importante.
Nesse cenário, ferramentas como o Headroom podem ganhar cada vez mais destaque e se tornarem tão relevantes quanto o aumento da capacidade dos próprios modelos.
