Pensamento

Um modelo que responde em uma única passagem precisa acertar tudo na primeira tentativa: sem rascunhos, sem verificação, sem mudar de rumo no meio do caminho. Para uma prova, um bug complicado ou uma longa tarefa agêntica, a primeira abordagem muitas vezes não é a melhor.

O "thinking" (pensamento) remove essa restrição. Quando o pensamento está ativo, Claude trabalha o problema com suas próprias palavras antes de responder: reformula o que está sendo pedido, experimenta abordagens, verifica resultados intermediários e abandona caminhos que não se sustentam. Esse raciocínio chega em blocos de conteúdo thinking antes da resposta, e Claude se apoia nele para produzir a resposta final. É por isso que o pensamento melhora o desempenho em tarefas complexas como matemática, programação, análise e trabalho agêntico de longa duração, em que a qualidade da resposta depende de um trabalho intermediário que, de outra forma, seria comprimido na própria resposta ou ignorado.

O pensamento tem um custo: os tokens que Claude gasta raciocinando são cobrados como tokens de saída, mesmo quando o texto do pensamento não é retornado a você, e contam para o max_tokens junto com o texto da resposta. Esta página aborda como o pensamento se comporta em toda a superfície da API: como ativá-lo, ler sua saída e gerenciar suas interações com ferramentas, streaming, cache e a janela de contexto.

Como o pensamento funciona

Se Claude pensa em uma determinada solicitação, e com que profundidade, depende da sua configuração de pensamento e da complexidade da solicitação.

Veja como o pensamento aparece em uma resposta: um ou mais blocos de conteúdo thinking chegam antes dos blocos text. O bloco de pensamento ainda é conteúdo gerado, como o bloco text que o segue, mas é separado da resposta canônica. Cada bloco de pensamento também carrega um campo signature, uma cópia criptografada do raciocínio completo que você devolve inalterada em conversas de múltiplos turnos e com uso de ferramentas (consulte Criptografia do pensamento):

{
  "content": [
    {
      "type": "thinking",
      "thinking": "Let me break this down. The question has two parts, so I'll start with the simpler one and use its result to constrain the second...",
      "signature": "WaUjzkypQ2mUEVM36O2Txu...."
    },
    {
      "type": "text",
      "text": "Based on my analysis..."
    }
  ]
}

Você nem sempre vê esse texto, e o que você vê nunca é a cadeia de pensamento bruta: o texto em um bloco de pensamento é um resumo do raciocínio do Claude. O campo display na configuração de pensamento controla se esse resumo é retornado: "summarized" o retorna, enquanto "omitted", o padrão em muitos modelos, retorna blocos de pensamento com um campo thinking vazio. De qualquer forma, o bloco é cobrado da mesma maneira e devolvido da mesma maneira em conversas de múltiplos turnos. Consulte Controlando a exibição do pensamento para os padrões por modelo e detalhes.

Se Claude usa ferramentas, o pensamento também pode aparecer entre chamadas de ferramentas. Consulte Pensamento com uso de ferramentas. Para o formato completo da resposta, consulte a referência da API Messages.

Configurando o pensamento

Na maioria dos modelos, o pensamento está ativado por padrão ou a um parâmetro de distância. Qual configuração cada modelo aceita, e qual é o seu padrão, está listado na tabela de configuração por modelo na página de Solução de problemas.

No Claude Opus 5, Claude Sonnet 5, Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5 e Claude Mythos Preview, o pensamento já está ativado e não precisa de configuração. display tem como padrão "omitted" nesses modelos, então o texto do pensamento fica oculto até que você opte por vê-lo. Opte com thinking: {"type": "adaptive", "display": "summarized"}, que é exatamente a solicitação a seguir com a string do modelo trocada.

No Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6 e Claude Sonnet 4.6, o pensamento fica desativado até que você defina thinking: {type: "adaptive"}, o que permite que Claude decida quando e com que profundidade pensar com base na solicitação. Os exemplos a seguir fazem isso, definem display: "summarized" para que o texto do pensamento fique visível e usam um max_tokens generoso:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
)

for block in response.content:
    if block.type == "thinking":
        print(f"\nThinking: {block.thinking}")
    elif block.type == "text":
        print(f"\nResponse: {block.text}")

Executar o exemplo imprime o pensamento resumido e, em seguida, a resposta:

Thinking: Use Euclidean algorithm.
1071 = 2*462 + 147
462 = 3*147 + 21
147 = 7*21 + 0
GCD = 21

Response: ## Finding GCD of 1071 and 462

I'll use the **Euclidean algorithm**, repeatedly dividing and taking remainders...

Os tokens de pensamento contam para o max_tokens, então defina-o alto o suficiente para deixar espaço tanto para o pensamento quanto para o texto da resposta. Consulte Controle de custos na página de direcionamento e Pensamento e a janela de contexto.

Desativando o pensamento

No Claude Sonnet 5, onde o pensamento está ativado por padrão, você pode desativá-lo:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    thinking={"type": "disabled"},
    messages=[{"role": "user", "content": "Summarize this article in one sentence."}],
)

O Claude Opus 5 também tem o pensamento ativado por padrão e aceita thinking: {type: "disabled"} com effort high ou inferior. Com effort xhigh ou max, o pensamento não pode ser desativado: solicitações que combinam thinking: {type: "disabled"} com esses níveis de effort retornam um erro 400. Essa restrição se aplica ao Claude Opus 5 e modelos posteriores e é aplicada em cada solicitação. Com o pensamento desativado, o Claude Opus 5 pode ocasionalmente emitir chamadas de ferramentas como texto simples ou incluir tags XML internas em sua saída visível. Consulte Executando com o pensamento desativado para mitigações via prompt.

Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5 e Claude Mythos Preview rejeitam thinking: {type: "disabled"}. O pensamento não pode ser desativado nesses modelos.

Se o seu modelo suporta apenas extended thinking (pensamento estendido) (consulte a tabela de configuração por modelo), configure-o com type: "enabled" e um valor de budget_tokens. A página Pensamento estendido aborda essa configuração. E se qualquer configuração de pensamento retornar um erro 400, Solução de problemas do pensamento associa cada mensagem de erro à sua correção.

Lendo a saída de pensamento

Controlando a exibição do pensamento

O campo display na configuração de pensamento controla como o conteúdo de pensamento é retornado nas respostas da API. display funciona em ambos os modos: defina-o junto com type: "adaptive" ou type: "enabled". Ele aceita estes valores:

• "summarized": os blocos de pensamento contêm texto de pensamento resumido, um resumo legível do raciocínio do Claude. Este é o padrão no Claude Opus 4.6, Claude Sonnet 4.6 e modelos anteriores.
• "omitted": os blocos de pensamento são retornados com um campo thinking vazio. O campo signature ainda carrega o pensamento completo criptografado para continuidade em múltiplos turnos (consulte Criptografia do pensamento). Este é o padrão no Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Opus 5, Claude Sonnet 5, Claude Opus 4.8, Claude Opus 4.7 e Claude Mythos Preview.
• "updates" (beta): os blocos de raciocínio são retornados com um campo thinking vazio, como em "omitted", e as breves atualizações de progresso que alguns modelos escrevem entre chamadas de ferramentas retornam como texto legível. Requer o cabeçalho beta thinking-display-updates-2026-08-18.

Defina display: "omitted" quando sua aplicação não exibe o conteúdo de pensamento aos usuários. O principal benefício é um tempo até o primeiro token de texto mais rápido ao usar streaming: o servidor pula completamente o streaming dos tokens de pensamento e entrega apenas a assinatura, de modo que a resposta de texto final começa a ser transmitida mais cedo.

Com display: "omitted", a resposta contém blocos thinking com um campo thinking vazio:

{
  "content": [
    {
      "type": "thinking",
      "thinking": "",
      "signature": "EosnCkYICxIMMb3LzNrMu..."
    },
    {
      "type": "text",
      "text": "The answer is 12,231."
    }
  ]
}

Tenha em mente o seguinte ao trabalhar com pensamento omitido:

• Você ainda é cobrado pelos tokens de pensamento completos. Omitir reduz a latência, não o custo.
• Se você devolver blocos de pensamento em conversas de múltiplos turnos, devolva-os inalterados. O servidor descriptografa a signature para reconstruir o pensamento original para a construção do prompt (consulte Preservando blocos de pensamento). Qualquer texto que você colocar no campo thinking de um bloco omitido devolvido é ignorado.
• display é inválido com thinking.type: "disabled" (não há nada para exibir).
• Ao usar thinking.type: "adaptive" e o modelo pular o pensamento para uma solicitação simples, nenhum bloco de pensamento é produzido, independentemente de display.
• Ao usar streaming com display: "omitted", nenhum evento thinking_delta é emitido. Com display: "updates", apenas os blocos de atualização de progresso transmitem eventos thinking_delta. Consulte Streaming do pensamento para a sequência de eventos.

No SDK Ruby, hashes simples recebem display: como mostram os exemplos. A classe tipada ThinkingConfigAdaptive nomeia o parâmetro como display_ (com sublinhado no final, para evitar sobrepor o Kernel#display do Ruby). De qualquer forma, o campo transmitido ainda é display.

Pensamento resumido

Quando display é "summarized", o texto de pensamento que você recebe é um resumo do processo de pensamento completo do Claude, em vez da cadeia de pensamento bruta. O pensamento resumido fornece todos os benefícios de inteligência do pensamento enquanto previne uso indevido. Nenhuma configuração de display retorna a cadeia de pensamento bruta.

Tenha em mente o seguinte ao trabalhar com pensamento resumido:

• Você é cobrado pelos tokens de pensamento completos gerados pela solicitação original, não pelos tokens do resumo. A contagem de tokens de saída cobrada não corresponde à contagem de tokens que você vê na resposta.
• No Claude Opus 4.6, Claude Sonnet 4.6 e modelos anteriores, as primeiras linhas da saída de pensamento são mais detalhadas, fornecendo um raciocínio minucioso que é particularmente útil para fins de engenharia de prompt. O Claude Mythos Preview resume desde o primeiro token, então seus blocos de pensamento não mostram esse preâmbulo detalhado.
• O resumo preserva as ideias principais do processo de pensamento do Claude com latência adicional mínima, de modo que os resumos podem ser transmitidos à medida que chegam.
• O resumo é processado por um modelo diferente daquele que você especifica em suas solicitações. O modelo de pensamento não vê a saída resumida.
• À medida que a Anthropic busca melhorar o recurso de pensamento, o comportamento de resumo está sujeito a alterações.

Para ver o raciocínio do modelo, leia os blocos thinking em vez de solicitar o raciocínio no texto da resposta. No Claude Fable 5.1 e Claude Fable 5, uma solicitação que tenta extrair o raciocínio interno do modelo como parte do texto da resposta pode ser recusada com stop_details.category: "reasoning_extraction". Consulte Categorias de recusa para a referência do campo e orientações de tratamento.

Streaming do pensamento

O pensamento funciona com streaming. Os blocos de pensamento são transmitidos como eventos thinking_delta dentro de eventos content_block_delta, seguidos por um único evento signature_delta logo antes do content_block_stop do bloco. Os blocos de texto são transmitidos depois, como de costume.

Os exemplos a seguir transmitem uma resposta com pensamento adaptativo, imprimindo os deltas de pensamento e de texto à medida que chegam:

client = anthropic.Anthropic()

with client.messages.stream(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
) as stream:
    for event in stream:
        if event.type == "content_block_start":
            print(f"\nStarting {event.content_block.type} block...")
        elif event.type == "content_block_delta":
            if event.delta.type == "thinking_delta":
                print(event.delta.thinking, end="", flush=True)
            elif event.delta.type == "text_delta":
                print(event.delta.text, end="", flush=True)

Para remontar blocos de pensamento completos com suas assinaturas após o streaming, use o auxiliar de acumulação de mensagens do seu SDK, onde existir (por exemplo, stream.get_final_message() em Python ou stream.finalMessage() em TypeScript), em vez de concatenar os deltas você mesmo.

event: message_start
data: {"type": "message_start", "message": {"id": "msg_01...", "type": "message", "role": "assistant", "content": [], "model": "claude-opus-4-8", "stop_reason": null, "stop_sequence": null}}

event: content_block_start
data: {"type": "content_block_start", "index": 0, "content_block": {"type": "thinking", "thinking": "", "signature": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "I need to find the GCD of 1071 and 462 using the Euclidean algorithm.\n\n1071 = 2 × 462 + 147"}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "\n462 = 3 × 147 + 21\n147 = 7 × 21 + 0\n\nSo GCD(1071, 462) = 21"}}

// Additional thinking deltas...

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "signature_delta", "signature": "EqQBCgIYAhIM1gbcDa9GJwZA2b..."}}

event: content_block_stop
data: {"type": "content_block_stop", "index": 0}

