A capacidade mede-se, não é uma cifra de um milhão

A linha de «1M tokens» numa ficha de modelo é um teto superior do que a API aceitará, não uma garantia do que o modelo usará bem. Em agosto de 2026, a ofox.ai enviou um mesmo documento inglês de 420 palavras a nove modelos emblemáticos e mediu uma dispersão de 1,56x na contagem de tokens — 614 tokens no Grok 4.20, 957 no Claude Opus 5 — para exatamente o mesmo texto. A janela anunciada é uma afirmação de ficha; a capacidade real é uma medição, e segundo Theorem 3, uma propriedade fica garantida exatamente quando o seu mecanismo está implementado e a medir. O mecanismo aqui é o tokenizador mais a curva de precisão de recuperação, e nenhum aparece na cifra do título.

O que é realmente uma janela de contexto

Uma janela de contexto é o orçamento de tokens para um único pedido à API. Tudo o que o modelo lê e tudo o que escreve tem de caber num só número, e a API não tem estado — não se lembra da chamada anterior. Em cada turno a tua aplicação reenvia a conversa inteira, e a janela é o teto de quão grande pode ser esse reenvio mais a resposta que vem.

Por isso a janela não é memória em nenhum sentido útil. Um produto de chat que parece lembrar o teu nome entre sessões está a guardar esse texto num lado qualquer e a colá-lo de volta na janela em cada pedido. A persistência vive na tua aplicação, não no modelo.

O que conta para a janela

Tudo o que está no pedido, mais tudo o que está na resposta. As partes que as pessoas esquecem são geralmente as mais caras:

• Prompt do sistema. Contabilizado em cada turno, não uma vez por sessão.
• Histórico completo de mensagens. Cada turno anterior de utilizador e assistente que reenvias.
• Definições de ferramentas. Nomes, descrições e esquemas JSON de cada ferramenta que declaras. No Claude estas acrescentam ainda um prompt de sistema de uso de ferramentas por modelo, de 286 tokens no Opus 5 a 675 no Opus 4.7.
• Resultados de ferramentas. Muitas vezes o maior item individual num ciclo de agente; uma listagem de diretório ou uma resposta de API pode chegar a milhares de tokens.
• Tokens de raciocínio. Em modelos com pensamento ativado, o raciocínio conta e é faturado mesmo quando o texto não te é devolvido.
• A própria resposta. É por isto que max_tokens e a janela de contexto interagem: um pedido que não deixa espaço para a saída fica truncado.

«1M tokens» são nove números diferentes

[UNIQUE INSIGHT] A janela anunciada é um teto superior do que a API aceitará, não do que o modelo usará bem — e a distância entre os dois é uma questão de benchmark, não de ficha. O mecanismo que determina a capacidade real é o tokenizador mais a curva de precisão de recuperação, e nenhum aparece na cifra do título.

Entre os nove modelos emblemáticos que a ofox.ai catalogou em 2026-08-12, «1M» resolve-se em nove inteiros distintos: desde um 1.000.000 redondo (Claude Opus 5, Grok 4.20, DeepSeek V4 Flash) até 1.131.072 (Qwen 3.8 Max). Isso é uma dispersão de 13% antes de teres medido seja o que for. No catálogo completo de 119 modelos de texto, a janela mais comum é 256K (25 modelos), com 22 em 1M.

Uma cautela sobre de onde vêm estas cifras. Os catálogos de gateway e a documentação do fornecedor nem sempre concordam: em 2026-08-12 o catálogo da ofox listava Grok 4.20 em 2.000.000 enquanto a própria documentação da xAI indica 1.000.000. A comparação honesta usa o número do fornecedor, e verificas a página do fornecedor quando a cifra importa. Uma ficha é uma afirmação; a doc do fornecedor é uma afirmação mais forte; o prompt_tokens medido no teu conteúdo é a única que responde à tua pergunta.

A dispersão de 1,56x com a mesma entrada

A surpresa mais profunda é que o tokenizador — não o número da janela — é o mecanismo determinante. A ofox enviou um mesmo documento inglês de 2.638 caracteres (um postmortem de serviço de 420 palavras) a nove modelos através de um único endpoint e leu prompt_tokens em cada resposta:

• Grok 4.20: 614 tokens (4,30 caracteres/token)
• GPT-5.6 Sol: 626 (4,21)
• GLM-5.2: 632 (4,17)
• DeepSeek V4 Flash: 634 (4,16)
• Gemini 3.1 Pro: 684 (3,86)
• Claude Opus 4.6: 698 (3,78)
• Qwen 3.8 Max: 706 (3,74)
• Kimi K3: 716 (3,68)
• Claude Opus 5: 957 (2,76)

