Limites de tokens em PDF por modelo de IA: referência prática (2026)

Toda vez que você manda um PDF para um modelo de IA, está trabalhando dentro de um orçamento de tokens. Passe do limite e o modelo recusa a entrada ou descarta conteúdo em silêncio. O detalhe: cada família de modelo tem um teto diferente, e esses tetos mudam conforme provedores lançam atualizações.

Mantenho essa página atualizada. Conferi cada número abaixo em 8 de outubro de 2026 nas páginas de modelos dos próprios provedores: OpenAI, Anthropic e Google. Se algum provedor lançou algo mais novo depois disso, confie na página dele, não nessa.

Janelas de contexto atuais (outubro de 2026)

A coluna de páginas assume de 250 a 500 tokens por página de texto denso. As linhas com * são menores porque o tokenizador atual do Claude gera mais tokens pro mesmo texto (explico abaixo). A única forma confiável de saber o seu número é medir.

Uma versão anterior dessa página listava o GPT-4o com 128K e o Claude 3.5 Sonnet com 200K. Esses já não são os modelos atuais, e a diferença é a notícia de verdade: quase todo modelo principal hoje aceita perto de um milhão de tokens. Pra maioria dos PDFs a pergunta deixou de ser "vai caber?" e virou "quanto vai custar, e o modelo vai aproveitar bem tudo isso?"

O custo tem um limite próprio, bem abaixo da janela. O Claude Haiku 5.5 cobra cinco vezes mais por um prompt acima de 100K tokens, os modelos GPT-6 dobram o preço de entrada acima de 272K, e o Gemini 3.1 Pro passa de US$ 2 para US$ 4 por milhão acima de 200K. Nos três casos a requisição inteira vai pela tarifa mais alta, não só o que passou do limite (veja as páginas de preço da Anthropic, da OpenAI e do Google).

Deixei de fora modelos abertos como Llama e Mistral. O contexto que dá pra usar neles depende de como e onde você roda, então um número só confundiria mais do que ajudaria.

Por que esses números não são o que você pode usar de fato

Na maioria dos modelos a janela é dividida entre o que você manda e o que o modelo responde, então uma resposta longa sai do mesmo orçamento do documento. O Google lista os limites de entrada e saída do Gemini separadamente. Prompt de sistema, histórico de conversa e chamadas de ferramenta também levam a parte deles.

Regra segura: assuma que pode usar uns 80% da janela declarada pro documento. Numa janela de 1M, planeje uns 800K tokens de PDF.

Mais um detalhe: esses são limites da API. Os apps de chat podem ter limites próprios de tamanho de arquivo ou de contexto, então colar um PDF no chat não garante que você tenha o número inteiro.

Diferenças de tokenizador entre modelos

O mesmo PDF não custa o mesmo número de tokens em todo lugar. O exemplo mais claro hoje é o Claude. A página de modelos da Anthropic diz que 1M de tokens comporta umas 555 mil palavras no tokenizador que chegou com o Claude Opus 4.7, enquanto os modelos anteriores cabiam umas 750 mil palavras no mesmo 1M. Dá uns 35% a mais de tokens pro mesmo texto, e é por isso que as linhas do Claude 5.x mostram menos páginas.

A página de modelos da OpenAI não diz qual codificação o GPT-6 usa, então a contagem o200k do contador de tokens é uma estimativa pra ele, não um número exato. O Gemini também tem tokenizador próprio, e o guia de contagem de tokens do Google mostra como pegar a contagem exata pela API.

Texto em português costuma gastar mais tokens por palavra que inglês, e quanto a mais depende do idioma e do tokenizador. Se seus PDFs não são em inglês, meça em vez de estimar.

Quando chunkar versus mandar o arquivo inteiro

Se o documento cabe confortavelmente em 80% da janela, mande inteiro. Chunking introduz problemas de fronteira e torna o pipeline mais complexo.

Se não cabe, ou se você está montando um sistema de recuperação para vários documentos, chunk em segmentos do tamanho do seu modelo de embedding (normalmente 256 a 1024 tokens por chunk).

Meça antes de decidir

Rode o PDF real pelo contador de tokens antes de escolher fluxo. Se precisar chunkar, o Chunker de PDF divide com overlap e exporta output estruturado direto do navegador.