A fatura de API do mês passado chega 340% acima da projeção, sem que o volume de requisições tenha mudado nem o modelo tenha sido alterado. O que mudou foi o tamanho médio do contexto por chamada, que saiu de 1.200 tokens pra 8.700 em seis semanas, sem decisão consciente de aumentá-lo. Pra mim, esse é o caso clássico de inflação de contexto, e a maioria dos times só percebe quando o orçamento estoura.
O problema começa com a mecânica de cobrança dos provedores. A OpenAI cobra o GPT-4o a $2,50 por milhão de tokens de entrada e $10,00 de saída. O Claude Sonnet 4 custa $3,00 e $15,00 nos mesmos termos. Pra modelos de raciocínio como o o1, os valores sobem pra $15,00 e $60,00, com o agravante de que reasoning tokens internos consomem billing de output sem aparecer na resposta. O efeito se manifesta na multiplicação. Cada chamada é stateless, então pra manter coerência conversacional o sistema reenvia o histórico relevante a cada requisição. Um chatbot com dez turnos não processa só a última mensagem, ele reenvia as dez anteriores, as respostas, o system prompt e qualquer contexto de RAG injetado. O custo cresce linearmente com o acúmulo de turnos, mesmo quando a pergunta atual é trivial.
Existe um segundo mecanismo que opera de forma ainda menos visível. Quando se integra retrieval-augmented generation ao pipeline, cada chamada passa a incluir chunks recuperados do vector store, e a calibragem de quantos incluir raramente recebe atenção proporcional ao impacto financeiro. Eu já vi pipelines onde o retriever injetava dez chunks de 500 tokens pra responder perguntas que precisavam de dois. São 4.000 tokens desperdiçados por chamada, que num volume de 50.000 chamadas diárias representam 200 milhões de tokens por dia. No Claude Sonnet 4, $18.000 por mês em contexto que o modelo lê mas não precisa.
O crescimento dos context windows agrava esse comportamento ao criar a ilusão de que o espaço disponível é espaço que deve ser ocupado. Com o GPT-4.1 suportando 1 milhão de tokens e o Claude Sonnet 4 oferecendo 200K por padrão, a pressão por eficiência desaparece. O raciocínio implícito vira: se cabe, manda. System prompts que começaram com 200 tokens crescem pra 2.000 porque alguém adicionou instruções extras e ninguém removeu o que deixou de ser necessário. O efeito cumulativo é um system prompt que consome mais tokens do que a pergunta do usuário, reprocessado integralmente a cada chamada.
A questão computacional explica por que contextos maiores não são simples questão de armazenamento. O mecanismo de atenção em transformers opera com complexidade quadrática em relação ao comprimento da sequência, então dobrar tokens de entrada quadruplica o custo de atenção. Por isso o Gemini 1.5 Pro cobra o dobro por token quando o prompt ultrapassa 128K.
Em pipelines de agentes o problema se compõe. Um agente com tool calling acumula histórico conversacional, resultados de cada chamada e o raciocínio intermediário da seleção. Um pipeline com três agentes em sequência atinge 15.000 a 30.000 tokens acumulados antes da resposta final. Em 10.000 requisições por dia, o custo de input fica entre $450 e $900. O mesmo pipeline otimizado, onde cada agente recebe só o que precisa saber, opera com 5.000 a 8.000 tokens, reduzindo o custo em 60% a 70% sem perda mensurável de qualidade.
O prompt caching é frequentemente apresentado como solução, e na minha avaliação reduz custos quando aplicado corretamente. Na API da Anthropic, cache hits custam 10% do preço de input padrão, e o cache write custa 1,25x o preço base pra janela de 5 minutos. O investimento se paga a partir da segunda requisição que acerta o cache. O caching resolve só a parte estática, e tudo o que muda a cada chamada (histórico, resultados de ferramentas, chunks de RAG) fica de fora. É essa porção dinâmica que tende a crescer sem controle.
Há ainda uma camada de custo que não aparece na fatura. Modelos não processam todos os tokens com atenção uniforme, e existe um fenômeno documentado em benchmarks de long-context onde a acurácia cai pra informações no meio de contextos longos, o que a literatura chama de lost in the middle. Os oito chunks irrelevantes do exemplo anterior competem com o que importa, e o time paga mais por um resultado pior.
Na minha análise, a otimização segue um padrão previsível em times que tratam o problema com engenharia. Começa por medir, o que parece óbvio mas raramente acontece com a granularidade necessária, até porque sem telemetria por chamada qualquer intervenção é chute. Com os números na mão, a auditoria do system prompt vira o alvo imediato. Eu já reduzi system prompts de 3.800 tokens pra 900 sem alteração mensurável na qualidade, o que num serviço com 100.000 chamadas diárias em Claude Sonnet 4 representa $870 por dia economizados. A atenção se move depois pro retriever, e uma vez que o estático e o retrieval estão sob controle, a sumarização do histórico fecha o ciclo.
Existe um trade-off real entre compactação e qualidade, mas na minha avaliação a maioria dos sistemas opera tão longe do limite ótimo que há margem ampla antes que ele apareça. É a mesma dinâmica de quem quer particionar tabelas com queries sem índice. A diferença entre um sistema que gasta $3.000 por mês e um que gasta $15.000 com a mesma funcionalidade está no que cada requisição carrega sem necessidade.