A janela de contexto é um orçamento, não um balde

Um modelo classificado para 1M de tokens começa a perder o fio bem antes de chegar lá. O número na caixa é a capacidade física do recipiente. O número que governa o seu resultado é a zona onde a atenção ainda se sustenta, e essa zona fica mais perto de 100k tokens, não importa se a caixa diz 200k, 1M ou 2M.

As equipes tratam a janela anunciada como um balde: despejam tudo que pode ser relevante e confiam no modelo para achar o que importa. Os dados de confiabilidade dizem que o balde tem fundo falso.

O número anunciado não é o número de trabalho

A revisão das evidências feita por Garrit Franke (garrit.xyz, maio de 2026) chega a um resumo direto: não confie em janelas de contexto grandes. Duas linhas sustentam isso.

A primeira é o RULER (arXiv 2404.06654), um benchmark que estica tarefas de recuperação e raciocínio sobre entradas longas. Modelos que gabaritam o teste simples de “agulha no palheiro” degradam rápido quando a tarefa exige manter vários fatos e raciocinar sobre eles à distância. O comprimento anunciado e o comprimento utilizável são medidas diferentes.

A segunda é o trabalho da Chroma sobre o que eles chamam de context rot. Conforme a janela enche, a qualidade do resultado cai de forma não-linear. O desempenho não fica estável até despencar num penhasco no limite. Ele se erode ao longo de todo o caminho, e se erode mais rápido quando o contexto carrega distratores, quase-duplicatas ou material vagamente relacionado. O corte prático da “zona inteligente” fica em torno de 100k tokens na leitura de Franke, e esse número quase não se move quando o teto anunciado salta uma ordem de magnitude.

O Nielsen Norman Group chegou ao mesmo lugar pelo lado dos fatores humanos. Paz Perez (NN/g, junho de 2026) diz sem rodeios: “Mais contexto não leva a resultados melhores, porque cada elemento compete pela atenção do modelo.” A atenção é o recurso escasso. Os tokens são apenas como você a gasta. Uma janela que você enche até a borda é um orçamento que você torrou em ruído.

Duas arquiteturas que respeitam o orçamento

Se a janela de trabalho é fixa perto de 100k enquanto as tarefas só crescem, um recipiente maior não resolve. O que resolve é uma arquitetura que mantém cada unidade de trabalho dentro do orçamento. Calvin French-Owen (calv.info, junho de 2026) descreve os dois padrões dominantes como o oráculo e a firma. Trate as cifras exatas de tokens abaixo como aproximadas; elas vieram de um sumarizador de fetch.

O oráculo é a compactação. O Codex da OpenAI mantém um único fio coerente de cerca de 200k tokens e, conforme ele enche, resume o trabalho anterior de volta para baixo, de modo que o fio permaneça dentro da zona de trabalho. Uma mente, uma memória contínua, comprimida periodicamente. A força é a coerência: toda decisão enxerga o mesmo histórico. O risco é o passo de compressão. Resuma mal e você descarta o fato de que precisava três turnos depois, sem nenhum registro de que ele um dia existiu.

A firma são os sub-agentes. O padrão da Anthropic distribui o trabalho para agentes especializados, cada um com seu próprio contexto perto do teto anunciado maior, cada um devolvendo um resultado limitado a um coordenador. A força é o paralelismo e o isolamento: uma subtarefa de pesquisa que incharia o fio principal roda no próprio contexto e devolve um resumo. O custo é a coordenação. O coordenador nunca vê o raciocínio completo de cada agente, só o que cada um escolheu reportar, então uma premissa errada dentro de um agente pode subir limpa para cima.

Os dois padrões mantêm o orçamento por passo fixo. Ambos guardam o contexto ativo pequeno e empurram o resto para outro lugar: para um resumo ou para a janela de um agente separado. É o mesmo princípio por trás de manter a utilização baixa e externalizar estado, aplicado no nível da arquitetura em vez do nível do prompt. Cobrimos a mecânica no nível do prompt em Context Engineering para Agentes de IA.

