# Compactar o contexto economiza 17%, não 60%

> Medimos a compactação de contexto em 30 sessões reais de agente: 17,01% de economia, 26 centavos de Jev para poupar 101 dólares, e onde o custo realmente mora. Disponível hoje no Atlasberg Platform.

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.

## Sobre este artigo

Publicado em 2026-09-23 por Rafael Hickmann, Fundador da Atlasberg. Leitura de 9 minutos.

## O que testamos

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.

## Quem decide é o Jev, não um LLM

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.]

## O número

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ê.

## Por que a projeção estava errada

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 que ocupa o histórico: Entrada das chamadas de ferramenta | Fatia: 46,9% | Dá para podar?: Não. Se a chamada fica, a entrada dela fica junto
- O que ocupa o histórico: Resultado das ferramentas | Fatia: 44,0% | Dá para podar?: Sim, e é o único alvo
- O que ocupa o histórico: Prosa, incluindo raciocínio | Fatia: 9,2% | Dá para podar?: Não, por invariante

## O achado que muda o problema

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.

## O segundo achado: o cache já tinha resolvido boa parte

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.

## E a qualidade? A pergunta que ninguém publica

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.

- Linha: Ganho medido | Valor: US$ 101,58
- Linha: Perda no pior caso (reobter tudo que foi citado depois) | Valor: US$ 4,32
- Linha: Custo do Jev | Valor: US$ 0,26
- Linha: Saldo | Valor: US$ 97,00

## O que não medimos, e você deveria cobrar

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.

## O que fica

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.

## Está disponível a partir de hoje

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.

- Nasce desligada. Ligar é um ato deliberado, e qualquer falha do motor de decisão termina no mesmo lugar: o histórico original é enviado. Nenhuma requisição é quebrada para economizar token.
- Tem um modo de medição. Com ATLASBERG_COMPACTACAO_MEDIR=1 o gateway calcula o que a compactação economizaria no seu tráfego sem compactar nada. Os números deste artigo saíram exatamente desse modo.
- Dois motores, um protocolo. O Jev, remoto, vê a conversa inteira e exige consentimento explícito, registrado na trilha de auditoria. A Laya, local, roda na própria máquina e nenhum trecho de conversa sai da rede. Trocar um pelo outro é trocar o endereço.
- Decide por chamada, não por idade. Dois resultados da mesma ferramenta na mesma sessão podem receber vereditos diferentes.

### Documentação da compactação de contexto

Como funciona, os dois motores, o limiar, o modo de medição e cada campo de configuração.

### Ver o Atlasberg Platform ao vivo

Uma demo com tráfego de verdade, para ver o gateway decidindo requisição por requisição.

## Sobre a Atlasberg

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 contact@atlasberg.com ou use https://atlasberg.com/pt-br/contato.

## Mais da Atlasberg

- [Todos os artigos](https://atlasberg.com/pt-br/blog)
- [Documentação da compactação de contexto](https://atlasberg.com/pt-br/docs/console/compactacao-de-contexto)
- [Visão geral da plataforma](https://atlasberg.com/pt-br)
- [Fale com a engenharia](https://atlasberg.com/pt-br/contato)

---
Fonte: https://atlasberg.com/pt-br/blog/compactacao-de-contexto-17-por-cento
Empresa: Sobimann Tecnologia da Informacao LTDA (Atlasberg), Porto Alegre, RS, Brasil.
Contato: contact@atlasberg.com - resposta em até um dia útil.
Índice para agentes: https://atlasberg.com/llms.txt