event: content_block_start
data: {"type": "content_block_start", "index": 1, "content_block": {"type": "text", "text": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 1, "delta": {"type": "text_delta", "text": "The greatest common divisor of 1071 and 462 is **21**."}}

// Additional text deltas...

event: content_block_stop
data: {"type": "content_block_stop", "index": 1}

event: message_delta
data: {"type": "message_delta", "delta": {"stop_reason": "end_turn", "stop_sequence": null}}

event: message_stop
data: {"type": "message_stop"}

Quando display: "omitted" está definido, o bloco de pensamento abre, um único signature_delta chega e o bloco fecha sem nenhum evento thinking_delta. O streaming de texto começa imediatamente depois:

event: content_block_start
data: {"type":"content_block_start","index":0,"content_block":{"type":"thinking","thinking":"","signature":""}}

event: content_block_delta
data: {"type":"content_block_delta","index":0,"delta":{"type":"signature_delta","signature":"EosnCkYICxIMMb3LzNrMu..."}}

event: content_block_stop
data: {"type":"content_block_stop","index":0}

event: content_block_start
data: {"type":"content_block_start","index":1,"content_block":{"type":"text","text":""}}

Com display: "updates" (beta), os blocos de raciocínio são transmitidos como em "omitted". Cada bloco de atualização de progresso transmite seu texto como eventos thinking_delta antes do bloco tool_use que ele introduz. Uma pausa de vários segundos antes de o bloco de atualização de progresso abrir é normal:

event: content_block_start
data: {"type":"content_block_start","index":1,"content_block":{"type":"thinking","thinking":"","signature":""}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"thinking_delta","thinking":"Confirmed the retry path never refreshes the expired token. Editing auth.py to add the refresh call."}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"signature_delta","signature":"Es8CCkYICxIM..."}}

event: content_block_stop
data: {"type":"content_block_stop","index":1}

event: content_block_start
data: {"type":"content_block_start","index":2,"content_block":{"type":"tool_use","id":"toolu_01D7FLrfh4GYq7yT1ULFeyMV","name":"edit_file","input":{}}}

Em "updates", trate um bloco como uma atualização de progresso assim que um de seus eventos thinking_delta carregar texto não vazio.

Para a mecânica geral de streaming, consulte Streaming de mensagens.

Pensamento e effort

O parâmetro thinking controla se o Claude pensa em blocos de pensamento antes de responder; o parâmetro effort controla quanto trabalho o Claude dedica à resposta inteira, o que, no modo adaptativo, inclui com que frequência e com que profundidade ele pensa. Não passe adaptive como um valor de effort: adaptive é um modo de pensamento, não um nível de esforço.

Para saber o que cada nível de effort faz com o comportamento do pensamento, consulte a tabela de comportamento do pensamento por nível na página Direcionando o pensamento. A página Effort documenta o parâmetro em si, incluindo quais níveis cada modelo suporta. No Claude Opus 4.5, o único modelo exclusivo de pensamento estendido que suporta effort, o effort se compõe com budget_tokens. Consulte Regras e ajuste de orçamento.

Com os dois controles separados dessa forma, escolha aquele que corresponde ao seu objetivo:

• Menor custo ou latência em uma carga de trabalho com pensamento ativado: reduza o effort primeiro. Ele reduz a escala de toda a resposta, incluindo o pensamento.
• Claude está pensando muito raramente ou de forma muito superficial: aumente o effort, ou consulte Direcionando com que frequência Claude pensa na página de direcionamento.
• Você precisa do pensamento totalmente desativado: use thinking: {type: "disabled"} nos modelos que permitem isso (consulte a tabela de configuração por modelo).
• Você precisa de um teto rígido de gastos: use max_tokens. O effort é uma orientação flexível. max_tokens é um limite estrito.

Pensamento com uso de ferramentas

O pensamento funciona junto com o uso de ferramentas, permitindo que Claude raciocine sobre a seleção de ferramentas e processe os resultados das ferramentas. Duas restrições se aplicam:

1. Limitação de escolha de ferramenta (modo manual): o uso de ferramentas com pensamento estendido manual (thinking: {type: "enabled"}) suporta apenas tool_choice: {"type": "auto"} (o padrão) ou tool_choice: {"type": "none"}. Usar tool_choice: {"type": "any"} ou tool_choice: {"type": "tool", "name": "..."} resulta em um erro porque essas opções forçam o uso de ferramentas, o que é incompatível com o pensamento estendido manual. O pensamento adaptativo, inclusive em modelos onde o pensamento está ativado por padrão, suporta o uso forçado de ferramentas, exceto no Claude Fable 5.1 e Claude Mythos 5.1 (consulte Preenchimento prévio de resposta e uso forçado de ferramentas).
2. Preservando blocos de pensamento: ao retornar resultados de ferramentas, você deve devolver os blocos de pensamento da mensagem do assistente à API, completos e sem modificações. Consulte Preservando blocos de pensamento.

Um loop de uso de ferramentas é um único turno do assistente. Da perspectiva do modelo, um turno do assistente não se completa até que Claude termine sua resposta completa, que pode incluir múltiplas chamadas de ferramentas e resultados. Toda esta sequência é um único turno do assistente:

User: "What's the weather in Paris?"
Assistant: [thinking] + [tool_use: get_weather]
User: [tool_result: "20°C, sunny"]
Assistant: [text: "The weather in Paris is 20°C and sunny"]

O turno inteiro é executado em um único modo de pensamento: você não pode alternar o pensamento no meio de um turno, inclusive durante o loop de uso de ferramentas. No modo estendido (manual), a API adicionalmente exige que o turno final do assistente de uma solicitação com pensamento ativado comece com um bloco de pensamento. O modo adaptativo relaxa isso: nenhum turno do assistente precisa começar com um.

Conflitos no meio do turno degradam graciosamente. Se você alternar o pensamento no meio do turno (por exemplo, entre enviar uma chamada de ferramenta e retornar seu resultado), a API não gera erro. Em vez disso, ela desativa silenciosamente o pensamento para aquela solicitação. Para preservar a qualidade do modelo, a API pode remover blocos de pensamento que criariam uma estrutura de turno inválida, ou desativar o pensamento quando o histórico da conversa for incompatível com o pensamento ativado. Para confirmar se o pensamento estava ativo, verifique a presença de blocos thinking na resposta.

Alterne entre turnos, não dentro deles. Planeje sua estratégia de pensamento no início de cada turno. Complete o turno do assistente e, em seguida, altere a configuração de pensamento para o próximo:

User: "What's the weather?"
Assistant: [tool_use] (thinking disabled)
User: [tool_result]
Assistant: [text: "It's sunny"]
User: "What about tomorrow?"
Assistant: [thinking] + [text: "..."] (thinking enabled - new turn)