Uma dispersão de 1,56x com a mesma entrada. O Claude Opus 5 é o valor atípico porque a Anthropic documenta que Claude 4.7 e posteriores usam um tokenizador mais novo que produz aproximadamente 30% mais tokens para o mesmo texto.

Combina as duas tabelas e a janela anunciada deixa de ser o número útil. As cópias desse mesmo documento de 420 palavras que realmente cabem vão de 1.045 no Claude Opus 5 a 1.677 no GPT-5.6 Sol — uma diferença de 1,60x em modelos que todos anunciam «cerca de 1M».

A razão não é constante entre tipos de conteúdo. Num ficheiro TypeScript a dispersão foi de 1,53x e o GLM-5.2 foi o mais enxuto em vez do Grok. Em prosa chinesa a dispersão alargou-se para 1,88x, e ambos os modelos Claude ficaram perto de um token por carácter chinês contra 1,87 do Grok. Toma-os como amostras, não como regras: numa segunda passagem chinesa com mais pontuação os mesmos dois modelos ficaram em 0,98 e 0,96 caracteres/token, o que significa que alguns caracteres custam mais do que um token. Se a tua entrada é código ou não é inglês, mede-a em vez de assumir.

Porque é que os preços por token não são comparáveis entre fornecedores

Como um token não é uma quantidade fixa de texto, os preços por token não são diretamente comparáveis. Um fornecedor que cobra menos por token pode sair mais caro por palavra se o seu tokenizador for mais denso. A Anthropic fatura a janela completa de 1M a tarifas padrão sem prémio de contexto longo, pelo que um pedido de 900K tokens custa o mesmo por token que um de 9K. O Gemini 3.1 Pro passa de 2 $ para 4 $ por milhão de tokens de entrada passado 200K, e o Grok 4.20 de 1,25 $ para 2,50 $ no mesmo limiar. O modelo com a tarifa de título mais barata pode ser o mais caro para trabalho com documentos longos, e a diferença do tokenizador soma-se à tarifa que te calhar.

Uma comparação de orçamento que lê o preço de capa e a janela anunciada está a ler duas afirmações. Uma comparação que mede prompt_tokens no documento real e multiplica pela tarifa do escalão aplicável está a ler uma medição. A primeira é uma suposição; a segunda é um número contra o qual podes faturar.

A janela não é o contexto utilizável

A cautela mais importante é que um modelo que aceita 1M tokens não é o mesmo que um modelo que encontra de forma fiável o facto que enterraste no token 800.000. A precisão de recuperação decai com a distância em todos os modelos públicos, e o tamanho dessa falha é uma questão de benchmark, não de ficha. A ofox aponta RULER, MRCR v2 e NoLiMa como os benchmarks que realmente o medem: o RULER sonda a recuperação a profundidades controladas em contextos sintéticos, o MRCR v2 segue a recuperação multi-salto em documentos longos, e o NoLiMa testa se um modelo ainda encontra a resposta quando a sobreposição lexical entre pergunta e evidência é removida. Nenhuma dessas pontuações aparece numa ficha ao lado de «contexto de 1M».

Trata a janela anunciada como um teto superior do que a API aceitará, e os números de benchmark como o guia do que o modelo usará bem. O primeiro número é um contrato; o segundo é uma medição. Um modelo que aceita um milhão de tokens mas recupera com 60% de precisão à profundidade 500K tem um contexto utilizável muito abaixo do anunciado, e nenhuma janela o resolve — só o faz um mecanismo diferente (encaminhamento, recuperação ou reestruturação).

O mecanismo é a medição, não a ficha

[ORIGINAL DATA] Na Everythink tratamos a janela de contexto como qualquer propriedade afirmada: segundo Theorem 3, uma propriedade fica garantida exatamente quando o seu mecanismo está implementado e a medir. A linha de «1M tokens» não tem mecanismo por trás; o prompt_tokens no teu próprio conteúdo é o mecanismo. Medimos antes de nos comprometermos com um fornecedor, e voltamos a medir quando um fornecedor publica um tokenizador novo, porque a cifra de título se desviou até 1,6x em qualquer direção.

Esta é a disciplina da re-medição. Um tokenizador não é uma propriedade estável da física; é um artefacto de software que um fornecedor pode substituir por um mais novo que produz 30% mais tokens para o mesmo texto, como a Anthropic fez com o Claude 4.7. Quando isso acontece, cada estimativa de capacidade que puseste em cache do tokenizador antigo está errada nos mesmos 30%, e também cada estimativa de custo construída sobre ela. As equipas que se queimam são as que mediram uma vez, escreveram o número num ficheiro de configuração e nunca voltaram. As que se mantêm honestas re-medem com uma cadência, como recalibrarias qualquer instrumento.

