Compactação e pensamento preservado

Ignore esta página, a menos que você envie "thinking blocks" (blocos de pensamento) de volta a um modelo com "preserved thinking" (pensamento preservado) e mantenha turnos após o bloco de "compaction" (compactação). "Kept turns" (turnos mantidos) são os turnos que seguem o bloco: turnos recentes que você deixou de fora da solicitação de compactação, como em Compactação que mantém turnos recentes, ou turnos que chegaram enquanto o resumo estava sendo escrito, como em Compactação em segundo plano.

Modelos com pensamento preservado verificam blocos de pensamento anteriores em relação à conversa que os produziu. Um resumo substitui parte dessa conversa, mas a verificação aceita a substituição quando a API escreveu o resumo, de modo que o pensamento nos turnos mantidos pode permanecer válido.

Condições para que o pensamento mantido permaneça válido

Os blocos de pensamento nos turnos mantidos permanecem válidos enquanto todas estas condições forem atendidas:

• A solicitação de compactação é executada em um modelo com pensamento preservado. Esta condição abrange todas as solicitações de compactação desde que um bloco de pensamento foi produzido, não apenas a mais recente. Uma maneira de atendê-la é enviar todas as solicitações de compactação para o modelo que a conversa usa.
• Os turnos mantidos seguem diretamente as mensagens resumidas, e você os envia sem alterações. Envie cada mensagem mantida exatamente como está no seu histórico. Não pule nem adicione uma mensagem entre a última mensagem resumida e a primeira mantida. A primeira mensagem mantida também deve ter um papel (role) diferente da última mensagem resumida, e não pode ser uma mensagem role: "system" no meio da conversa. Caso contrário, a API a mescla na última mensagem resumida. Uma maneira de acertar a primeira mensagem mantida é compactar exatamente as messages de uma solicitação que você já enviou. Os turnos mantidos então começam com a resposta de Claude a ela.
• system e as tools não marcadas com defer_loading: true não mudam. Eles são os mesmos na solicitação de compactação e nas solicitações que produziram o pensamento mantido, e permanecem os mesmos nas solicitações seguintes. Alterar o prompt do sistema ou as ferramentas explica como alterá-los com segurança.

Se uma condição não for atendida, nada falha quando você compacta, e a API aceita o bloco em solicitações posteriores de qualquer forma. A falha ocorre na primeira solicitação posterior que envia o pensamento mantido onde a API aplica a verificação: um erro 400 por padrão, ou blocos de pensamento descartados se a solicitação definir thinking.block_binding.prefix_mismatch_behavior como "drop_block". Na Message Batches API, um item que deixa o campo sem definição não falha. Onde a verificação se aplica por padrão, a API descarta os blocos em vez disso. O que a API faz com um bloco inválido descreve ambos os resultados, e Quando a API aplica a verificação indica quais solicitações são verificadas.

Compactar novamente sem quebrar pensamentos mais antigos

Você pode compactar novamente e manter turnos: o novo bloco abrange o resumo antigo e todas as mensagens que o seguem na solicitação de compactação, e quaisquer turnos que você deixar de fora dessa solicitação são turnos mantidos do novo bloco.

A primeira das condições para o pensamento mantido conta todas as compactações desde que um bloco de pensamento foi produzido, então um turno que você mantém ao longo de duas compactações exige que ambas tenham sido executadas em um modelo com pensamento preservado.

Compactações anteriores à produção de um bloco de pensamento não contam contra ele. O pensamento produzido depois que um bloco está em vigor fica vinculado a esse bloco e permanece válido em compactações posteriores que atendam às condições.

Alterar o prompt do sistema ou as ferramentas

Uma solicitação posterior pode usar um system diferente, tools diferentes ou um modelo diferente da solicitação de compactação, e a API ainda aceita o bloco. Essa alteração pode invalidar o pensamento nos turnos mantidos, mas não tem nenhum outro efeito.

Para alterar system ou tools sem invalidar nenhum pensamento mantido, compacte primeiro a conversa inteira, para que nenhum turno seja mantido. Em seguida, altere-os na próxima solicitação.

Para adicionar uma instrução ou alterar as ferramentas disponíveis sem mexer em system ou tools, anexe a alteração a messages, conforme descrito em Fazer mudanças sem editar o prefixo.

Mensagens do sistema no meio da conversa dentro dos turnos resumidos também são resumidas, então suas instruções de texto deixam de se aplicar após a substituição. Para manter uma em vigor, declare-a novamente em uma mensagem role: "system" logo após o primeiro novo turno user que segue os turnos mantidos. As alterações de ferramentas dentro desses turnos são transferidas automaticamente quando a solicitação de compactação também inclui inline-tools-2026-09-15: o bloco retornado registra o efeito líquido delas em seu campo tool_changes, então envie o bloco de volta sem modificações. Se o bloco não tiver um campo tool_changes, declare novamente essas alterações de ferramentas da mesma forma. Uma mensagem do sistema colocada entre o bloco e os turnos mantidos quebra o pensamento deles.