Alternar modos de pensamento também invalida o cache de prompt. Consulte Pensamento e cache de prompt.

Preservando blocos de pensamento

Quando Claude invoca uma ferramenta, ele pausa a construção de sua resposta para aguardar informações externas. Quando você retorna o resultado da ferramenta, Claude continua construindo essa mesma resposta, então seu raciocínio anterior ainda deve estar presente. Devolva cada bloco thinking à API completo e sem modificações, junto com o bloco tool_use que ele acompanhou. Isso importa por dois motivos:

1. Continuidade do raciocínio: os blocos de pensamento capturam o raciocínio passo a passo que levou às solicitações de ferramentas. Incluí-los permite que Claude continue raciocinando de onde parou.
2. Manutenção do contexto: os resultados de ferramentas aparecem como mensagens do usuário na estrutura da API, mas fazem parte de um fluxo de raciocínio contínuo. Preservar os blocos de pensamento mantém esse fluxo entre chamadas de API.

Em resumo:

• Obrigatório: dentro de um turno de uso de ferramentas, devolva os blocos de pensamento.
• Recomendado: entre turnos, devolva tudo.
• Permitido: fora do uso de ferramentas, omita o pensamento de turnos anteriores.

Você não precisa podar o pensamento antigo por conta própria. Devolva todos os blocos de pensamento em conversas de múltiplos turnos, e a API os filtra automaticamente, mantém os blocos necessários para preservar o raciocínio do modelo e cobra tokens de entrada apenas pelos blocos efetivamente mostrados ao Claude. Quais blocos de turnos anteriores são mantidos depende do modelo. Consulte Preservação de blocos de pensamento por modelo. Para substituir o padrão, use a estratégia de edição de contexto clear_thinking_20251015.

Dentro da mensagem mais recente do assistente, a sequência de blocos thinking consecutivos deve corresponder ao que o modelo gerou na solicitação original: você não pode reorganizá-los, editá-los ou descartá-los parcialmente. Isso inclui os blocos redacted_thinking.

Para um passo a passo completo de dois turnos com código em todos os SDKs, consulte Pensamento em fluxos de trabalho com ferramentas e múltiplos turnos. Ele define uma ferramenta, recebe uma resposta de pensamento mais uso de ferramentas e devolve o turno do assistente com o resultado da ferramenta.

Pensamento intercalado

O "interleaved thinking" (pensamento intercalado) permite que Claude pense entre chamadas de ferramentas, raciocinando sobre cada resultado de ferramenta antes de agir sobre ele. Com o pensamento intercalado, Claude pode:

• Raciocinar sobre os resultados de uma chamada de ferramenta antes de decidir o que fazer em seguida
• Encadear múltiplas chamadas de ferramentas com etapas de raciocínio entre elas
• Tomar decisões mais refinadas com base em resultados intermediários

Com o pensamento adaptativo, o pensamento intercalado é automático em todos os modelos que suportam pensamento adaptativo. Nenhum cabeçalho beta é necessário. No Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Mythos Preview, Claude Opus 5, Claude Opus 4.8 e Claude Opus 4.7, o raciocínio entre chamadas de ferramentas sempre aparece em blocos de pensamento. O Claude Haiku 4.5 não suporta pensamento intercalado. Em modelos que usam pensamento estendido manual, a intercalação requer um cabeçalho beta e muda como o orçamento de pensamento é contado. Pensamento intercalado no modo manual aborda as regras por modelo e o comportamento de cabeçalho específico de cada plataforma.

Com o pensamento intercalado, a alocação de pensamento pode abranger todo o turno do assistente em vez de uma única resposta. O pensamento intercalado é suportado apenas para ferramentas usadas por meio da API Messages.

Para uma comparação prática mostrando o que o pensamento intercalado muda em um fluxo de trabalho com duas ferramentas, consulte Como o pensamento intercalado muda o fluxo.

Atualizações de progresso entre chamadas de ferramentas

No Claude Fable 5.1, Claude Mythos 5.1 e Claude Fable 5, o modelo pode escrever uma atualização de progresso entre chamadas de ferramentas. Uma atualização de progresso é uma ou duas frases sobre o que o modelo acabou de encontrar e o que está prestes a fazer em seguida, escrita para a pessoa que observa o agente, e não como raciocínio. Cada uma retorna como seu próprio bloco thinking com sua própria signature, separada de qualquer bloco de raciocínio no mesmo ponto. Ela fica imediatamente antes do bloco tool_use ou server_tool_use que introduz. No máximo uma atualização de progresso precede cada chamada de ferramenta, e o modelo pode pular qualquer uma delas. Atualizações de progresso não são pensamento intercalado: elas aparecem independentemente de blocos de raciocínio aparecerem ou não entre chamadas de ferramentas, e uma resposta pode conter ambos.

O que um bloco de atualização de progresso contém depende de display:

Use display: "updates" para uma interface de agente que mantém o raciocínio oculto e mostra ao usuário uma linha de status a cada etapa. Com ele, qualquer bloco thinking com texto não vazio é uma atualização de progresso, então renderize esses e nada mais. Está em beta e requer o cabeçalho beta thinking-display-updates-2026-08-18 (no Amazon Bedrock, Google Cloud e Microsoft Foundry, passe o valor beta conforme descrito em Cabeçalhos beta). Sem ele, o valor é rejeitado com o mesmo 400 invalid_request_error de um valor de display desconhecido.

{
  "model": "claude-fable-5-1",
  "max_tokens": 16000,
  "thinking": { "type": "adaptive", "display": "updates" },
  "tools": [
    {
      "name": "edit_file",
      "description": "Replace the contents of a file in the repository.",
      "input_schema": {
        "type": "object",
        "properties": {
          "path": { "type": "string" },
          "content": { "type": "string" }
        },
        "required": ["path", "content"]
      }
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "The login test fails after an hour of uptime. Find out why and fix it."
    }
  ]
}

Em "updates", o início da resposta que segue um tool_result tem esta aparência. O primeiro bloco é raciocínio e permanece vazio, como ficaria em "omitted". O segundo carrega texto, então é uma atualização de progresso. Em "summarized" ambos os blocos carregam texto, e em "omitted" ambos ficam vazios.

{
  "content": [
    {
      "type": "thinking",
      "thinking": "",
      "signature": "EqMBCkYICxIM..."
    },
    {
      "type": "thinking",
      "thinking": "Confirmed the retry path never refreshes the expired token. Editing auth.py to add the refresh call.",
      "signature": "Es8CCkYICxIM..."
    },
    {
      "type": "tool_use",
      "id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
      "name": "edit_file",
      "input": { "path": "auth.py", "content": "..." }
    }
  ]
}