Não é uma disciplina nova para nós. O HAI Engine está em produção desde 2016, e cada previsão ramifica para múltiplas Sisters — cada uma um agente de IA tipado com a sua própria personalidade e a sua própria decisão de orçamento de contexto — antes de o Oracle fundir os seus rascunhos num conjunto calibrado. Uma previsão não é um prompt gigante; é um conjunto encaminhado de prompts delimitados, e o limite é uma medição, não uma linha de ficha.

[PERSONAL EXPERIENCE] Há uma década que medimos orçamentos de contexto de agentes, e o erro mais fiável que vemos é escolher um modelo pela janela anunciada e descobrir, em produção, que a carga real cabe 35% menos documentos do que a ficha implicava. A correção nunca é uma janela maior. A correção é medir o teu próprio conteúdo nos modelos entre os quais escolhes — um pedido com max_tokens: 1 devolve prompt_tokens e custa uma fração de cêntimo — e encaminhar em conformidade.

O encaminhamento precede a recuperação

Este é o mesmo princípio que «the space is the router»: na Everythink, a topologia network→community→room encaminha uma consulta antes de qualquer coisa responder. Não despejas o mundo inteiro numa janela e esperas que o modelo encontre o facto certo no token 800.000; encaminhas para a sala que contém o contexto relevante, de modo que a janela que o modelo realmente vê é pequena, fresca e medida. A capacidade é um problema de encaminhamento antes de ser de recuperação, e a recuperação é um problema de medição antes de ser de ficha.

The 21 papers codificam isto. Theorem 3 não diz «maior é melhor»; diz que uma propriedade verifica-se exatamente quando o mecanismo que a garante está no lugar e a medir. Para a capacidade, esse mecanismo é um tokenizador a ler o teu conteúdo e um benchmark a ler a recuperação do modelo à profundidade. O número anunciado não é nenhum dos dois.

A soberania do cliente funciona com medição

A soberania do cliente — a tua rede, a tua marca, os teus dados — tem uma dependência silenciosa com a medição de capacidade. Quando és dono da topologia network→community→room, decides que contexto chega a que agente, e essa decisão é tão boa como a tua estimativa do que cabe. Um operador soberano que confia na ficha entrega a decisão real ao copy de marketing do fornecedor. Um operador soberano que mede o seu próprio corpus mantém a decisão de encaminhamento em casa, onde pertence. O mesmo se aplica à inclusão por conceção: um utilizador com conectividade reduzida num plano de dados medido é melhor servido com uma janela pequena e bem encaminhada, não com uma mangueira de um milhão de tokens, e «pequena e bem encaminhada» é uma medição que só podes fazer se tiveres medido.

Como caber mais na janela que tens

Nenhum destes torna a janela maior; todos reduzem o que gastas dentro dela. Por ordem aproximada de retorno:

1. Cache de prompts. Um prefixo estável — prompt do sistema, definições de ferramentas, um documento sobre o qual continuas a perguntar — é faturado a cerca de 10% da tarifa de entrada num acerto de cache na Anthropic e noutros fornecedores, embora o desconto exato varie e em alguns seja maior. É a alavanca maior para chamadas repetidas, e muda o custo, não a capacidade.
2. Compaction. Resumo do lado do servidor dos turnos anteriores quando a conversa se aproxima do limite, para que uma sessão de agente longa continue em vez de dar erro.
3. Edição de contexto. Limpar resultados de ferramentas obsoletos e blocos de raciocínio antigos do histórico. Os ciclos de agente enchem-se de saída de ferramentas mais do que de conversa.
4. Escolher o tokenizador certo para o teu conteúdo. Como as medições acima mostram, essa decisão por si só vale até 1,6x de capacidade efetiva antes de otimizares mais alguma coisa.

Os três primeiros gerem o orçamento. O quarto escolhe contra que orçamento estás a medir. Os quatro são mecanismos; nenhum é um número maior numa ficha.

O que acontece quando excedes a janela

Recebes um HTTP 400 e nenhuma saída. Nada é silenciosamente truncado. A ofox enviou um pedido sobredimensionado a um modelo de 32.000 tokens e recebeu:

{"error":{"code":null,
  "message":"<400> InternalError.Algo.InvalidParameter: Range of input length should be [1, 30720]",
  "type":"invalid_request_error"}}

Lê esse limite com cuidado: o modelo anuncia 32.000, e o teto de entrada imposto é 30.720, com o restante reservado para a saída. A janela anunciada é o total, não a tua verba de entrada, e o número imposto pode ser inferior ao de marketing.

