Em 2 de novembro, a Anthropic abriu na Claude Platform o beta público de message threads. O desenvolvedor adiciona um parâmetro thread à requisição da Messages API, envia a conversa completa no primeiro turno e, nos seguintes, apenas as mensagens novas e o ID da resposta anterior; o servidor se encarrega de remontar a conversa.
O número divulgado pela empresa vem do Claude Code. O recurso já está ativado por padrão para a maioria dos usuários do Claude Code, e em pedidos de 500k a 1M de tokens a mediana do tempo até o primeiro token caiu cerca de 35%. O blog não informa o efeito em outras faixas de tamanho.
O beta abrange a Claude API, o Claude Platform on AWS, o Microsoft Foundry e o Claude hospedado pela Anthropic no Google Cloud. Os modelos listados na documentação vão do Sonnet 4.5 e do Opus 4.5 até o Fable 5.1 e o Mythos 5.1.
A economia está na validação e na tokenização
Sem threads, o agente reenvia a conversa inteira a cada rodada, e a API precisa validá-la e tokenizá-la de novo. Quanto mais longa a sessão, mais demorada essa preparação. Os agentes de uso do computador são os mais prejudicados, porque as capturas de tela do histórico têm de ser reenviadas a cada turno.
Os threads guardam esse conteúdo na memória do servidor, de modo que o volume a processar se resume, na prática, ao turno recém-adicionado.
O Claude ainda precisa ler a conversa inteira em cada turno, então os tokens do lado do modelo não diminuem, e a cobrança e os limites de taxa seguem as regras atuais. Uma conta aproximada: numa sessão de 800 mil tokens com 2.000 tokens novos por turno, o que vai na requisição com threads é cerca de um quatrocentos avos do original, mas os tokens de entrada na fatura continuam acima de 800 mil. Para economizar de fato, ainda é preciso o cache de prompt, que é outra chave: a requisição de thread pode incluir cache_control no nível superior; sem ele, mesmo enviando só mensagens novas, nada é armazenado em cache.
Na integração, deixe uma rota de retorno
A documentação define o thread como "melhor esforço" (best effort), e isso condiciona a forma de integrar.
- Expiração: o thread expira 5 minutos após a última requisição, e cada resposta armazenada reinicia a contagem; no máximo, é excluído 1 hora depois do último uso.
- Invalidação: se uma requisição de continuação retornar 404, é preciso reenviar a conversa completa e abrir um novo thread. A resposta não informa se o turno atual foi armazenado com sucesso; só se descobre na próxima requisição de continuação.
- Cópia: a versão de referência da conversa continua no lado da aplicação. Os auxiliares dos SDKs oficiais mantêm uma cópia na memória e a reenviam automaticamente; ao encerrar o processo, ela se perde, e quem precisar de persistência entre processos terá de guardá-la por conta própria.
- Campos fixos:
systemetoolssó são enviados na criação; incluí-los numa continuação, mesmo como null, gera erro 400. Campos comomodel,thinking,tool_choiceemcp_serversdevem ser reenviados sem alterações a cada turno, e qualquer mudança retornathread_fingerprint_mismatch. Para trocar o prompt de sistema ou as ferramentas, só abrindo um novo thread.
Há também uma restrição de conformidade. O conteúdo dos threads fica criptografado na memória e não é gravado em armazenamento persistente, mas o recurso não atende aos requisitos de retenção zero de dados (ZDR). Empresas com contrato ZDR continuam usando normalmente os demais recursos, apenas o thread fica indisponível.
Vale ainda distinguir: o Claude Managed Agents também tem session threads, que são coisa diferente dos message threads agora lançados.
Uma peça que faltava
A Responses API da OpenAI tem há bastante tempo o previous_response_id, que também passa um ID para continuar o contexto anterior. A Anthropic exigia havia muito que o cliente enviasse o histórico completo a cada turno, o que traz a vantagem de ser sem estado e simples de implementar, ao custo de latência quando a sessão cresce. A abordagem atual é um meio-termo: o estado fica no servidor só por pouco tempo, se for perdido é reenviado, e a cópia do lado do cliente continua indispensável.
Pelos cenários de uso apontados pela Anthropic, o foco são agentes de programação de longa duração, agentes de uso do computador e fluxos de trabalho com muitos documentos e imagens. A empresa também ativou o recurso por padrão primeiro no seu próprio Claude Code, para só então abri-lo aos usuários da API.
Quanto ao ganho em conversas comuns com menos de algumas centenas de milhares de tokens, a Anthropic não divulgou números; a documentação diz apenas que os threads ajudam mais em laços longos de agentes. Equipes que constroem seus próprios agentes podem medir primeiro com a distribuição de tamanho das suas sessões e só então decidir se vale escrever uma camada extra de código para o caminho de reenvio após o 404.
Fontes: blog oficial do Claude, CocoLoop, documentação para desenvolvedores da Claude Platform; a redução de latência segue a mediana do Claude Code divulgada pela empresa, e a conta aproximada é uma estimativa da redação.