Tenha em mente o seguinte ao trabalhar com atualizações de progresso:

• Devolva os blocos de atualização de progresso inalterados com o restante do turno do assistente, como qualquer outro bloco thinking.
• O texto que você recebe é um resumo da atualização de progresso, normalmente uma ou duas frases. Não dependa do seu comprimento. A atualização de progresso conta para usage.output_tokens em seu comprimento total, não no do resumo.
• Um bloco de atualização de progresso pode retornar com um campo thinking vazio sob qualquer valor de display. Não renderize nada para um bloco vazio. Em "updates" ele tem a mesma aparência de um bloco de raciocínio vazio e não precisa de tratamento separado.
• Quando uma resposta para em max_tokens, model_context_window_exceeded ou stop_sequence logo após uma chamada de ferramenta ou resultado de ferramenta, seu último bloco pode ser um bloco de atualização de progresso representando o trabalho que o modelo não havia terminado. Em "updates" e "summarized" seu texto é exatamente This part of the response was interrupted before it finished. e você pode exibi-lo como qualquer outra atualização. Em "omitted" ele fica vazio. Para continuar, devolva o turno do assistente inalterado e acrescente uma nova mensagem user (com um tool_result para cada bloco tool_use naquele turno).
• Ao usar streaming, espere uma pausa de vários segundos antes de um bloco de atualização de progresso abrir. Consulte o rastreamento de "updates" em Streaming do pensamento.
• Esses modelos escrevem menos atualizações de progresso com effort mais alto e em longas cadeias de ferramentas. Se sua interface depende delas, consulte Peça atualizações de progresso voltadas ao usuário.

Preservação de blocos de pensamento por modelo

Se os blocos de pensamento de turnos anteriores do assistente permanecem no contexto por padrão depende do modelo:

• Mantêm todos os turnos anteriores: Claude Opus 4.5 e modelos Opus posteriores, Claude Sonnet 4.6 e modelos Sonnet posteriores, Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5 e Claude Mythos Preview.
• Mantêm apenas o último turno: modelos Opus e Sonnet anteriores, e todos os modelos Haiku até o Claude Haiku 4.5. Quando você devolve blocos de pensamento mais antigos, a API os remove automaticamente. Você não precisa removê-los por conta própria.

A preservação traz dois benefícios:

• Otimização de cache: blocos de pensamento preservados permitem acertos de cache durante o uso de ferramentas, pois são devolvidos com os resultados das ferramentas e armazenados em cache incrementalmente ao longo do turno do assistente, resultando em economia de tokens em fluxos de trabalho de múltiplas etapas.
• Sem impacto na inteligência: preservar blocos de pensamento não tem efeito negativo no desempenho do modelo.

A contrapartida é o uso de contexto: conversas longas consomem mais espaço de contexto em modelos que mantêm tudo, porque os blocos de pensamento retidos contam como entrada, como qualquer outro histórico de conversa (consulte Pensamento e a janela de contexto). O comportamento é automático em ambos os regimes. Nenhuma alteração de código ou cabeçalho beta é necessário, e você deve continuar devolvendo blocos de pensamento completos e sem modificações, conforme descrito em Preservando blocos de pensamento. Para substituir o padrão em qualquer direção, use a limpeza de blocos de pensamento.

Trocando de modelo no meio da conversa. Continue devolvendo os blocos de pensamento inalterados quando trocar de modelo, por exemplo após um fallback de recusa por classificador. Um bloco de pensamento é legível apenas pelo modelo que o produziu ou por um mais novo, e a API ignora ou descarta os blocos que o modelo de destino não consegue ler. No Claude Fable 5.1 e Claude Mythos 5.1 a direção importa: eles leem os blocos de pensamento de todos os modelos anteriores e nenhum modelo anterior lê os deles, então trocar para eles mantém o raciocínio da conversa e trocar para um modelo anterior o descarta (consulte Pensamento preservado para a lista exata e para saber como os blocos descartados são cobrados e reportados). Remova blocos thinking e redacted_thinking anteriores por conta própria apenas para economizar tokens de entrada em modelos que os ignoram em vez de descartá-los, e nunca ao resgatar um crédito de fallback, que exige o corpo inalterado.

Pensamento preservado

Claude preserva um bloco de pensamento, mantendo-o utilizável em turnos posteriores, apenas sob as condições em que ele foi criado. A partir do Claude Fable 5.1 e Claude Mythos 5.1, um bloco thinking ou redacted_thinking é preservado apenas:

• Para o modelo que o produziu, ou um mais novo. Um modelo anterior não consegue usar o bloco, e a API o descarta daquela solicitação. Consulte Apenas para o modelo que o produziu, ou um mais novo.
• Na conversa que o produziu (apenas Claude Fable 5.1). Se o prompt system, as tools ou qualquer mensagem anterior mudar, o bloco deixa de ser válido, e a API rejeita a solicitação ou descarta o bloco. Consulte Apenas na conversa que o produziu.

A signature do bloco registra ambas as condições em ambos os modelos. A API a verifica sempre que o bloco retorna em uma solicitação posterior, incluindo uma solicitação para um modelo diferente; o Claude Mythos 5.1 verifica apenas a condição de modelo.

Devolva os blocos inalterados. Envie cada turno do assistente exatamente como você o recebeu, blocos de pensamento incluídos, e deixe a API decidir quais blocos o modelo pode usar.

Apenas para o modelo que o produziu, ou um mais novo

Esta condição é unidirecional: Claude Fable 5.1 e Claude Mythos 5.1 leem os blocos de pensamento de modelos anteriores, e nenhum modelo anterior lê os deles.

• Uma conversa que passa para o Claude Fable 5.1 ou Claude Mythos 5.1 mantém seu raciocínio. Os blocos de pensamento do modelo anterior permanecem legíveis, então o modelo pensa normalmente desde o primeiro turno após a troca.
• Uma conversa que passa deles para qualquer modelo anterior o perde. O modelo anterior não consegue ler os blocos deles, a API os descarta para aquela solicitação, e o modelo anterior raciocina novamente a partir das mensagens visíveis. Se a conversa retornar posteriormente ao Claude Fable 5.1 com o mesmo histórico, seus próprios blocos voltam a ser legíveis.

Na íntegra, Claude Fable 5.1 e Claude Mythos 5.1 leem blocos de pensamento produzidos um pelo outro, pelo Claude Opus 5, Claude Fable 5 e Claude Mythos 5, e pelo Claude Opus 4.8 e modelos Opus anteriores, modelos Claude Sonnet e Claude Haiku 4.5. Nenhum modelo além desses dois consegue ler um bloco produzido pelo Claude Fable 5.1 ou Claude Mythos 5.1.

