Como acompanhar o que o Claude Fable 5.1 faz entre as tool calls com os progress updates em beta

Fala aí, beleza? Sabe aquele momento em que tu manda o agente rodar uma tarefa grande e ele simplesmente some?

Um minuto de tela parada, dois minutos, e nada. Nenhuma linha dizendo o que ele tá fazendo, se travou, se tá no quinto arquivo ou se desistiu da vida

Esse silêncio tem explicação: o comportamento padrão do Claude Fable 5.1 é escrever MENOS atualizações visíveis ao usuário durante turnos longos de tool calling do que o Fable 5 escrevia. E existe uma opção em beta que devolve justamente essas atualizações de progresso em texto, pra tu mostrar na tua interface

Bora entender e ativar? 🙂

Por que o Claude Fable 5.1 parece mudo entre as tool calls

O sintoma é chato e é sempre o mesmo: o agente fica minutos em silêncio, ou entrega uma mensagem final que cobre só a última etapa do que ele fez

Tu sabe que ele trabalhou. Tu só não faz ideia de COMO

A parte técnica é o campo thinking.display. Nos modelos mais novos o valor padrão dele é "omitted", e isso significa que os thinking blocks até voltam na resposta, porém com o campo thinking vazio

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

"Então o raciocínio se perdeu?" Não. O campo signature segue carregando o thinking cifrado, que é o que garante a continuidade multi-turno. O conteúdo existe, ele só não vem legível pra ti

E tem um detalhe importante do Fable 5.1 aqui: ele escreve notas curtas entre as chamadas de ferramenta, e cada nota volta como um thinking block próprio, antes da chamada correspondente

Ou seja, o material que tu quer exibir já é produzido. Com o display no padrão, ele chega vazio na tua mão

O que você precisa antes de ativar os progress updates

Lista curta, sem enrolação:

• Acesso ao modelo pelo identificador certo: claude-fable-5-1 na Claude API, no Google Cloud, no Microsoft Foundry e na Claude Platform na AWS, e anthropic.claude-fable-5-1 no Bedrock
• Plano ou plataforma com o modelo liberado: ele está disponível para usuários Pro, Max, Team e Enterprise, e para desenvolvedores na Claude Platform, na AWS, no Google Cloud e no Microsoft Foundry (o identificador que tu vai usar depende do ponto de acesso, como está no item acima)
• O header beta thinking-display-updates-2026-08-18, porque a opção display: "updates" é nova e está em beta
• Um app que já consuma thinking blocks, já que é por eles que as atualizações chegam. Se a tua camada de streaming descarta bloco de thinking hoje, esse é o primeiro lugar a mexer

E o contexto de orçamento, que vale ter na cabeça antes de sair rodando teste em cima de teste: o Fable 5.1 custa US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída. A leitura de cache ficou em US$ 0,25 por milhão de tokens, 75% menos que no Fable 5

Passo a passo para receber as atualizações de progresso em texto

1. Defina thinking.display como "updates" na requisição

{
  "model": "claude-fable-5-1",
  "thinking": {
    "display": "updates"
  }
}

O resto da tua configuração de thinking continua sendo a que o teu app já usa. O que muda aqui é só o display

O erro comum deste passo: deixar o campo no padrão sem perceber. Se ninguém setou nada, o valor é "omitted", e tu vai seguir recebendo thinking block com texto vazio achando que o recurso não funciona

2. Envie o header beta na chamada

anthropic-beta: thinking-display-updates-2026-08-18

O erro comum deste passo: setar o display e esquecer o header. A opção está em beta, e beta na Claude API pede o header correspondente. Fixa isso no cliente, não em uma chamada solta

3. Leia o stream e trate todo thinking block com texto NÃO vazio como status line exibível

A regra é bem direta, dá pra escrever em uma linha no teu handler:

// dentro do seu loop de blocos da resposta
if (block.type === "thinking" && block.thinking.trim() !== "") {
  renderStatusLine(block.thinking)
}

Cada nota entre tool calls chega como um progress-update thinking block próprio, antes da chamada. Então tu tem uma sequência natural de status: nota, tool call, nota, tool call, por aí vai

O erro comum deste passo: renderizar thinking block vazio como se fosse update. O usuário vê uma bolha em branco piscando na tela e acha que tua aplicação quebrou

4. Audite o prompt e remova o que manda o modelo segurar as descobertas pro final

