Resumo Técnico: Redução de Tokens Não é Redução de Custo

Declaração do Problema

Agentes de codificação baseados em API (ex: Claude Code, SWE-agent) operam invocando ferramentas iterativamente e alimentando o modelo de linguagem de grande escala (LLM) resultante com o texto gerado. Este processo cria uma janela de contexto em constante crescimento. Para gerenciar custos, a indústria desenvolveu "camadas de redução de contexto", como compressores de saída de comando, classificadores de recuperação (rankers) e proxies de fronteira de API.

A métrica predominante da indústria para avaliar essas camadas é a redução de tokens (ex: razões de compressão, tokens removidos). Este artigo argumenta que a redução de tokens é um indicador incompleto e muitas vezes enganoso para a métrica que os profissionais realmente buscam: o custo por tarefa concluída com sucesso faturado pelo provedor. Os autores postulam que reduzir o contexto não reduz o custo de forma linear devido a três mecanismos:

1. Economia de Cache: Os provedores modernos faturam o contexto em cache a taxas significativamente descontadas. Remover texto de um prompt que já está em cache (ou que será cacheado) economiza muito menos do que a contagem bruta de tokens sugere.
2. Loops de Feedback de Trajetória: Se a compressão remover o contexto que o modelo precisará posteriormente, o agente pode iniciar turnos diagnósticos extras, relendo arquivos ou pesquisando novamente. Esses turnos adicionais retransmitem todo o prefixo do contexto, anulando a economia inicial.
3. Corrupção de Downstream: A compressão pode corromper formatos de dados exigidos por consumidores não-modelo (ex: pipelines de shell que esperam a saída bruta do grep), levando a falhas silenciosas ou respostas incorretas.

Metodologia

O estudo fundamenta-se em uma campanha pareada, com hash congelado e pré-especificado, de 2.908 execuções faturadas pelo provedor (2.848 analisadas) através de 103 tarefas, 7 repositórios e 3 modelos (Claude Haiku 4.5, Sonnet 5, Opus 4.8). O gasto total medido foi de aproximadamente $643, com 8.263 avaliações de componentes de custo zero de inferência adicionais.

Design Experimental

• Braços: O estudo comparou um baseline (sem compressão) contra três camadas de otimização:
  1. RTK: Uma camada determinística baseada em hooks de produção que reescreve comandos de shell via um proxy de CLI.
  2. RTK-ML: Uma arquitetura que adiciona nove capacidades controladas por flags (propagação de consulta, roteamento de recuperação, pontuação léxica/de embedding, recuperação estrutural, etc.) sobre o RTK.
  3. Headroom: Um proxy de fronteira de API que otimiza payloads em trânsito (caixa-preta para o harness).
• Pareamento: As execuções foram executadas em blocos onde todos os quatro braços rodaram em cópias de trabalho idênticas e novas da mesma tarefa, randomizadas em ordem para mitigar o viés.
• Métricas: A métrica primária foi o Custo por Execução Bem-Sucedida (CPS), definido como o custo total faturado dividido pelo número de execuções bem-sucedidas. O estudo também rastreou a duração da trajetória (turnos), taxas de sucesso e uma decomposição de custo de quatro componentes.
• Modelo de Custo: Os autores reconstruíram os custos faturados usando campos de uso do provedor e preços padrão, decompondo os custos em: (1) Input não cacheado, (2) Criação de cache, (3) Leitura de cache e (4) Output gerado.

Estudos Adicionais

• Estudo de Fundamentação de Passo Único (Single-Shot): Um programa separado em tarefas Go derivadas do SWE-bench testou o impacto da compressão em "âncoras de edição de verbatim" (contexto byte-exato necessário para patches SEARCH/REPLACE).
• Campanha de Longa Duração: Uma linhagem separada de 529 sessões em grandes repositórios sintéticos para observar efeitos de longo horizonte.

Principais Descobertas

1. Anatomia do Custo: Dominância do Cache

O estudo revela que o tráfego de cache de prompt domina a composição do custo.

• Criação e leitura de cache representaram aproximadamente 87% do custo reconstruído dos quatro componentes (cerca de 80% da conta real).
• Output gerado (a resposta do modelo) representou apenas ~10%.
• Input não cacheado foi negligenciável (~1,3%).
• Houve um residual residual ponderado em dólar de 8,7% explicitamente quantificado e não atribuído pelo modelo padrão, que escalou com a configuração de "esforço de pensamento" (thinking-effort) no Haiku 4.5, sugerindo que as cobranças de pensamento estão incorporadas no residual em vez de nos campos de saída padrão.

