Claude lança message threads, que permitem aos agentes enviar só as mensagens novas

O problema que o recurso ataca é conhecido de quem opera agentes longos. Um agente de código pode fazer centenas de requisições numa sessão, e cada uma reenvia todas as mensagens e resultados de ferramentas anteriores. Quando a conversa chega a centenas de milhares de tokens, reenviar tudo soma tempo antes de o Claude começar a responder. Com message threads, o agente manda só o que é novo desde o último turno, e o tempo até o primeiro token (TTFT) cai.

Na prática, o primeiro request inclui a conversa completa e abre uma thread, usando o parâmetro thread na Messages API. Os seguintes levam só as mensagens novas e o ID da resposta anterior. A thread fica em memória, criptografada e sem gravação em disco, e expira 5 minutos após a última requisição. Depois disso, o cliente precisa reenviar a conversa inteira. Um ponto de custo: o Claude continua lendo o contexto completo a cada turno, então o uso de tokens não muda. Valem as tarifas padrão e os limites de taxa existentes. O recurso está em beta público na Claude Platform nativa, no Claude Platform on AWS, no Claude in Microsoft Foundry e no Claude Models on Google Cloud (gerenciado pela Anthropic). Para a maioria dos usuários do Claude Code, já vem ligado por padrão, e em requisições de 500 mil a 1 milhão de tokens a mediana do TTFT cai cerca de 35%.

A cobertura anterior mostra a janela de contexto crescendo. Em 19 de fevereiro de 2026, o CEVIU noticiou o "Anthropic lança Claude Sonnet 4.6 com contexto de 1M e habilidades de agente aprimoradas", com 1 milhão de tokens em beta. Em 9 de abril de 2026, veio o "Anthropic Lança Claude Managed Agents para Empresas com Infraestrutura de IA Gerenciada". Contextos grandes e agentes de longa duração tornam o reenvio do histórico um gargalo, e message threads age justamente nesse ponto. A redução de latência é de transporte do histórico, não de capacidade do modelo.

Para quem opera agentes de código ou de computer use em produção, a leitura é que o ganho é de latência, não de custo. Se a conta de tokens era o problema, nada muda. Se o problema era esperar o primeiro token em sessões longas, vale testar. Também é preciso desenhar o cliente para a expiração de 5 minutos, com fallback que reenvia a conversa completa.