o problema
Quem integra um modelo pela primeira vez costuma tratar a janela de contexto como um campo de tamanho fixo: cabe ou não cabe. O problema é que a conta quase nunca fecha do jeito que a intuição sugere. Não é só a conversa que ocupa espaço. O system prompt ocupa. As definições das ferramentas ocupam, mesmo que nenhuma seja chamada. Os tool results ocupam, as imagens e os documentos ocupam, e o texto que o modelo ainda vai gerar ocupa — a janela guarda o histórico mais a saída do turno. Quem só soma as mensagens visíveis descobre o resto quando a requisição volta com 400.
O segundo problema é pior porque não dá erro. Mesmo dentro do limite, a qualidade não é constante ao longo da janela: conforme a contagem de tokens cresce, precisão e recall degradam. A documentação dá nome a isso, context rot, e tira daí a consequência prática — decidir o que entra no contexto importa tanto quanto quanto espaço sobra. Uma janela de 1 milhão de tokens não é convite para despejar o repositório inteiro nela.
a ideia
A resposta da documentação tem duas metades. A primeira é contabilidade explícita: cada resposta reporta em usage o que a requisição consumiu, e existe uma API de contagem de tokens para estimar antes de enviar. Nada é implícito, nada é grátis. Prompt caching, por exemplo, muda o que você paga por aqueles tokens, não se eles contam.
A segunda é tratar a janela como memória de trabalho que precisa de manutenção, não como um limite que se aceita. Isso aparece em três frentes: o modelo saber quanto lhe resta, o servidor comprimir o que já passou, e o cliente poder apagar seletivamente o que não serve mais.
como funciona
A acumulação é progressiva e completa: cada mensagem de usuário e cada resposta do assistente ficam preservadas turno a turno, e o output de um turno vira input do seguinte. Com prompt caching, o input se divide em input_tokens, cache_read_input_tokens e cache_creation_input_tokens, e os três contam.
Os tamanhos variam por modelo. Fable 5.1, Mythos 5.1, Fable 5, Mythos 5, Opus 5, Opus 4.8, 4.7, 4.6, Sonnet 5, Sonnet 4.6 e o Mythos Preview têm 1 milhão de tokens, com até 128k de saída em uma requisição; os demais, incluindo Sonnet 4.5, têm 200k. Onde há 1 milhão, ele é o default: sem beta header, a preço padrão. Uma requisição aceita até 600 imagens ou páginas de PDF — 100 nos modelos de 200k —, e o limite de tamanho da requisição pode chegar antes do limite de tokens.
Thinking é onde o comportamento se divide. Os tokens de thinking saem do orçamento de max_tokens, são cobrados como output e contam para rate limit. O que acontece com os blocos antigos depende do modelo: Opus 4.5 e Opus posteriores, Sonnet 4.6 e Sonnet posteriores, Fable e Mythos mantêm os blocos anteriores por padrão, e eles passam a contar como input; Opus e Sonnet anteriores e todos os Haiku descartam automaticamente os blocos que você devolve. Dá para inverter os dois casos com thinking block clearing.
Há uma exceção que o código precisa respeitar: ao postar um tool result, o bloco de thinking daquele pedido de ferramenta volta inteiro e sem modificação, com a assinatura. A API verifica a assinatura criptograficamente e devolve erro se o bloco foi alterado.
Sonnet 5, Sonnet 4.6, Sonnet 4.5 e Haiku 4.5 têm context awareness: a API injeta no system prompt uma tag <budget:token_budget> com a janela total e, depois de cada tool call, um <system_warning> com o consumo e o que resta. É automático e o cliente nunca escreve essas tags. Opus 4.7 e posteriores, Fable e Mythos não recebem a injeção; para eles existem task budgets, em beta.
No estouro, dois regimes. Se só o input já passa da janela, todo modelo responde 400 com invalid_request_error. Se input mais max_tokens passa, os modelos 4.5 em diante aceitam a requisição e, se a geração alcançar o limite, param com stop_reason: "model_context_window_exceeded". Nos modelos anteriores isso é erro de validação, a menos que você opte pelo header model-context-window-exceeded-2025-08-26.
o que isso custou
O reconhecimento do context rot é uma admissão desconfortável: a janela anunciada não é uma promessa de qualidade uniforme. O número no datasheet mede capacidade, não desempenho.
A contabilidade honesta também mostra o que o cache não resolve. Ele barateia tokens repetidos, mas não devolve espaço — quem esperava usar cache como técnica de compressão perde a aposta. Do mesmo lado, manter blocos de thinking entre turnos melhora continuidade e custa: eles foram cobrados uma vez como output quando nasceram e voltam a ser cobrados como input em cada requisição seguinte.
A assinatura criptográfica torna o histórico de thinking imutável dentro do ciclo de ferramenta. É bom para integridade e ruim para quem queria reescrever o contexto na mão. E a compaction, que é a estratégia recomendada para conversas longas, é sumarização: o que ela ganha em sobrevida, perde em fidelidade — além de estar em beta, restrita a modelos 4.6 em diante e ao Mythos Preview. Task budgets também é beta.
O custo mais chato é a fragmentação. Preservação de thinking, context awareness, interleaved thinking e o comportamento de overflow mudam de modelo para modelo. Um cliente que fala com Opus e com Haiku precisa carregar os dois regimes.
onde isso aparece hoje
Toda a camada de gerenciamento de contexto da plataforma sai daqui. Compaction resume no servidor os trechos antigos para a conversa continuar além do limite. Context editing oferece o bisturi: tool result clearing para workflows agênticos e thinking block clearing para quando o padrão do modelo não serve. Para as definições de ferramentas, que ocupam espaço antes da primeira chamada, existe a orientação de gerenciar o contexto de tools e a tool search tool, que adia as definições.
Para agentes que atravessam sessões, a recomendação muda de lugar: em vez de esticar a janela, projetar artefatos de estado que permitam recuperar contexto rápido no início da próxima sessão — o padrão multissessão da memory tool. É a mesma tese de curadoria aplicada ao tempo, não só ao tamanho.