100K de contexto bastam: comprima a memória em vez de comprar uma janela maior

A janela não é o problema

A cada poucos meses um laboratório lança um modelo com uma janela de contexto maior e a conversa recomeça: duzentos mil tokens, depois um milhão, depois dois milhões. A promessa implícita é que memória é um problema de hardware e que alguém vai continuar aumentando.

billion-context, um projeto TypeScript de ranxianglei que vem subindo desde o fim de setembro, assume a posição contrária já no slogan: 100K de contexto basta. Não "basta por enquanto". Basta, se você parar de tratar a conversa como um log em que só se acrescenta.

É um proxy que fica entre seu agente de código e a API do modelo. As requisições passam por ele, são comprimidas e seguem adiante. As respostas são reescritas na volta. Nada muda no modelo. O argumento: a parte cara nunca foi o tamanho da janela, foi o que a gente insistia em colocar dentro dela.

Como a compressão funciona

O proxy interpreta cada requisição no formato Anthropic ou OpenAI, roda seu kernel de compressão sobre a conversa e injeta quatro ferramentas que o modelo pode chamar sozinho: comprimir um intervalo de mensagens em um resumo, descomprimir um intervalo quando os detalhes exatos voltam a ser necessários, buscar por palavra-chave nos resumos comprimidos e nas mensagens visíveis, e conferir o uso do contexto.

A escolha de projeto que importa é que o modelo decide quando comprimir, não um limite fixo. O resumidor embutido de um host costuma disparar quando a janela enche e substitui tudo antes de um ponto de corte por um único resumo que não dá para desfazer. O billion-context comprime em intervalos pequenos, mantém tudo reversível e preserva o cache de prefixo.

Esse último ponto é o detalhe de engenharia que merece atenção. O cache de prefixo é o que torna sessões longas de agente pagáveis; se cada compressão reescreve o começo da conversa, o cache erra e você paga preço cheio por todo o histórico de novo. O projeto afirma que uma sessão saudável mantém 95-97% de acerto no cache de prefixo e que a compressão em si custa no máximo 2% de overhead. São números dele, e ele traz comandos para atribuir uma queda na taxa a uma causa, normalmente o TTL do cache upstream vencendo ou uma troca de modelo.

O número que torna a promessa crível

Fornecedores vivem anunciando economia de tokens. O incomum aqui é um estudo longitudinal que vem junto com o código: quatro meses e meio, três hosts, 174,327 chamadas ao modelo, 18.76 bilhões de tokens de entrada acumulados em um host e cerca de 24.7 bilhões somando todos. O relatório diz que as sessões mais longas chegaram a 8,584 a 12,049 chamadas, com zero violações de janela de contexto em modelos de 204,800 tokens.

Zero violações é a frase que importa. Significa que nenhuma sessão morreu porque a conversa cresceu além do modelo. Todo o resto do estudo está abaixo disso.

Isso também redefine o que é uma "sessão longa". A maioria das pessoas sente os limites de contexto como uma degradação lenta: o agente fica mais vago, esquece uma restrição de duas horas atrás, começa a reler arquivos que já leu. Quando a janela realmente enche, a sessão já está ruim há um tempo. Uma compressão que roda o tempo todo ataca a degradação, não só o ponto de parada.

Se funciona como anunciado na sua carga de trabalho é outra pergunta. Os números são autorrelatados, o benchmark é o uso do próprio autor, e "5 vezes menos tokens" depende inteiramente de quão repetitivas são suas sessões. Uma sessão que lê quarenta arquivos e mexe em três comprime lindamente. Uma que lê um único arquivo gigante e raciocina linha por linha tem bem menos redundância para dobrar.

O que muda no dia a dia

A diferença prática aparece no meio entediante de uma tarefa longa. Um agente conduzindo um refactor tem três tipos de memória: o que decidiu, o que leu e o que tentou e descartou. Uma transcrição crua mantém os três na mesma resolução, e é por isso que um refactor de quarenta arquivos enche a janela com stack traces que já não importam.

A compressão deixa o agente manter as decisões em fidelidade total, dobrar as evidências em resumos e voltar para as linhas exatas só quando precisa. É mais ou menos como uma pessoa trabalha: você lembra que moveu a validação para o middleware, não lembra das seis tentativas que falharam antes.

O modo de falha é igualmente humano. Se um resumo deixa de fora a única restrição que importava, "esse endpoint precisa continuar retrocompatível", o agente quebra isso alegremente quarenta minutos depois, e a camada de compressão te economizou dinheiro ao custo de um bug. A reversibilidade é o que torna isso sobrevivível: dá para descomprimir e conferir o que o resumo realmente dizia.

Por que isso virou uma categoria

Existem pelo menos três abordagens distintas disputando o mesmo problema. Uma é a resposta do laboratório: construir uma janela maior. Outra é a do harness: recuperar em vez de lembrar, e manter só um conjunto de trabalho no contexto. A terceira, que o billion-context representa, é manter a conversa e comprimi-la no lugar, de forma reversível.

Os trade-offs são reais. Uma janela maior é o mais simples e o menos controlável; você paga por ela em toda chamada, tenha o histórico relevância ou não. A recuperação é a mais barata, mas perde continuidade, porque o agente não sabe o que esqueceu. A compressão no lugar tenta segurar continuidade e custo ao mesmo tempo, ao preço de ficar no caminho das suas requisições.

Esse último custo é o que merece reflexão. Um proxy no meio vê todo prompt e toda completion. Para um desenvolvedor solo, tudo bem. Para uma empresa com regras de tratamento de dados, é uma conversa de compliance, e "a gente leu o código, está tudo bem" não é a mesma coisa que uma auditoria.

Tem também a questão menor da licença. O paper técnico é MIT e mora no repositório. A licença do repositório em si aparece como "Other", e não como uma licença OSI padrão. Se você for implantar isso dentro de uma empresa, essa distinção vai aparecer.

A implicação desconfortável

Se a compressão funciona bem o suficiente para que 100K bastem, então boa parte do marketing sobre janelas de contexto mira um problema que sai mais barato resolver em software. Isso não torna janelas maiores inúteis, um documento de 400 páginas ainda precisa caber em algum lugar, mas significa que "temos um milhão de tokens" é um argumento mais fraco do que parece. É como anunciar um tanque maior em vez de um consumo melhor.

Isso também muda como você deveria escrever um agente. Se a memória é compressível, vale incentivar o agente a anotar o que aprendeu em formato estruturado, porque notas estruturadas comprimem muito melhor que logs crus. Uma frase como "o middleware de auth lê o tenant do header, não do cookie" vale mil linhas de stack trace. A camada de compressão recompensa boa escrituração, e isso é uma propriedade simpática para uma ferramenta.

O projeto passa de mil estrelas e fica perto de 400,000 downloads mensais no npm, com badges para mais de vinte clientes. Não é base instalada de hobby. Sugere que a dor é real e bem compartilhada, e que a resposta que as pessoas estão buscando não é mais um zero no tamanho da janela.

Essa é a conclusão útil, seja qual for a ferramenta que você acabe usando. Contexto é orçamento, não recipiente. Times que tratam assim vão continuar fazendo mais por dólar, e os que esperam uma janela maior vão continuar pagando pelo privilégio de não decidir o que importa.