Um bloco que o modelo receptor não consegue ler é descartado. A API o remove antes que o prompt chegue ao modelo. Ele não conta para input_tokens e não é cobrado. Quando você faz fallback do Claude Fable 5.1 para um modelo mais antigo no meio da conversa, por exemplo após um fallback de recusa por classificador, o modelo mais antigo raciocina novamente a partir da conversa visível. Com o cabeçalho beta de controles, o descarte é reportado em input_transformations como model_binding_mismatch. Sem ele, o descarte é silencioso. Um fallback do lado do servidor descarta blocos ilegíveis da mesma forma.

Somente na conversa que o produziu

Um bloco de pensamento do Claude Fable 5.1 é preservado apenas enquanto o prefixo da conversa a partir do qual ele foi produzido permanece inalterado. Sua signature cobre o prompt system, as tools e as mensagens que precederam o bloco. O Claude Mythos 5.1 registra a mesma signature, mas não executa essa verificação.

Essa verificação é aplicada para novas contas criadas em ou após 31 de agosto de 2026. Para contas criadas anteriormente, a API registra a condição na assinatura, mas não age sobre uma incompatibilidade, a menos que a requisição defina thinking.block_binding.prefix_mismatch_behavior, o que opta pela aplicação. A Anthropic planeja aplicar essa condição para todas as organizações em modelos futuros. Se sua conta foi criada anteriormente, torne sua aplicação compatível agora: os mesmos padrões somente de acréscimo (append-only) mantêm o cache de prompt aquecido, e você pode testar contra a verificação enviando prefix_mismatch_behavior: "error". Se você distribui uma ferramenta ou framework que as pessoas executam com sua própria chave de API, teste dessa forma: seus usuários em contas novas estão sujeitos à aplicação antes de você. Pensamento preservado tem a lista de verificação de integração: como saber se seu código edita o histórico e o recurso da API que substitui cada tipo de edição.

Onde a verificação é aplicada, uma requisição que reenvia um bloco contra um prefixo alterado é rejeitada com um 400 invalid_request_error:

messages.5.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block". That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

A última frase aparece apenas quando a requisição não enviou o cabeçalho beta. A mensagem pode terminar com mais uma frase nomeando a primeira mensagem que mudou. Tentar novamente com o mesmo corpo de requisição falha da mesma forma. Para continuar sem o raciocínio invalidado, envie o cabeçalho beta thinking-binding-controls-2026-08-01 e defina prefix_mismatch_behavior como "drop_block". A API então descarta o bloco com falha e todos os blocos de pensamento após ele na conversa, e relata cada um em input_transformations como prefix_binding_mismatch. O endpoint de contagem de tokens executa a mesma verificação e retorna o mesmo 400.

O que invalida blocos de pensamento posteriores:

• Editar, reordenar ou remover uma mensagem anterior, incluindo remover um lembrete por turno que você injetou em um turno de usuário anterior.
• Alterar o conteúdo do prompt system de nível superior, ou adicionar, remover ou editar uma ferramenta no array tools, entre requisições.
• Compactação ou truncamento no lado do cliente que mantém turnos recentes do assistente literalmente, incluindo o pensamento, enquanto reescreve os turnos anteriores a eles.
• Uma URL de imagem ou documento em um turno anterior que serve bytes diferentes em uma requisição posterior. A verificação cobre os bytes, não a string da URL, portanto uma URL assinada rotativa para o mesmo arquivo não causa problema. Para conteúdo que você referencia entre turnos, faça o upload uma vez com a Files API e envie o file_id, ou envie base64.

O que não invalida:

• Remover uma sequência inicial de blocos de pensamento, do mais antigo primeiro: o primeiro bloco de pensamento na conversa (ou o primeiro após o bloco de compactação mais recente), depois o próximo, e assim por diante. Remover um bloco de pensamento de qualquer outro lugar invalida todos os blocos de pensamento após ele, naquele turno e em todos os turnos posteriores.
• Alterar output_config.effort, max_tokens ou outras configurações de amostragem entre requisições.
• Marcadores cache_control, onde quer que você os coloque ou mova.
• Compactação e edição de contexto no lado do servidor: elas não contam como edições, porque a verificação compara a conversa como você a enviou, não a cópia editada do servidor. Após uma compactação, o prefixo verificado começa a partir do bloco de compactação.

Padrões que mantêm os blocos de pensamento válidos:

• Somente acréscimo. Adicione novas mensagens ao final de messages e deixe os turnos anteriores inalterados byte a byte.
• Use mensagens de sistema no meio da conversa e alterações de ferramentas no meio da conversa para adicionar instruções ou alterar a disponibilidade de ferramentas no meio do caminho, em vez de editar o campo system de nível superior ou o array tools. Para um lembrete que deve se aplicar a apenas um turno, envie-o como uma mensagem de sistema com escopo de turno e deixe-o no histórico em vez de excluí-lo depois. Isso também preserva o cache de prompt.
• Use gerenciamento de contexto no lado do servidor em vez de aparar o histórico você mesmo.
• Se uma requisição for rejeitada por incompatibilidade de prefixo e você não puder reparar o histórico, reenvie-a com o cabeçalho beta e prefix_mismatch_behavior: "drop_block", ou remova todos os blocos thinking e redacted_thinking do histórico e tente novamente uma vez.

Quando o pensamento anterior é descartado, o modelo responde àquele turno sem esses blocos. Um cliente que invalida repetidamente seu próprio histórico reinicia o cache de prompt a cada vez, o que aumenta o custo.

Compactação no lado do cliente. Essa verificação não exclui a compactação no cliente. A regra é mais restrita: não mantenha um bloco de pensamento atrás de um prefixo que você reescreveu. A compactação no lado do servidor é a maneira mais simples de satisfazê-la. Se você compactar no cliente, use uma destas formas:

• Compactação simples (recomendada): resuma a conversa em uma mensagem e inicie a próxima requisição com esse resumo mais o novo turno do usuário, sem reenviar turnos anteriores nem blocos de pensamento anteriores. Nenhum pensamento anterior permanece, então nada falha, e o modelo pensa do zero sobre a conversa compactada. Os modelos Claude são treinados em tarefas de longo horizonte com esse esquema, e ele tem desempenho comparável a esquemas mais elaborados para a maioria das cargas de trabalho. Ele reinicia o cache de prompt, como qualquer compactação faz.
• Compactação mantendo a cauda: resuma os turnos mais antigos e mantenha os turnos mais recentes literalmente. Os blocos de pensamento dos turnos mantidos foram produzidos contra o histórico completo e falham atrás do resumo. Remova thinking e redacted_thinking de cada turno que você carregar adiante (o texto e as chamadas de ferramentas deles podem permanecer), ou defina prefix_mismatch_behavior: "drop_block" e deixe a API descartá-los.
• Compactação em segundo plano: construa o resumo fora do caminho crítico e substitua-o enquanto a conversa continua. Cada turno produzido nesse meio-tempo tem pensamento anterior à substituição. Envie "drop_block" em cada requisição que ainda carregue blocos de pensamento produzidos antes da substituição (ou remova esses blocos você mesmo; input_transformations na primeira resposta após a substituição lista exatamente quais), ou compacte de forma síncrona.

Recortar turnos individuais do meio da transcrição invalida todos os blocos de pensamento após eles, e nenhuma forma no lado do cliente evita isso. Use uma mensagem de sistema no meio da conversa para a mudança de instrução que você estava fazendo, ou edição de contexto no lado do servidor para remoção seletiva.

Controles para blocos que não são preservados (beta)

Envie o cabeçalho beta thinking-binding-controls-2026-08-01 para obter duas coisas: um array input_transformations em cada resposta que lista quaisquer blocos de pensamento que a API descartou, e um objeto block_binding na configuração de pensamento com um campo.

block_binding é aceito junto com thinking.type: "adaptive" e thinking.type: "enabled". Enviá-lo sem o cabeçalho beta retorna um erro 400. Modelos que não executam a verificação de conversa aceitam o objeto e relatam apenas descartes da verificação de modelo, portanto um único corpo de requisição funciona em todos os modelos. No Amazon Bedrock e no Google Cloud, passe os nomes beta conforme descrito em Cabeçalhos beta.

A requisição a seguir opta por descartar em vez de rejeitar. Em um primeiro turno não há nada para reenviar, então input_transformations retorna vazio:

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={
        "type": "adaptive",
        "block_binding": {"prefix_mismatch_behavior": "drop_block"},
    },
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
    betas=["thinking-binding-controls-2026-08-01"],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

print(f"Input transformations: {len(response.input_transformations or [])}")

The greatest common divisor of 1071 and 462 is 21.
Input transformations: 0

Blocos descartados são relatados em input_transformations. Sob o cabeçalho beta, cada resposta de um modelo com capacidade de pensamento carrega esse array de nível superior. Ele está vazio quando nada foi descartado e nunca é null. Cada entrada nomeia a posição de um bloco descartado e a verificação em que ele falhou:

{
  "input_transformations": [
    {
      "type": "thinking_dropped",
      "path": "messages.1.content.0",
      "reason": "model_binding_mismatch"
    }
  ]
}

O campo reason é model_binding_mismatch ou prefix_binding_mismatch. Ignore entradas cujo type ou reason você não reconheça, porque verificações posteriores adicionam valores. Ao usar streaming, input_transformations chega no objeto message no evento message_start. Após um fallback no lado do servidor no meio do stream, o evento message_delta final carrega o array novamente com as entradas do modelo que está atendendo. Sem o cabeçalho beta, o campo está ausente.

Uma assinatura adulterada ou impossível de descriptografar é uma falha diferente: ela sempre retorna um 400 (Invalid `signature` in `thinking` block, sem cláusula de motivo) e prefix_mismatch_behavior não se aplica a ela. Em um lote de mensagens, um item cujo bloco falha na verificação de conversa sob "error" é resolvido como errored.

Pensamento e cache de prompt

O cache de prompt interage com o pensamento de algumas maneiras específicas. As regras a seguir se aplicam em ambos os modos de pensamento.

Mudanças de configuração invalidam o cache. A configuração de pensamento e o nível de effort resolvido são renderizados no próprio prompt, portanto alterar qualquer um deles inicia um novo prefixo de cache. Alternar entre adaptive, enabled e disabled, alterar budget_tokens e alterar o valor de effort invalidam os pontos de interrupção do cache: pontos de interrupção no nível de mensagem sempre falham, e pontos de interrupção de ferramentas e do prompt do sistema também podem falhar, dependendo de onde o modelo renderiza a configuração. Trate qualquer mudança de pensamento ou de effort de nível superior como um reinício do cache. Em modelos que suportam effort por mensagem, uma mudança de effort carregada em uma mensagem role: "system" dentro de messages deixa o prefixo em cache intacto. Requisições consecutivas que mantêm a mesma configuração preservam o cache, e definir um parâmetro explicitamente com seu valor padrão é equivalente a omiti-lo. Um bloco de pensamento que a API descarta sob qualquer uma das condições de pensamento preservado altera o prefixo em cache a partir da posição daquele bloco em diante. Blocos passados de volta inalterados mantêm o cache intacto. Uma demonstração prática com saída de uso está na página Direcionando o pensamento.

Blocos de pensamento são armazenados em cache com resultados de ferramentas. Durante um loop de uso de ferramentas, o cache ocorre quando você faz uma requisição de acompanhamento que inclui resultados de ferramentas. Nesse ponto, o histórico anterior da conversa, incluindo seus blocos de pensamento, pode ser armazenado em cache, e esses blocos de pensamento em cache contam como tokens de entrada em suas métricas de uso quando lidos do cache. Isso ocorre automaticamente, mesmo sem marcadores cache_control explícitos, e se comporta da mesma forma para pensamento regular e intercalado. A contrapartida: blocos de pensamento que você nunca mais vê nas respostas ainda contribuem para o uso de tokens de entrada quando lidos do cache.

Se os blocos anteriores estão no contexto depende do modelo. O padrão de preservação governa isso. Em modelos que mantêm tudo, os blocos de pensamento dos turnos anteriores permanecem em cache e no contexto. Em modelos que mantêm apenas o último turno, uma vez que você envia uma mensagem de usuário que não é um resultado de ferramenta, todos os blocos de pensamento anteriores são removidos do contexto. Nesses modelos, uma conversa como esta:

User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [thinking_block_2] + [text block 2],
User: [Text response, cache=True]

é processada como se os blocos de pensamento nunca tivessem existido:

User: ["What's the weather in Paris?"],
Assistant: [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [text block 2],
User: [Text response, cache=True]

Em modelos que mantêm tudo, a mesma requisição mantém thinking_block_1 e thinking_block_2 no contexto e no cache.

A degradação remove o pensamento do histórico armazenável em cache. Se o pensamento for desativado no meio do turno e você passar conteúdo de pensamento no turno atual de uso de ferramentas, o conteúdo de pensamento é removido e o pensamento permanece desativado para aquela requisição (consulte degradação graciosa). O pensamento intercalado amplifica os efeitos de invalidação do cache, porque blocos de pensamento podem ocorrer entre múltiplas chamadas de ferramentas.

Pensamento e a janela de contexto

max_tokens, que inclui todo o pensamento que Claude gera no turno atual, é aplicado como um limite estrito. Nos modelos Claude 4.5 e mais recentes, se os tokens de entrada mais max_tokens excederem o tamanho da "context window" (janela de contexto), a API aceita a requisição. Se a geração então atingir o limite da janela de contexto, ela para com stop_reason: "model_context_window_exceeded" em vez de retornar um erro. Em modelos anteriores, a API retorna um erro de validação. Consulte Tratando motivos de parada.

Como o pensamento conta contra a janela depende de quando ele foi gerado:

• Pensamento do turno atual sempre conta para max_tokens, é cobrado como tokens de saída e ocupa espaço na janela de contexto para o turno que o gerou.
• Pensamento de turnos anteriores depende do padrão de preservação. Em modelos que mantêm todos os turnos anteriores, os blocos de pensamento anteriores permanecem no contexto, contam para a janela e são cobrados como tokens de entrada como o restante do histórico da conversa. Em modelos que mantêm apenas o último turno, a API remove automaticamente os blocos de pensamento mais antigos quando você os passa de volta, portanto eles não consomem espaço na janela nem tokens de entrada.

Na prática:

• Em modelos que mantêm tudo, planeje sua janela de contexto como se o pensamento fosse histórico de conversa comum, porque ele é. Sessões agênticas longas acumulam pensamento no contexto. Use a limpeza de blocos de pensamento se precisar recuperar espaço.
• Em modelos que mantêm apenas o último turno, o pensamento é apenas um custo por turno: o pensamento de cada turno conta contra o max_tokens daquele turno e depois sai da janela.

Os diagramas a seguir ilustram o regime de apenas último turno (remoção). O primeiro mostra uma conversa de múltiplos turnos: o bloco de pensamento de cada turno é gerado na saída, mas não é carregado para a entrada dos turnos posteriores.

O segundo mostra o mesmo regime com "tool use" (uso de ferramentas): o pensamento permanece no contexto junto com seu resultado de ferramenta durante o turno do assistente, e depois sai no próximo turno do usuário.

Use a API de contagem de tokens para obter contagens precisas para seu caso de uso específico, especialmente para conversas de múltiplos turnos que incluem pensamento.

Criptografia do pensamento

O conteúdo completo do pensamento é criptografado e retornado no campo signature em cada bloco de pensamento. A API usa a assinatura para verificar que os blocos de pensamento foram gerados pelo Claude quando você os passa de volta.

Tenha o seguinte em mente ao trabalhar com assinaturas:

• Só é estritamente necessário enviar de volta os blocos de pensamento ao usar ferramentas com pensamento. Caso contrário, você pode omitir os blocos de pensamento dos turnos anteriores. Se você os passar de volta, se a API os mantém ou remove depende do modelo (consulte Preservação de blocos de pensamento por modelo). Use a edição de contexto para configurar isso.
• Ao enviar de volta blocos de pensamento, passe tudo de volta exatamente como você recebeu, por consistência e para evitar possíveis problemas.
• Ao usar streaming de respostas, a assinatura chega como um signature_delta dentro de um evento content_block_delta logo antes do evento content_block_stop.
• Os valores de signature são significativamente mais longos no Claude 4 e modelos posteriores do que nos modelos anteriores.
• O campo signature é opaco: não o interprete nem o analise.
• Os valores de signature são compatíveis entre plataformas (a Claude API, o Amazon Bedrock e o Google Cloud). Valores gerados em uma plataforma funcionam em outra.

Blocos de pensamento redigidos

Além dos blocos thinking regulares, a API pode retornar blocos redacted_thinking quando partes do raciocínio do Claude são redigidas por segurança. Um bloco redacted_thinking contém conteúdo de pensamento criptografado em um campo data, sem texto legível:

{
  "type": "redacted_thinking",
  "data": "..."
}

O campo data é opaco e criptografado. Assim como o campo signature nos blocos de pensamento regulares, passe os blocos redacted_thinking de volta para a API inalterados ao continuar uma conversa de múltiplos turnos com ferramentas.

Limites e compatibilidade de recursos

Parâmetros de amostragem

No Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Mythos Preview, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7 e Claude Sonnet 5, valores não padrão de temperature, top_p ou top_k retornam um erro 400 em cada requisição, independentemente de o pensamento ser usado. Em modelos mais antigos, a restrição se aplica apenas enquanto o pensamento está ativado: temperature e top_k são incompatíveis com o pensamento, e top_p é permitido em valores entre 0,95 e 1.

Preenchimento prévio de resposta e uso forçado de ferramentas

Você não pode preencher previamente a resposta do assistente enquanto o pensamento está ativado. O uso forçado de ferramentas (tool_choice: {"type": "any"} ou {"type": "tool", ...}) é incompatível com o pensamento estendido manual, mas funciona com o pensamento adaptativo. As exceções são o Claude Fable 5.1 e o Claude Mythos 5.1, que rejeitam o uso forçado de ferramentas em cada requisição com um erro 400. Nesses modelos, use tool_choice: {"type": "auto"} com uso estrito de ferramentas ou saídas estruturadas. Consulte Pensamento com uso de ferramentas.

Limites de saída

Cada modelo aceita max_tokens até o teto listado aqui. Na Message Batches API, o cabeçalho beta output-300k-2026-03-24 eleva esse teto para os modelos com um teto de lotes listado.

Consulte a visão geral dos modelos para os limites em modelos legados.

Requisições longas

Os SDKs exigem streaming quando max_tokens é maior que 21.333, para evitar timeouts HTTP em requisições de longa duração. Esta é uma validação no lado do cliente, não uma restrição da API. Se você não precisa processar eventos incrementalmente, use .stream() com .get_final_message() (Python) ou .finalMessage() (TypeScript) para obter o objeto Message completo sem tratar eventos individuais. Consulte Streaming de mensagens. Espere tempos de resposta mais longos quando o pensamento está ativo, porque gerar blocos de pensamento adiciona tempo de processamento. Para cargas de trabalho que levam o pensamento acima de aproximadamente 32k tokens por requisição, use o processamento em lote para evitar problemas de rede: tais requisições podem durar o suficiente para atingir timeouts do sistema e limites de conexões abertas.

Próximos passos