As formas de erro diferem por fornecedor, por isso não faças pattern-matching na string da mensagem. Os endpoints compatíveis com OpenAI geralmente devolvem um 400 com um código estilo context_length_exceeded. O Claude pode em vez disso terminar o turno com stop_reason: "model_context_window_exceeded", distinto de max_tokens e que precisa do seu próprio ramo no teu código. Trata de ambos. Uma resposta que parou cedo porque a janela encheu não é o mesmo falhanço que uma que parou porque o teu max_tokens era pequeno, e as correções diferem.

Conclusões principais

• A janela anunciada é um teto superior do que a API aceita, não do que o modelo usa bem. A capacidade real é uma medição, e a medição é o tokenizador mais a curva de precisão de recuperação.
• «1M tokens» são nove números diferentes, e o mesmo documento de 420 palavras cabe 1,6x mais cópias num modelo emblemático do que noutro. Os preços por token não são comparáveis entre fornecedores sem ajustar pela densidade do tokenizador.
• Mede o teu próprio conteúdo. Um pedido com max_tokens: 1 devolve prompt_tokens e custa uma fração de cêntimo. Corre-o na tua carga real antes de escolher um modelo pelo tamanho da janela, e volta a corrê-lo quando um fornecedor publica um tokenizador novo.
• O mecanismo é a medição, não a ficha. Segundo Theorem 3, uma propriedade fica garantida exatamente quando o seu mecanismo está implementado e a medir. A linha de «1M» não tem mecanismo; prompt_tokens é o mecanismo.
• O encaminhamento precede a recuperação. Não despejes o mundo numa janela. Encaminha primeiro para o contexto relevante — a topologia network→community→room na Everythink é o mesmo princípio ao nível do produto — para que a janela que o modelo vê seja pequena, fresca e medida.

Perguntas frequentes

Uma janela de contexto é o mesmo que memória? Não. Uma janela de contexto é por pedido, não persistente. A API não tem estado: em cada turno reenvias a conversa inteira, e a janela é o teto do que um pedido pode conter. Tudo o que estiver fora dela desaparece a menos que a tua aplicação o guarde e o envie de novo. Os produtos que parecem lembrar-se de ti entre sessões estão a reinjetar texto guardado na janela, não a tirar de memória do modelo.

Quantas palavras são 1 milhão de tokens? Para prosa inglesa, aproximadamente entre 440.000 e 685.000 palavras — uma gama mais ampla do que a regra habitual admite. Pela medição da ofox num mesmo documento, oito de nove modelos ficam entre 587.000 e 684.000 palavras por milhão de tokens; o Claude Opus 5 é o valor baixo atípico, cerca de 439.000, pelo seu tokenizador mais novo. O código é mais denso (cerca de 2,4 a 3,6 caracteres/token) e o chinês ainda mais (0,9 a 1,9), pelo que a mesma janela de 1M contém muito menos desses.

Qual é a janela de contexto maior disponível em 2026? 1M tokens é o topo da faixa principal. Vários fornecedores situam-se ligeiramente acima do número redondo: Qwen 3.8 Max em 1.131.072, GPT-5.6 em 1.050.000, e Gemini, GLM e Kimi K3 em 1.048.576. Entre os 119 modelos de texto do catálogo da ofox em 2026-08-12, a janela mais comum é 256K (25 modelos), com 22 em 1M.

Porque é que o mesmo ficheiro usa mais tokens no Claude do que no GPT? Tokenizadores diferentes. A Anthropic nota que Claude 4.7 e posteriores usam um tokenizador mais novo que produz aproximadamente 30% mais tokens para o mesmo texto do que os Claude anteriores. No documento inglês de teste da ofox, o Claude Opus 5 usou 957 tokens onde o GPT-5.6 Sol usou 626, uma diferença de 1,53x na mesma entrada. Não há nada de errado; os modelos simplesmente contam de forma diferente, e os preços por token não são comparáveis entre fornecedores sem ajustar por isso.

Posso aumentar a janela de contexto de um modelo? Não. É fixa para o modelo e não há parâmetro para a subir. O que podes mudar é quanto gastas dela: a cache de prompts corta o custo de reenviar um prefixo estável, a edição de contexto limpa resultados de ferramentas obsoletos, e compaction resume os turnos mais antigos. Esses gerem o orçamento em vez de o expandir.

Se queres deixar de adivinhar a capacidade e começar a medi-la, cria a tua rede — a topologia que encaminha antes de qualquer coisa responder, para que a janela que os teus agentes realmente veem seja a que mediste.

Sources

• 2026 — ofox.ai, «What Is a Context Window? Token Limits by Model (2026)» — https://ofox.ai/blog/what-is-a-context-window-token-limits-by-model-2026/
• 2026 — Anthropic, «Context windows» — https://platform.claude.com/docs/en/build-with-claude/context-windows
• 2026 — Anthropic, «Pricing, including the tokenizer note» — https://platform.claude.com/docs/en/about-claude/pricing