Esse passo é o mais esquecido de todos. A documentação de prompting orienta exatamente isso: varrer o system prompt e tirar qualquer linha que instrua o modelo a guardar as conclusões para a resposta final

O erro comum deste passo: manter aquela instrução antiga de "não comente durante a execução, apresente tudo no fim". Tu liga o updates, o modelo obedece o teu prompt, e a narração continua sumida. Não é bug, é ordem tua

5. Se a tua interface depende de narração, peça a narração de forma explícita

A recomendação da documentação, quando o produto realmente precisa disso, é pedir no prompt: uma linha de abertura, atualizações periódicas durante a execução e um recap de fechamento

O erro comum deste passo: assumir que ativar o display já garante o ritmo que o teu produto quer. O display abre o canal. O prompt define a cadência

omitted, summarized ou updates: qual valor de thinking.display usar

Repara na diferença fina entre os dois últimos: os dois entregam os updates, só que o "summarized" vem com o raciocínio resumido no meio, e o "updates" mantém o raciocínio escondido

Se o teu objetivo é UI, o segundo é o que tende a dar menos trabalho de filtrar

Ativei o display updates e continuo sem ver nada: o que checar

Quatro cenários, na ordem em que eu checaria:

Sintoma: o thinking block volta, mas com o texto vazio

Causa mais provável: o display ainda está em "omitted". Pode ser que o campo não subiu na requisição, ou que o header beta não foi junto e a tua chamada caiu no comportamento padrão. Confere os dois na mesma requisição, não em lugares diferentes do código

Sintoma: os updates aparecem, só que embolados com raciocínio

Causa: o display está em "summarized", que devolve as atualizações junto do raciocínio resumido. Se tu quer só a status line, o valor é "updates"

Sintoma: tudo configurado certo e o modelo segue calado

Causa: o prompt. Alguma linha ali manda ele segurar as descobertas pra resposta final. Tira essa instrução e, se a interface depende de narração, pede abertura, updates periódicos e recap final de forma explícita

Sintoma: no Claude Code o thinking não aparece do jeito esperado

Aqui vale saber que existe uma issue aberta no repositório do Claude Code, a #52376, de 23/04/2026, pedindo que o thinking.display seja honrado em sessões autenticadas por assinatura. Segundo a própria issue, hoje apenas sessões com API key recebem conteúdo de thinking

Ou seja, o comportamento que tu vê num agente de terminal não é necessariamente o mesmo da tua integração via API, e essa diferença entre harness e agente de terminal explica bem por que a mesma configuração se comporta de jeitos diferentes dependendo de onde ela roda

Como prevenir os quatro: fixa o header beta no cliente (não em uma chamada avulsa) e revisa o prompt toda vez que a narração sumir do nada. Na prática, é quase sempre um dos dois 😀

Onde os progress updates fazem diferença de verdade

Status line em produto com execuções agênticas longas. É o caso mais óbvio. Em vez de um spinner genérico girando por minutos, cada nota entre tool calls vira uma linha de estado real na tela

Log de acompanhamento pra debugar pipeline de tools. Quando o agente encadeia várias chamadas, ter a nota que antecede cada uma delas ajuda a entender em qual etapa a coisa saiu do trilho. É a mesma lógica de ver a memória do agente: o valor está em ver o processo acontecendo, não só o resultado

Transparência com o usuário final durante espera de minutos. Espera longa sem sinal de vida é onde o usuário fecha a aba. Update em texto, mesmo curtinho, muda a percepção da espera

Recap pra quem chegou no meio da execução. Se tu pedir no prompt a linha de abertura, os updates periódicos e o recap de fechamento, quem abriu a tela no minuto três consegue se situar sem ler tudo de novo

Conclusão

O ponto principal é esse: o silêncio do Fable 5.1 entre as tool calls é CONFIGURAÇÃO, não limitação do modelo

As notas já são escritas entre as chamadas, e cada uma volta como um thinking block próprio. Com o display no padrão "omitted", elas chegam vazias na tua mão, com o signature guardando o thinking cifrado pra continuidade

O próximo passo prático é bem curto: roda uma chamada de teste com thinking.display em "updates" e o header thinking-display-updates-2026-08-18, audita o system prompt atrás de qualquer instrução que mande guardar tudo pro final, e decide como cada status line vai ser renderizada na tua interface

Depois disso é só ajustar a cadência no prompt, com abertura, updates periódicos e recap

Até o próximo post! 🙂