A parte que as duas arquiteturas escondem

Compactação e sub-agentes compartilham uma fraqueza. Ambos decidem, no seu lugar, o que o modelo pode manter. A compactação joga fora detalhe quando resume. Os sub-agentes jogam fora detalhe quando reportam. Nos dois casos o material descartado fica invisível depois do fato, o que significa que, quando um agente toma uma decisão estranha, você não consegue reconstruir o que ele realmente viu no momento em que decidiu.

Esse é o problema de auditoria, e é onde a governança entra. Uma janela maior não dá uma trilha de auditoria. Arquitetura sem registro também não. O que você precisa é de um log reconstruível: um registro append-only do que entrou no contexto a cada passo, do que foi compactado ou delegado, e do que voltou. O comportamento do agente é função do seu contexto, então o log desse contexto é a coisa mais próxima de uma explicação que você consegue segurar.

Circula uma ideia de apoio de que o log é o agente: que o registro durável e reproduzível de tudo que o agente viu e fez é mais o sistema de registro do que qualquer janela de contexto viva. Posta nesse nível, ela decorre direto dos dados de confiabilidade. Se a janela viva é pequena e com perdas, o log é onde o histórico completo de fato vive, e é a única superfície que você pode auditar, reproduzir ou entregar a um revisor.

É por isso que context engineering pertence à governança, antes de pertencer ao ajuste fino. O mesmo raciocínio guiou nosso argumento de que os 60% do trabalho de IA que ninguém governa são context engineering. A janela que você não consegue inspecionar é a superfície que você não consegue governar.

Por que inchar a janela sai pela culatra duas vezes

Encher a janela faz mais do que torrar orçamento. Degrada ativamente a execução.

O primeiro custo é a diluição da atenção. Cada token distrator compete com os tokens de sinal, e a capacidade do modelo de recuperar o fato certo cai conforme o volume irrelevante sobe. O segundo custo é a sobrecarga de ferramentas, que rastreamos em Code Mode e a sobrecarga de ferramentas do agente: cada definição de ferramenta, cada schema verboso, cada resultado redundante que você deixa no contexto está pagando aluguel no único orçamento que determina a qualidade do resultado. Uma janela entupida com cinquenta especificações de ferramentas tem menos espaço para o problema real, e o modelo tem mais formas de escolher a errada.

Então o instinto de “dar mais ao modelo para que ele tenha tudo que pode precisar” troca uma pequena conveniência por duas penalidades que se acumulam. Menos material, escolhido com mais precisão, vence mais material toda vez que a janela de trabalho é a restrição. E a janela de trabalho é sempre a restrição.

Faça isto agora

Pare de orçar contra o número na caixa. Escolha a arquitetura que cabe no trabalho: compactação quando a tarefa é um único fio longo e coerente e a continuidade importa mais que o paralelismo; sub-agentes quando o trabalho se decompõe em peças limitadas que rodam em isolamento. Depois adicione a camada que nenhum dos padrões dá de graça. Ligue um log reconstruível do que entrou no contexto a cada passo, do que foi compactado ou delegado para fora, e do que voltou. Meça sua utilização efetiva, não sua capacidade teórica, e trate qualquer coisa além da zona inteligente como sinal de problema de design, não como folga.

A janela é um orçamento. Gaste-o em sinal, guarde os comprovantes, e arquitete para que nenhum passo isolado tenha que segurar mais do que de fato consegue atender.

Fontes

garrit.xyz. “Don’t trust large context windows.” Maio de 2026.
calv.info. “The Oracle and the Firm.” Junho de 2026.
Nielsen Norman Group. “Context Architecture.” Junho de 2026.

A Victorino ajuda equipes a desenhar arquiteturas de contexto auditáveis, não apenas janelas maiores: contato@victorino.com.br | www.victorino.com.br