O caso: a Anthropic lançou em 2 de novembro de 2026, em beta, os message threads na API do Claude. A conversa fica guardada no servidor, e cada novo turno manda só as mensagens novas. Um time que roda um agente de código com 30 passos por sessão quer saber: a conta cai?
Resposta curta: não. A documentação diz que os threads não mudam o preço nem os limites de uso. O ganho é de velocidade: pedidos menores e primeira resposta mais rápida. O que corta a conta continua sendo o cache de prompt. No exemplo deste guia, uma sessão no Sonnet 5.5 custa US$ 5,22 sem cache e US$ 0,88 com cache, com ou sem thread.
O que a Anthropic lançou
As notas de versão da plataforma do Claude registram, em 2 de novembro de 2026, os message threads em beta. O recurso liga com o cabeçalho message-threads-2026-08-12. Funciona na API do Claude, no Claude Platform on AWS, no Claude Models on Google Cloud gerido pela Anthropic e no Microsoft Foundry.
O funcionamento, pela documentação:
- Criar. O primeiro pedido vai como hoje, com a conversa inteira, o prompt de sistema e as ferramentas, mais o campo
threaddo tipocreate. - Continuar. Os pedidos seguintes levam só as mensagens novas e o
idda resposta anterior. O sistema e as ferramentas ficam de fora. - Expirar. O thread expira 5 minutos depois do último pedido. A API apaga o conteúdo no máximo 1 hora depois do último uso.
- Repetir. Se o thread expirou, o pedido de continuação volta com erro 404. A aplicação manda a conversa inteira de novo, num novo
create.
Sem thread, cada turno sobe a conversa inteira, e a API valida e conta os tokens de tudo de novo. Com thread, esse trabalho fica quase só no turno novo. Por isso a primeira resposta chega mais rápido em conversas longas.
O preço não muda
A seção de preços da documentação tem uma frase: os threads não mudam o preço nem os limites de uso. A API remonta a conversa inteira antes de chamar o modelo, e o modelo lê tudo. Mandar menos bytes pela rede não é o mesmo que pagar menos tokens.
Os preços do exemplo vêm da tabela do site, atualizada em outubro de 2026:
| Preço por milhão de tokens | Sonnet 5.5 | Opus 5.5 |
|---|---|---|
| Entrada | US$ 2,00 | US$ 4,00 |
| Gravação no cache de 5 minutos | US$ 2,50 | US$ 5,00 |
| Gravação no cache de 1 hora | US$ 4,00 | US$ 8,00 |
| Leitura do cache | US$ 0,10 | US$ 0,20 |
| Saída | US$ 10,00 | US$ 20,00 |
A conta de uma sessão de agente
Premissas de exemplo: prompt de sistema e ferramentas com 20.000 tokens. Cada passo do agente acrescenta 4.000 tokens à conversa (o resultado da ferramenta e a resposta anterior) e gera 1.000 tokens de saída. A sessão tem 30 passos. No último, a conversa chega a 140.000 tokens.
Somando todos os passos, o modelo lê 2.460.000 tokens de entrada na sessão. É a conversa crescendo e sendo lida de novo a cada passo. O thread não muda esse total.
| Sessão de 30 passos | Sonnet 5.5 | Opus 5.5 |
|---|---|---|
| Sem cache (com ou sem thread) | US$ 5,22 | US$ 10,44 |
| Com cache de 5 minutos (com ou sem thread) | US$ 0,88 | US$ 1,76 |
| Economia do cache | 83% | 83% |
Na conta com cache, cada passo lê do cache a conversa até o passo anterior e grava só o trecho novo. É o que a documentação descreve para o cache_control no topo do pedido.
O thread não liga o cache
Este é o ponto que mais pesa no bolso. A documentação avisa que o thread não faz cache do prompt sozinho. O cache funciona como sem thread: você escolhe onde ficam os pontos de cache.
Para cachear cada turno, o pedido leva um cache_control no topo, igual em todos os pedidos do thread. Sem ele, cada turno manda só as mensagens novas, mas nada fica em cache. Quem liga o thread achando que ganhou o cache de graça paga US$ 5,22 por sessão no Sonnet 5.5, em vez de US$ 0,88.
Outras regras de cache no thread:
- Cada pedido aceita no máximo 4 pontos de cache. O
cache_controldo topo conta como um. Os pontos no sistema e nas ferramentas docreatecontam de novo em cada continuação. Um a mais devolve erro 400. - O cache só pega quando a conversa passa do tamanho mínimo do modelo, como em qualquer pedido.
Quando o thread expira
O thread vive 5 minutos depois do último pedido. O cache padrão também. Num agente que para e espera a aprovação de uma pessoa, uma pausa longa derruba os dois.
Aí a aplicação manda a conversa inteira de novo. Com o cache de 5 minutos já expirado, esse turno grava tudo no cache, ao preço de gravação. Exemplo: uma pausa longa no passo 20, com a conversa em 100.000 tokens.
| Passo 20 | Turno normal com cache | Turno depois da pausa | Diferença |
|---|---|---|---|
| Sonnet 5.5 | US$ 0,0196 | US$ 0,2500 | US$ 0,2304 |
| Opus 5.5 | US$ 0,0392 | US$ 0,5000 | US$ 0,4608 |
Com 3 pausas longas por sessão, todas perto do passo 20, a sessão no Sonnet 5.5 sobe de US$ 0,88 para cerca de US$ 1,57. É o mesmo custo que a pausa já tinha antes dos threads: quem perde o cache paga a gravação de novo.
O cache de 1 hora ajuda aqui. O thread expira em 5 minutos, mas o cache segue vivo, e a nova criação lê a conversa do cache. A gravação custa mais: no exemplo, a sessão sem pausas sai por US$ 1,09 no Sonnet 5.5 com o cache de 1 hora. Vale quando as pausas longas são frequentes. Simule o seu caso na calculadora de cache de prompt.
O que o thread não aceita
A lista da documentação tem itens que mexem na conta:
| Recurso | Com thread | Efeito na conta |
|---|---|---|
| API de Lotes | Não aceita | Quem precisa do desconto de 50% segue sem thread |
| Contagem de tokens | Não aceita | Conte a conversa inteira, com sistema e ferramentas |
| Compactação sob demanda | Não aceita | A conversa não encolhe dentro do thread |
| Edição de contexto | Só a limpeza de raciocínio com keep all | Resultados antigos de ferramentas ficam na conta |
| Retenção zero de dados (ZDR) | Não elegível | O conteúdo fica em memória por até 1 hora |
A compactação é o ponto delicado em sessões longas. Sem ela, a conversa só cresce. A documentação tem uma seção sobre como resumir turnos antigos: começar um thread novo com a conversa já resumida.
Há ainda o Haiku 5.5. O preço dele sobe em pedidos acima de 100 mil tokens, e a conta inclui as leituras de cache. No exemplo, a conversa passa desse limite por volta do passo 20. O thread não muda isso, porque o modelo lê a conversa inteira.
Para quem vale ligar
- Agentes longos e chats com histórico grande. O ganho é a primeira resposta mais rápida e estável. A conta fica igual.
- Quem ainda não usa cache. Vale mais ligar o cache do que o thread. No exemplo, o cache corta 83% da sessão no Sonnet 5.5.
- Volume grande. Com 40 sessões por dia útil e 22 dias, o mês sai por US$ 776,16 com cache no Sonnet 5.5 (cerca de R$ 3.888,25), contra US$ 4.593,60 sem cache.
Erros comuns
- Achar que o thread corta tokens. Corta bytes enviados, não tokens cobrados.
- Esquecer o
cache_controldo topo. Sem ele, nada fica em cache. - Mudar campos fixos no meio. Modelo, ferramentas, raciocínio e o
cache_controldo topo precisam ser iguais em todo o thread. Diferença dá erro 400. - Não guardar a conversa. A aplicação continua dona do histórico. Sem cópia própria, não há como refazer o thread depois do 404.
- Pôr thread em lote. A API de Lotes recusa pedidos com thread.
Perguntas frequentes
Os message threads deixam a API do Claude mais barata?
Não. A documentação diz que o preço e os limites não mudam. No exemplo, a sessão de 30 passos custa US$ 0,88 no Sonnet 5.5 com cache, com ou sem thread.
O thread faz cache automático?
Não. O cache depende do cache_control. Sem ele, a mesma sessão custa US$ 5,22 no Sonnet 5.5, US$ 4,34 a mais.
Quanto tempo o thread dura?
Cinco minutos depois do último pedido. A API apaga o conteúdo em até 1 hora. Depois disso, a aplicação manda a conversa inteira de novo. No passo 20 do exemplo, esse turno custa US$ 0,2500 no Sonnet 5.5, contra US$ 0,0196 de um turno normal com cache.
Dá para usar thread com a API de Lotes?
Não. O pedido em lote com thread termina com erro. Para o desconto de 50%, mande a conversa inteira, sem thread.
Quais modelos aceitam threads?
A documentação lista os modelos atuais, entre eles Fable 5.1, Opus 5.5, Sonnet 5.5 e Haiku 5.5, além de versões anteriores como Opus 4.8 e Sonnet 4.5.
Para ver quanto o cache corta na sua conversa, use a calculadora de cache de prompt.
