Todos os artigos

Janela de contexto na prática: o que cabe de verdade em 200k vs. 1M tokens

Por LW Forge — mantenedora do LLM Scout · Atualizado em 3 de agosto de 2026

Uma janela de contexto de 128.000 tokens parecia generosa há um par de anos; hoje é a ponta pequena da faixa. A linha principal da Claude vai até 200k, enquanto GPT-5.6, Gemini 2.5, GLM-5.2, Kimi K3 e Nemotron 3 Ultra vêm todos com cerca de um milhão de tokens de contexto. Os números de manchete são fáceis de achar — o que eles significam de verdade para os seus documentos, sua fatura e a qualidade da resposta é menos óbvio.

O que 200k e 1M tokens realmente comportam

Usando a mesma conversão que roda na nossa calculadora de janela de contexto, um milhão de tokens dá aproximadamente 770.000 palavras em densidade típica de inglês — algo como 8-9 romances médios, ou cerca de 2.000 páginas densas de texto. Uma janela de 200k comporta uns 20% disso: por volta de 150.000 palavras, 1-2 romances, ou cerca de 400 páginas. Para a maioria dos documentos corporativos — contratos, relatórios, bases de código de tamanho moderado — 200k já é generoso; um milhão de tokens foi feito para cargas de repositório inteiro ou múltiplos documentos, não um único relatório.

Confira quantas páginas cabem no GPT para a versão em contagem de páginas dessa mesma conta, detalhada por modelo.

Janelas maiores custam dinheiro de verdade para preencher

Uma janela de contexto é capacidade, não armazenamento grátis — todo token dentro dela, seja o seu prompt ou dez documentos reaproveitados, é cobrado como entrada em toda requisição que o incluir. Preencher uma requisição de um milhão de tokens na tarifa de um modelo topo de linha já custa alguns dólares só de entrada, numa única requisição; faça isso dez mil vezes por mês e o número deixa de ser trivial. Uma particularidade específica de provedor que vale saber: a tarifa por token do Gemini 2.5 Pro praticamente dobra para a parte do prompt que passa de 200k tokens, então uma requisição "quase pequena" e uma "genuinamente enorme" não são precificadas na mesma curva, mesmo no mesmo modelo.

A regra prática: trate a janela como um teto que você tem permissão de se aproximar, não como uma meta a preencher por padrão. Uma aplicação que deixa o histórico de conversa ou o contexto recuperado crescer sem controle vai bater no orçamento de tokens — ou na fatura — bem antes de bater no limite real do modelo.

Perdido no meio: por que encher a janela sai pela culatra

Avaliações de contexto longo continuam achando o mesmo padrão: modelos lembram melhor de informação perto do início e do fim de um prompt do que de material enterrado no meio, mesmo bem dentro do limite declarado. Jogar uma base de conhecimento inteira no contexto só porque a janela tecnicamente permite não custa só mais — a resposta pode piorar, porque o fato que importa fica competindo com milhares de tokens de ruído pela atenção do modelo.

Dois hábitos decorrem disso. Coloque instruções e os fatos mais decisivos perto do início ou bem no final do prompt, não enterrados na página 40 de 60. E quando seu material de origem é grande, a recuperação (retrieval) — indexar o material e enviar só as passagens relevantes para a pergunta atual — costuma vencer o "encher a janela" tanto em custo quanto em qualidade, porque o modelo raciocina sobre dezenas de tokens relevantes em vez de milhares irrelevantes.

Quando uma janela maior vale de fato a pena

O tier de um milhão de tokens compensa o custo em alguns casos específicos: raciocinar sobre uma base de código inteira numa única passada em vez de arquivo por arquivo, manter uma coleção de documentos completa (não só um relatório) no contexto para referência cruzada, ou sessões longas de agente multi-turno em que podar o histórico não é opção. Chat de turnos curtos, classificação e perguntas sobre um único documento raramente precisam de mais que uma fração até de uma janela de 200k — confira seu uso real na calculadora de tokens antes de supor que precisa da maior janela do cardápio.

Onde fica o ponto de equilíbrio com retrieval

Não existe uma contagem fixa de páginas em que o retrieval vence de forma definitiva o "encher o contexto" — depende de quantas vezes você consulta o mesmo material. Um documento sobre o qual você vai fazer uma ou duas perguntas geralmente é mais barato só colar inteiro, mesmo com algumas centenas de milhares de tokens; uma base de conhecimento que você consulta centenas de vezes por dia quase sempre sai mais barata indexada uma vez e consultada repetidamente, já que encher o contexto recobra a fonte inteira a cada pergunta. Se você está reenviando o mesmo bloco grande de texto em várias requisições, o prompt caching é a outra alavanca que vale conferir antes de investir num pipeline de retrieval.

Meça antes de arquitetar em cima disso

Especificações de janela de contexto são fáceis de comparar numa ficha técnica e fáceis de errar na prática, porque o número que importa é a contagem real de tokens do seu documento, não a contagem de páginas nem o tamanho do arquivo. Rode uma amostra real na calculadora de tokens, confira exatamente quantas páginas a janela de um modelo comporta em quantas páginas cabem no GPT, e precifique a requisição na calculadora da OpenAI ou da Claude antes de comprometer uma arquitetura com um tamanho de janela específico.