Claude 5 aperta o contexto e cria orçamento de tokens

O que aconteceu

O Claude 5 impõe limites de contexto mais apertados e introduz um sistema de orçamento de tokens. O modelo aceita menos tokens por prompt, e cada token custa mais. As mudanças visam melhorar confiabilidade, reduzir alucinação e manter a latência previsível.

Os limites de prompt passam a ser aplicados de forma estrita: o que excede é truncado ou recusado, em vez de cortado em silêncio. O desenvolvedor pode definir consumo máximo por requisição no novo modo de orçamento, com controle mais fino de custo e tamanho. Em resumo, o modelo ficou mais restrito e mais previsível, o que obriga a repensar como a informação chega até ele.

Por que isso importa para quem constrói

• Redesenho dos templates de prompt — fluxos que dependiam de prompt longo precisam ser refatorados, dividindo a tarefa em prompts menores ou usando hierarquia.
• Cache e reuso de contexto — guardar trechos frequentes (mensagem de sistema, perfil de usuário, base estática) em consulta rápida mantém o prompt enxuto sem perder informação.
• Controle de custo pelo orçamento — o teto por requisição evita gasto descontrolado quando um agente entra em laço ou gera resposta longa demais.
• Ajuste na orquestração — pode ser necessário verificar o tamanho do prompt antes de chamar o modelo, para o fluxo falhar cedo em vez de estourar tempo.
• Métricas novas — vale acompanhar consumo de token, eventos de truncamento e qualidade da resposta.
• Mais previsibilidade — limites estritos reduzem saída parcial e truncamento silencioso, o que permite tratamento de erro robusto.

A leitura da Tyna

A mudança mais valiosa é a que menos chama atenção: truncamento explícito em vez de silencioso.

Corte silencioso é uma das falhas mais difíceis de diagnosticar em pipeline de agente. O sistema não gera erro, a resposta chega, tudo parece funcionar — e o modelo simplesmente não viu o final do documento. A saída é plausível e incompleta, o que é pior do que uma falha limpa. Times perdem dias procurando problema no prompt quando o problema era que metade do contexto nunca chegou.

Passar a recusar em vez de cortar transforma um erro invisível em erro visível. Isso vai aumentar o número de falhas registradas em fluxos que já rodam — e é uma boa notícia mal disfarçada de má notícia. As falhas já aconteciam; agora aparecem.

Sobre o modo de orçamento: ele é útil e vale entender o que ele não resolve. Teto por requisição protege contra a requisição individual descontrolada, não contra volume. Um agente em laço que faz mil chamadas pequenas respeita o orçamento de cada uma e estoura o mês. O controle que falta é limite agregado por fluxo e por período — e esse continua sendo responsabilidade sua.

Para quem tem prompt longo em produção hoje, o caminho mais barato não é dividir em pedaços: é verificar quanto do contexto enviado é realmente usado. Na prática, boa parte dos prompts longos carrega histórico que não muda e instrução repetida. Enxugar costuma resolver sem refatorar arquitetura.

Perguntas frequentes

P: Ainda dá para usar documentos longos?

R: Sim. Divida o documento e alimente em partes, ou resuma antes de enviar.

P: Como defino um orçamento de tokens no meu fluxo?

R: Os SDKs expõem um parâmetro de limite. Em n8n, um nó próprio que envolva a chamada consegue impor esse teto.

P: Os limites novos afetam meus prompts atuais?

R: Prompts acima do novo tamanho vão falhar ou ser truncados. Revise e refatore para caber, ou use o modo de orçamento para limitar o consumo.