Implicação: Remover tokens de saída de ferramenta frequentemente remove texto que já está em cache ou que será cacheado com desconto. Portanto, uma redução de 38% nos tokens brutos de saída de ferramenta não se traduz em uma redução de custo de 38%.

2. Desacoplamento entre Redução de Tokens e Redução de Custo

O estudo fornece evidência direta de que a redução de tokens e a redução de custo estão desacopladas.

• O braço RTK-ML reduziu os tokens brutos estimados de saída de ferramenta em 38,4%.
• No entanto, este braço resultou em um aumento de custo pareado de +6,8% (IC 95% [+2,8, +11,3]) em comparação ao baseline.
• A redução de tokens por tarefa foi um preditor fraco de mudança no custo faturado (Pearson r = 0,15).
• O Headroom (o proxy de API) incorreu em uma penalidade de custo massiva de +48,4% sem ganho estatisticamente significativo na taxa de sucesso.

3. A Compressão Pode Prejudicar a Conclusão da Tarefa

No estudo de fundamentação de passo único em tarefas Go:

• A compressão agressiva destruiu as âncoras de edição de verbatim necessárias para a aplicação de patches.
• As taxas de aplicação de patch caíram de 27/40 (bruto) para 15/40 (comprimido).
• Embora o braço comprimido tivesse menor custo por tentativa, o custo por linha resolvida foi maior ($0,515 vs. $0,248) porque a taxa de sucesso colapsou.
• A fundamentação byte-exata (fornecer janelas de contexto brutas) melhorou significamente as taxas de resolução, enquanto a compressão as degradou.

4. Heterogeneidade e Efeitos de Trajetória

• Duração da Trajetória: O custo cresce com o número de turnos. Qualquer camada que adicione turnos (devido a loops de recuperação ou releitura) deve superar o custo de retransmitir todo o prefixo em cache.
• Sensibilidade de Modelo/Esforço: Os resultados variaram por modelo e nível de esforço. Por exemplo, o RTK-ML mostrou aumentos de custo em tarefas de alto esforço do Haiku, mas economias em outras, indicando que não há um "ganho universal para modelos fracos".
• Famílias de Tarefas: As economias foram heterogêneas; o RTK mostrou economias em rastreamento de dependências, mas custos em busca semântica.

Contribuições

1. Anatomia de Custo Calibrada: Uma decomposição de quatro componentes mostrando que o tráfego de cache (criação + leitura) constitui ~87% do custo reconstruído, desafiando o foco em contagens brutas de tokens.
2. Evidência Pareada de Grande Escala: Uma comparação rigorosa, faturada pelo provedor, de camadas de redução de contexto em quase 3.000 execuções, demonstrando que a redução de tokens não prevê a redução de custo.
3. Documentação de Modos de Falha: Identificação de modos de falha específicos onde a compressão corrompe pipelines de shell e destrói âncoras de edição, levando a falhas de aplicação de patch.
4. Taxonomia de Evidência em Camadas: Uma proposta para um novo padrão de avaliação de alegações de eficiência de tokens, movendo-se de métricas de componente (L1-L2) para custo faturado ajustado pelo sucesso (L7).

Significância e Alegações

O artigo afirma que o foco da indústria em "tokens removidos" é ativamente enganoso. Os autores argumentam que redução de tokens não é redução de custo.

• O Mito do "Almoço Grátis": O estudo não encontra evidência de um "almoço grátis" onde a compressão reduza significativamente os custos sem compensações. Em muitos casos (RTK-ML, Headroom), a compressão aumentou os custos.
• Métrica de Decisão: Os autores propõem o Custo Faturado Ajustado pelo Sucesso (Custo por Execução Bem-Sucedida) como a única métrica de decisão para avaliar camadas de otimização de agentes.
• Ressalvas: O artigo é modesto quanto à generalização. O estudo de fundamentação de passo único é pequeno e específico para tarefas Go e formatos SEARCH/REPLACE. Os resultados de longa duração vêm de uma linhagem binária diferente. No entanto, o achado central — que a economia de cache e os loops de feedback de trajetória desacoplam as contagens de tokens dos custos — é apresentado como um fato empírico robusto derivado da campanha autoritativa.

Os autores concluem que os profissionais devem avaliar as camadas de otimização com base no custo ajustado pelo sucesso de ponta a ponta, em vez de razões de compressão de componente, pois estas últimas falham em considerar a complexa economia do cache de prompt e os loops de feedback comportamentais de agentes autônomos.