Verificar se o pensamento mantido continuou válido

A resposta da compactação não informa se o pensamento mantido continua válido. A primeira solicitação após a substituição informa. Para verificar em seus testes:

1. Tenha uma conversa curta com o pensamento ativado. Use um modelo no qual a API executa a verificação (consulte Quando a API aplica a verificação) e use-o em todas as etapas, porque um modelo que não consegue ler um bloco de pensamento o descarta sem erro.
2. Compacte os turnos mais antigos e mantenha pelo menos um turno que contenha um bloco de pensamento.
3. Envie a próxima solicitação, com o bloco primeiro, depois o turno mantido, depois uma nova mensagem user, e com thinking.block_binding.prefix_mismatch_behavior definido como "error".
4. Leia o resultado. Uma resposta 200 cujo array input_transformations está vazio significa que nenhum bloco de pensamento falhou na verificação ou foi descartado. Um erro 400 que diz que o bloco está vinculado a uma conversa diferente significa que algum falhou. A mensagem começa com o caminho do primeiro bloco que falhou, e O que a API faz com um bloco inválido a mostra por completo.

O campo prefix_mismatch_behavior precisa do cabeçalho beta thinking-binding-controls-2026-08-01 além do cabeçalho beta compact-2026-09-04. Definir o campo também inclui a solicitação na verificação em contas onde a verificação não está ativada por padrão.

O programa a seguir executa as quatro etapas. Ele imprime quantos blocos de pensamento o turno mantido contém e quantas entradas input_transformations tem; nenhuma entrada significa que o pensamento mantido continuou válido:

from anthropic.types.beta import BetaMessageParam, BetaThinkingConfigParam

client = anthropic.Anthropic()

# Claude Fable 5.1 é o primeiro modelo que verifica o thinking reenviado em relação à conversa.
MODEL = "claude-fable-5-1"
BETAS = ["compact-2026-09-04", "thinking-binding-controls-2026-08-01"]
SYSTEM = "You help plan a recipe app's release. Keep answers short."
# Com "error", um bloco de thinking que falha na verificação faz a requisição falhar com um 400.
THINKING: BetaThinkingConfigParam = {
    "type": "adaptive",
    "block_binding": {"prefix_mismatch_behavior": "error"},
}

# 1. Tenha uma conversa curta com o thinking ativado.
history: list[BetaMessageParam] = [
    {"role": "user", "content": "What are the main entities in the app's data model?"}
]
first = client.beta.messages.create(
    model=MODEL,
    max_tokens=8192,
    system=SYSTEM,
    betas=BETAS,
    thinking=THINKING,
    messages=history,
)
history += [
    {"role": "assistant", "content": first.content},
    {
        "role": "user",
        "content": "Testing starts on Tuesday, March 3, 2026, takes 10 weekdays, and pauses on March 9 and March 16. On which date does it end?",
    },
]
second = client.beta.messages.create(
    model=MODEL,
    max_tokens=8192,
    system=SYSTEM,
    betas=BETAS,
    thinking=THINKING,
    messages=history,
)
history.append({"role": "assistant", "content": second.content})
thinking_blocks = sum(block.type == "thinking" for block in second.content)
print(f"Thinking blocks in the kept turn: {thinking_blocks}")

# 2. Resuma o primeiro turno. O segundo turno fica fora da requisição.
summary = client.beta.messages.create(
    model=MODEL,
    max_tokens=4096,
    system=SYSTEM,
    betas=BETAS,
    thinking=THINKING,
    messages=history[:2],
    compaction={"type": "summarize"},
)
if summary.stop_reason != "compaction":
    raise SystemExit(f"No summary: {summary.stop_reason}")

# 3. Coloque o bloco antes do turno mantido e faça a próxima pergunta.
history = [
    {"role": "assistant", "content": summary.content},
    *history[2:],
    {"role": "user", "content": "Which day should the release go out?"},
]
third = client.beta.messages.create(
    model=MODEL,
    max_tokens=8192,
    system=SYSTEM,
    betas=BETAS,
    thinking=THINKING,
    messages=history,
)

# 4. Um 200 sem blocos descartados significa que o thinking mantido foi aceito.
print(f"Dropped thinking blocks: {len(third.input_transformations)}")

Thinking blocks in the kept turn: 1
Dropped thinking blocks: 0

Em produção, "drop_block" mantém as solicitações bem-sucedidas quando uma condição não é atendida e relata cada bloco descartado em input_transformations com reason: "prefix_binding_mismatch". Uma entrada cujo path está em um turno mantido significa que o pensamento desse turno não continuou válido. O que a API faz com um bloco inválido descreve o que é descartado e explica como criar alertas para isso.

Compatibility