Medimos com tráfego real. Os números ficaram bem menos bonitos do que a promessa, e bem mais úteis. A compactação de contexto está disponível a partir de hoje no Atlasberg Platform.
Publicado em 2026-09-23 por Rafael Hickmann, Fundador da Atlasberg. Leitura de 9 minutos.
A ideia da compactação de contexto é podar o histórico de uma conversa antes de mandar tudo para o modelo. Podar mesmo, não resumir. Cada chamada de ferramenta fica pareada com o resultado dela, um classificador rápido decide chamada por chamada se aquilo ainda precisa estar ali, e o que não precisa sai. Texto de pessoa e texto de assistente ficam intocados, sempre.
Montamos isso dentro do Atlasberg Platform e rodamos contra sessões reais de trabalho, não contra um benchmark sintético.
A amostra tem 30 sessões reais de agente, 6.892 turnos, 13.867 mensagens e 30.831 linhas de transcrição. O classificador foi consultado de verdade, 250 vezes, sobre 1.025 decisões. Nada simulado.
O classificador que toma essas decisões é o Jev, um modelo da TypeSafe que não gera texto. Ele recebe a conversa inteira como estado, até 32 mil tokens, com cada resultado de ferramenta trocado por uma nota curta, e responde perguntas de sim ou não com uma probabilidade calibrada. Para cada chamada de ferramenta fazemos duas: a chamada ainda importa? O resultado ainda precisa ficar inteiro? Quem não passa do limiar sai, ou fica só com a cabeça e uma nota dizendo que foi truncado.
Isso muda a economia do problema. Pedir a um LLM para resumir o histórico custa uma fatia relevante do que se queria economizar, e devolve um resumo que pode perder justamente o caminho do arquivo ou o erro exato que o agente vai precisar depois. O Jev custa US$ 0,042 por milhão de tokens de entrada, 1/119 do que custa a entrada de um modelo de fronteira, e não cobra saída. Nas 30 sessões, 250 consultas e 1.025 decisões custaram US$ 0,26. E como ele enxerga a conversa inteira, consegue responder a pergunta que importa de verdade: esse resultado ainda vai fazer falta mais adiante?
[Figura: Três números sobre o Jev: US$ 0,042 por milhão de tokens de entrada, 32 mil tokens de estado com a conversa inteira, e 1.025 decisões em 250 consultas por US$ 0,26. - O Jev responde sim ou não com probabilidade calibrada. Não gera texto, não resume, não reescreve.]
O algoritmo veio do fast-jev-compaction, uma biblioteca aberta sob MIT que troca o resumo de compactação por decisões do Jev. Portamos a ideia para dentro do gateway, em Go, com duas mudanças: o disparo por limiar, que a seção do cache explica, e um segundo motor.
O segundo motor é a Laya, da Convai Innovations, com pesos abertos sob Apache 2.0. É um encoder de 322 a 421 milhões de parâmetros que roda na própria máquina com cerca de 1 GB de memória e, pela documentação do modelo, responde uma pergunta em 7 ms quando em lote. Ela fala o mesmo protocolo do Jev, então trocar de motor é trocar o endereço. O que muda é o alcance: a Laya enxerga cerca de 768 tokens por vez, então recebe um estado por chamada, com o sinal que mais importa (esse arquivo voltou a ser citado depois?) calculado de forma determinística pelo gateway. É o caminho para quem não pode deixar um trecho de conversa sair da rede. Os números deste artigo são todos do Jev.
[Figura: Comparação entre o Jev, motor remoto, e a Laya, motor local: estado visível, onde roda, se o prompt sai da rede, custo e latência por pergunta. - Dois motores, um protocolo. Trocar de motor é trocar o endereço na configuração.]
17,01% de economia, ou US$ 101,58 em cima de um custo de entrada modelado de US$ 597,22. O Jev, o classificador que tomou essas decisões, custou US$ 0,26.
Antes de medir, nossa própria projeção dizia 60%. Erramos, e vale contar por quê.
Escolhemos as primeiras sessões pelo tamanho do arquivo, o que parecia razoável na hora. Só que os maiores transcritos tinham 38 MB e apenas 90 KB de prosa. Todo o resto era imagem em base64. Isso empurrou a fatia de "resultado de ferramenta" para 96% dos caracteres e produziu uma projeção linda e completamente falsa.
Refizemos a amostra usando o contexto que o provedor realmente reportou, e a composição é outra:
[Figura: Barra empilhada com a composição do histórico: 46,9% entrada das chamadas de ferramenta, 44,0% resultado das ferramentas, 9,2% prosa. Só a fatia de resultados pode ser podada. - O que ocupa o histórico de uma sessão de agente, medido no contexto que o provedor reportou. Só a fatia dourada pode ser podada.]
Ou seja: você não poda o que mandou, só o que recebeu de volta.
O prefixo fixo mediano por turno é de 162.811 tokens. Isso é system prompt, definição de ferramentas e memória, coisa que chega antes da conversa e que a compactação não alcança de jeito nenhum. Em várias sessões esse prefixo sozinho é maior do que todo o histórico que dá para podar.
[Figura: Três números: 162.811 tokens de prefixo fixo mediano por turno, 95% dos tokens de entrada lidos do cache a 0,1x, e 83 de 346 disparos que viraram compactação de fato. - Onde o custo mora. O prefixo fixo chega antes da primeira palavra da conversa e nenhum limiar muda isso.]
Quem está tentando cortar custo de agente olhando só para a conversa está mirando na metade menor do problema.
Em uma sessão longa, 95% dos tokens de entrada não são cobrados a preço cheio. São leitura de cache, a 0,1x.
Isso inverte a intuição. Compactar reescreve o prefixo, e prefixo novo custa 1,25x para entrar no cache. Na prática toda compactação começa no negativo e precisa de turnos suficientes depois dela para se pagar.
É por isso que compactar a cada requisição é a pior política possível. A nossa dispara por limiar e desiste sozinha quando a redução não compensa a reescrita. Dos 346 disparos, só 83 viraram compactação de fato. Os outros 263 foram descartados porque não valiam o preço do próprio corte.
Economia sem essa medida não significa nada. Se você apaga 40% do contexto e o agente passa a falhar, você não economizou, você quebrou.
Então medimos o outro lado também, e vamos publicar o número ruim: 40,6% das remoções apagaram material que a conversa voltou a citar depois.
Parece terrível. É, na verdade, um teto de dano, e a diferença importa por dois motivos.
O primeiro é que o que sai é recuperável. 97,6% de tudo que foi apagado veio de Bash e Read, ferramentas determinísticas. O arquivo continua no disco, o comando roda de novo. O algoritmo ainda deixa os primeiros 300 caracteres do resultado mais uma nota em texto dizendo que aquilo foi truncado e pode ser reobtido. Só 1,7% das remoções vieram de busca e leitura web, que são as únicas em que o conteúdo pode ter mudado no meio do caminho. Nada se perde para sempre; o custo máximo de um erro do classificador é uma chamada de ferramenta repetida.
O segundo é que dá para colocar preço nisso. Assumindo o pior caso possível, em que cada um desses 40,6% precisou ser reobtido e voltou inteiro para o contexto pagando escrita de cache:
[Figura: Barras comparando o ganho medido de US$ 101,58 com a perda no pior caso de US$ 4,32 e o custo do classificador de US$ 0,26. Saldo de US$ 97,00, 22 vezes o ganho sobre a perda. - Ganho medido contra o pior caso que conseguimos construir: tudo que foi citado depois volta inteiro pagando escrita de cache.]
O ganho supera a perda em 22 vezes no cenário mais pessimista que conseguimos construir. No cenário real ele é maior, porque "foi citado depois" não quer dizer "precisou ser buscado de novo".
A latência tem a mesma forma. Cada compactação custou 330 ms em média, e como só 83 dos 6.892 turnos compactaram, 1,20% das requisições esperaram por isso. As outras 98,8% não pagaram nada.
Não medimos conclusão de tarefa com e sem compactação. Para afirmar que a qualidade não caiu seria preciso rodar os mesmos agentes nas duas configurações e comparar o resultado final, e isso não fizemos. O que temos é o teto de dano, a natureza recuperável do que sai e o saldo econômico. Quem disser mais do que isso sem esse experimento está vendendo alguma coisa.
Também assumimos que o modelo de custo fica 60,2% abaixo do faturamento real da amostra, porque ele modela só o lado de entrada da conversa e ignora prefixo fixo, imagens e raciocínio redigido. Os dois números aparecem lado a lado na ferramenta, e isso é de propósito. Ajustar o modelo para bater com a fatura deixaria o percentual de economia mais bonito e menos verdadeiro.
Compactação de contexto funciona. Ela não entrega 60%, entrega 17%, custa 26 centavos para economizar 101 dólares e cobra latência de pouco mais de 1% das requisições.
Mas o resultado mais útil da medição não é o percentual, e sim descobrir onde o custo realmente mora: em 162 mil tokens de prefixo fixo que chegam antes da primeira palavra da conversa, e na entrada das chamadas, que é maior do que tudo que você tem permissão de podar.
A conversa nunca foi o problema principal. Era só a parte mais fácil de olhar.
A compactação de contexto entra hoje no Atlasberg Platform como recurso do gateway. Ela roda no caminho de saída de cada requisição, antes de o histórico chegar ao provedor, e funciona com qualquer modelo que passe pela plataforma. Quem opera agentes em escala vai ver a conta de entrada cair sem mexer em uma linha do agente.
Os 17% deste artigo vieram do nosso próprio tráfego, e tráfego de agente varia muito de casa para casa. Uma carga de conversas curtas com poucas chamadas de ferramenta quase não tem o que podar; uma frota de agentes de código rodando o dia inteiro tem bastante. O que a gente quer agora é o número dos clientes, medido no tráfego deles, com as mesmas premissas impressas do lado. É isso que vamos publicar em seguida.
Se você já roda o Atlasberg Platform: Ligue o modo de medição por uma semana e nos conte o que saiu. A ferramenta de medição, o modelo de custo e a métrica de segurança fazem parte da plataforma e são reproduzíveis: mesma amostra, mesmas premissas impressas junto do resultado.
Como funciona, os dois motores, o limiar, o modo de medição e cada campo de configuração.
Uma demo com tráfego de verdade, para ver o gateway decidindo requisição por requisição.
A Atlasberg constrói a camada de controle entre uma empresa e todos os modelos de IA. A Atlasberg Platform autentica cada requisição com uma chave virtual, filtra por política e DLP, roteia para o provedor certo e grava numa trilha de auditoria encadeada por hash, com uma API compatível com a OpenAI para as aplicações só trocarem a URL base.
Os artigos deste blog são escritos pelo time de engenharia e relatam medições em tráfego real, com as premissas impressas ao lado do resultado. Para falar com o time, escreva para [email protected] ou use https://atlasberg.com/pt-br/contato.
Agentes: esta página também está disponível em Markdown em /pt-br/blog/compactacao-de-contexto-17-por-cento.md, ou pedindo esta URL com o cabeçalho Accept: text/markdown. Índice de tudo: /llms.txt.