A Anthropic deu aos programadores uma forma de deixarem de reenviar ao Claude a conversa completa a cada interação. Os message threads, disponíveis em beta pública desde 2 de novembro de 2026, permitem que uma aplicação mande o histórico uma única vez e, a partir daí, apenas as mensagens novas, acompanhadas do identificador da resposta anterior do Claude. O alvo são os ciclos longos de agentes, nos quais, segundo a empresa, carregar repetidamente centenas de milhares de tokens acrescenta uma espera visível antes de o modelo começar a responder.
O número de destaque vem da própria ferramenta de programação da Anthropic. A empresa afirma que a funcionalidade já está ativa por omissão para a maioria dos utilizadores do Claude Code e que, em pedidos entre 500 mil e 1 milhão de tokens, o tempo mediano até ao primeiro token desceu cerca de 35%. Não foram divulgados resultados para conversas mais curtas: a Anthropic limita-se a dizer que o ganho aumenta com o contexto acumulado e aponta como casos principais os agentes de código, os agentes de uso de computador, que de outro modo voltariam a carregar capturas de ecrã, e os fluxos com muitos documentos.
Para a usar, basta acrescentar o campo thread aos pedidos da API Messages e enviar o cabeçalho beta message-threads-2026-08-12. A primeira chamada leva a conversa completa, o prompt de sistema e as ferramentas, e é marcada como criação. As seguintes são pedidos de continuação que indicam previous_message_id e têm de omitir o prompt de sistema e as ferramentas, porque o thread os conserva desde o início. Outros parâmetros, como o modelo e a configuração de raciocínio, não podem mudar durante a vida do thread. Os SDK da Anthropic incluem um auxiliar que monta estes pedidos e trata das repetições, e o tool runner em beta passou a recorrer a threads por omissão.
O que muda é o volume que circula na rede, não aquilo que o modelo lê. O Claude continua a processar toda a conversa em cada turno, pelo que o consumo de tokens, as tarifas normais e os limites de utilização se mantêm, de acordo com a Anthropic. A documentação sublinha que um thread não funciona como cache de prompts: quem quiser evitar recalcular turnos anteriores tem de definir pontos cache_control, até um máximo de quatro por pedido. Entre turnos, cada thread fica em memória, cifrado e sem ser gravado em disco, garante a empresa.
A vida útil é propositadamente curta. Um thread expira cinco minutos após o último pedido e é apagado, no máximo, uma hora depois da última utilização. Quando já não pode ser continuado, a API devolve um erro 404 com o código thread_not_found e o cliente tem de reenviar tudo para abrir um novo, razão pela qual a documentação recomenda guardar uma cópia própria de cada mensagem. Não existe API para listar, ler ou apagar threads, não é possível compactá-los e as respostas dadas por um modelo de recurso do lado do servidor não ficam guardadas. A funcionalidade também não é elegível para acordos de retenção zero de dados nem para HIPAA.
A beta abrange todos os modelos Claude e está disponível na Claude API, na Claude Platform on AWS, no Claude in Microsoft Foundry e nos Claude Models on Google Cloud (geridos pela Anthropic), constando das notas de versão da plataforma de 2 de novembro. O The Next Web, que noticiou o lançamento nesse mesmo dia, destacou o compromisso que a própria Anthropic reconhece: poupa-se tempo de espera, não dinheiro.
Para quem constrói agentes sobre o Claude, a vantagem está numa latência mais baixa e mais estável à medida que as sessões crescem, sem reescrever prompts. Em troca, há mais estado para gerir: é preciso acompanhar os identificadores das respostas, prever expirações e repetições e manter fixos os parâmetros obrigatórios. A melhoria de 35% é uma medição interna feita num grupo de utilizadores do Claude Code e não um teste independente, e os ganhos reais vão depender do tamanho do contexto, da configuração da cache e da frequência com que os threads caducam entre turnos.