Claude Platform Docs
Modelos e preçosClaude Fable 5.1

Guia de migração para o Claude Fable 5.1 e o Claude Mythos 5.1

Migre para o Claude Fable 5.1 e o Claude Mythos 5.1 a partir do Claude Fable 5, do Claude Mythos 5, do Claude Opus 5 ou do Claude Opus 4.8 com este guia de migração. As orientações para habilitar o Claude Fable 5.1 e o Claude Mythos 5.1 incluem IDs de modelo, mudanças incompatíveis e checklists de migração.

O Claude Fable 5.1 sucede o Claude Fable 5 com os mesmos preços de entrada e saída, com leituras de cache a um quarto do custo. Ele está disponível na Claude API, no Amazon Bedrock, na Claude Platform on AWS, no Google Cloud e no Microsoft Foundry. O Claude Mythos 5.1 compartilha as mesmas capacidades e está disponível apenas para organizações verificadas por meio dos programas de verificação da Anthropic, como o Cyber Verification Program. Para diferenças de comportamento e padrões de prompting, consulte Prompting do Claude Fable 5.1.

As configurações de base compartilhadas por claude-fable-5-1 e claude-mythos-5-1:

  • Pensamento: O "adaptive thinking" (pensamento adaptativo) está sempre ativado, sem alterações em relação ao Claude Fable 5. O modelo determina quando e quanto pensar. Nenhuma configuração de thinking é necessária. Tanto thinking: {type: "disabled"} quanto o "extended thinking" (pensamento estendido) manual (thinking: {type: "enabled", budget_tokens: N}) retornam um erro 400.
  • Prefill: Preencher previamente a mensagem do assistente retorna um erro 400, sem alterações em relação ao Claude Fable 5. Use instruções no "system prompt" (prompt do sistema) em vez disso.
  • Escolha de ferramenta: {type: "auto"} (o padrão) e {type: "none"} são suportados. Forçar uma chamada de ferramenta com {type: "any"} ou {type: "tool", name: "..."} retorna um erro 400. Consulte Mudanças incompatíveis.
  • Pensamento preservado entre modelos: O Claude Fable 5.1 lê blocos de pensamento do Claude Opus 5, Claude Fable 5, Claude Mythos 5 e modelos Claude anteriores. Nenhum desses modelos consegue ler os blocos do Claude Fable 5.1. Consulte Mudanças incompatíveis.
  • Janela de contexto e saída: Uma "context window" (janela de contexto) de 1M de tokens por padrão, e até 128k tokens de saída por requisição.
  • Preços: $10 USD por milhão de tokens de entrada e $50 USD por milhão de tokens de saída, o mesmo que o Claude Fable 5. Leituras de "prompt caching" (cache de prompt) custam $0,25 USD por milhão de tokens, um quarto da taxa do Claude Fable 5. Consulte Preços do Claude.
  • Retenção de dados: Ambos os modelos exigem retenção de dados de 30 dias, não estão disponíveis sob acordos de "zero data retention" (retenção zero de dados), ou ZDR, a menos que expressamente autorizado pela Anthropic, e são designados Covered Models, o mesmo que o Claude Fable 5 e o Claude Mythos 5. Na Claude API, uma requisição de uma organização ou workspace sem retenção de 30 dias retorna um 400 invalid_request_error. Organizações com um acordo de ZDR devem entrar em contato com sua equipe de conta da Anthropic ou configurar a retenção por workspace. Consulte Requisitos de retenção de dados específicos por modelo para detalhes por plataforma.

Onde os dois modelos divergem:

  • Disponibilidade: O Claude Fable 5.1 não exige aprovação de acesso. O Claude Mythos 5.1 está disponível apenas para organizações verificadas por meio dos programas de verificação da Anthropic, como o Cyber Verification Program. Para solicitar acesso, inscreva-se no programa que cobre seu caso de uso ou entre em contato com sua equipe de conta da Anthropic.
  • Priority Tier: Nenhum dos dois modelos é suportado no Priority Tier. O Claude Fable 5 é.

Migrando para o Claude Fable 5.1 a partir do Claude Fable 5

A migração é, em grande parte, direta. A superfície da API, os limites, o preço por token, o tokenizador, o pensamento adaptativo sempre ativado, o tratamento de recusas e as categorias de stop_details são todos iguais aos do Claude Fable 5. O que muda: a escolha forçada de ferramenta retorna um erro 400; apenas o Claude Fable 5.1 e o Claude Mythos 5.1 leem os blocos de pensamento do Claude Fable 5.1, e apenas na conversa que os produziu; leituras de cache custam menos; e o comportamento em loops de agente difere de três maneiras. As mesmas mudanças se aplicam ao Claude Mythos 5.1, exceto a verificação de conversa nos blocos de pensamento, que o Claude Mythos 5.1 não executa.

Atualize o nome do seu modelo

model = "claude-fable-5"  # Before
model = "claude-fable-5-1"  # After

# Ou, para o Claude Mythos 5.1, que oferece os mesmos recursos a organizações verificadas:
model = "claude-mythos-5-1"  # After

Mudanças incompatíveis

  1. A escolha forçada de ferramenta não é suportada: O Claude Fable 5 aceita tool_choice auto, none, any e tool. No claude-fable-5-1, {type: "any"} e {type: "tool", name: "..."} retornam um 400 invalid_request_error:

    tool_choice: type "tool" and "any" are not supported for this model.

    A verificação se aplica na Messages API, na Message Batches API e no endpoint de contagem de tokens.

    Antes (Claude Fable 5):

    client = anthropic.Anthropic()

record_summary_tool = {
    "name": "record_summary",
    "description": "Record the structured summary of the document.",
    "input_schema": {
        "type": "object",
        "properties": {"summary": {"type": "string"}},
        "required": ["summary"],
    },
}

response = client.messages.create(
    model="claude-fable-5",
    max_tokens=16000,
    tools=[record_summary_tool],
    tool_choice={"type": "tool", "name": "record_summary"},
    messages=[{"role": "user", "content": "Summarize: The meeting moved to Thursday."}],
)
print(response.content)

    Depois (Claude Fable 5.1): deixe tool_choice em auto, nomeie a ferramenta na instrução e defina strict: true para que a chamada corresponda ao seu schema. (Em uma organização CMEK, onde saídas estruturadas, incluindo strict: true, não estão disponíveis nos modelos Claude Fable, confie apenas na instrução.) Por exemplo:

    client = anthropic.Anthropic()

record_summary_tool = {
    "name": "record_summary",
    "description": "Record the structured summary of the document.",
    "strict": True,
    "input_schema": {
        "type": "object",
        "properties": {"summary": {"type": "string"}},
        "required": ["summary"],
        "additionalProperties": False,
    },
}

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    tools=[record_summary_tool],
    tool_choice={"type": "auto"},
    messages=[
        {
            "role": "user",
            "content": "Summarize: The meeting moved to Thursday. Call the record_summary tool with your result.",
        }
    ],
)
print(response.content)

    Consulte Uso estrito de ferramentas e Forçando o uso de ferramentas. Se você forçava uma ferramenta apenas para obter JSON em conformidade com o schema, use saídas JSON (output_config.format) em vez disso.

    Se a sua aplicação, e não o usuário, exige uma chamada de ferramenta específica no turno atual de uma conversa de múltiplos turnos, anexe uma mensagem de sistema no meio da conversa após o turno user mais recente. Nomeie a ferramenta, diga que a chamada é obrigatória para este turno e diga ao Claude para abrir sua resposta com ela. Como a mensagem é anexada em vez de escrita no prompt system de nível superior, os turnos anteriores permanecem idênticos byte a byte e mantêm seus acertos de cache de prompt:

    client = anthropic.Anthropic()

search_help_center_tool = {
    "name": "search_help_center",
    "description": "Search the help center for policy and troubleshooting articles.",
    "strict": True,
    "input_schema": {
        "type": "object",
        "properties": {"query": {"type": "string"}},
        "required": ["query"],
        "additionalProperties": False,
    },
}

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    system="You are a customer support assistant for an online electronics store.",
    tools=[search_help_center_tool],
    messages=[
        {
            "role": "user",
            "content": "My headphones from order A1234 arrived yesterday.",
        },
        {
            "role": "assistant",
            "content": "Thanks for confirming. How can I help with order A1234?",
        },
        {"role": "user", "content": "I opened the box. Can I still return them?"},
        # A aplicação exige uma consulta à central de ajuda antes de qualquer
        # resposta sobre políticas. Anexar o requisito como mensagem de sistema mantém
        # os turnos anteriores inalterados.
        {
            "role": "system",
            "content": "Tool-use requirement for the current turn: the application requires a call to the search_help_center tool in your response to the user's latest message. Begin your response with the search_help_center tool call. Do not reply with text only.",
        },
    ],
)
print(response.content)

    Mantenha a mensagem role: "system" no histórico em requisições posteriores, como qualquer outro turno. Mensagens de sistema no meio da conversa não precisam de cabeçalho beta. tool_choice: {"type": "none"} ainda funciona para um turno que não deve chamar ferramentas.

  2. Apenas o Claude Fable 5.1 e o Claude Mythos 5.1 leem os blocos de pensamento do Claude Fable 5.1: Cada bloco thinking registra qual modelo o produziu. O Claude Fable 5.1 lê seus próprios blocos e os do Claude Mythos 5.1, Claude Opus 5, Claude Fable 5, Claude Mythos 5 e modelos Claude anteriores. Uma conversa que passa para claude-fable-5-1 a partir de qualquer um deles mantém seu raciocínio anterior. A condição é unidirecional: com exceção do Claude Mythos 5.1, nenhum desses modelos consegue ler os blocos do Claude Fable 5.1.

    Uma conversa que rodou no Claude Fable 5.1 pode acabar em outro modelo, mais antigo ou mais novo, por meio de uma troca no roteador, de uma nova tentativa no lado do cliente ou de um fallback por recusa do classificador, incluindo um fallback no lado do servidor. A API remove os blocos que esse modelo não consegue ler antes que ele os veja, a requisição é bem-sucedida e você não é cobrado pelos tokens de entrada descartados. O modelo de destino replaneja sem esse raciocínio, o que pode aumentar o custo e a "latency" (latência) no primeiro turno após a troca. Para ver o que foi descartado, envie o cabeçalho beta thinking-binding-controls-2026-08-01: as respostas passam a trazer um array input_transformations nomeando cada bloco descartado com reason: "model_binding_mismatch". Consulte Trocar de modelo no meio da conversa.

  3. Editar turnos anteriores invalida blocos de pensamento: Cada bloco thinking do Claude Fable 5.1 é válido apenas em relação ao prompt system, às tools e ao histórico de conversa que o precederam. Se o Claude Code, o claude.ai, o Claude Managed Agents ou o Claude Agent SDK gerencia seu histórico de conversa, ele já mantém esse prefixo intacto. Se o seu código constrói o array messages por conta própria, este item se aplica a você, e Pensamento preservado é o guia de integração completo. Onde a verificação é aplicada, uma requisição que envia o bloco de volta depois que qualquer um desses mudou é rejeitada com um erro 400:

    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 API aplica a verificação para novas contas criadas a partir de 31 de agosto de 2026. Para contas criadas antes disso, a API registra a incompatibilidade, mas não age sobre ela, a menos que a requisição defina thinking.block_binding.prefix_mismatch_behavior, o que ativa a aplicação. Nessas contas, se você enviar o cabeçalho beta thinking-binding-controls-2026-08-01 e deixar esse campo sem definir, a resposta lista cada bloco que falhou na verificação em input_transformations como uma entrada thinking_mismatch_allowed. Torne sua aplicação compatível com a verificação independentemente da idade da sua conta: os mesmos padrões mantêm o cache de prompt aquecido, e você pode testar contra a verificação a partir de qualquer conta enviando prefix_mismatch_behavior. Se você distribui uma ferramenta ou framework que as pessoas executam com a própria chave de API, teste dessa forma antes do lançamento: sua chave provavelmente está em uma conta mais antiga, e seus usuários com contas novas encontram a verificação antes de você. Para saber se a sua própria conta tem a aplicação ativada por padrão, envie uma requisição que edita o histórico sem o cabeçalho beta: um 400 que menciona o cabeçalho significa que sim.

    O erro é permanente para aquele corpo de requisição: um loop de nova tentativa automática não o resolverá. Para continuar sem o raciocínio invalidado em vez de falhar, remova os blocos thinking do histórico e tente novamente uma vez, ou envie o cabeçalho beta thinking-binding-controls-2026-08-01 e defina prefix_mismatch_behavior como "drop_block" (o padrão é "error"). Com "drop_block", a API descarta o bloco incompatível e todos os blocos de pensamento após ele na conversa, e reporta cada um com reason: "prefix_binding_mismatch" no array input_transformations da resposta:

    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 [])}")

    O endpoint de contagem de tokens executa a mesma verificação. Consulte Controles para blocos que não são preservados (beta) para o formato da resposta e o posicionamento no streaming.

    Padrões que invalidam blocos de pensamento posteriores, e o que fazer em vez disso:

    • Editar, reordenar ou remover turnos anteriores. Isso inclui excluir resultados de ferramentas antigos, recortar turnos do meio da transcrição e a "compaction" (compactação) no lado do cliente que mantém os turnos recentes e seus blocos de pensamento literalmente atrás de um resumo (incluindo a compactação em segundo plano que insere seu resumo alguns turnos depois). Em vez disso, use a compactação ou a edição de contexto no lado do servidor (limpeza de resultados de ferramentas para resultados de ferramentas antigos), ou um dos formatos de compactação no lado do cliente em Reduza o contexto no servidor.
    • Injetar conteúdo que você não persiste, por exemplo um lembrete por turno anexado após os blocos tool_result e removido na requisição seguinte. Em vez disso, envie o lembrete como uma mensagem do sistema com escopo de turno e deixe-a no histórico.
    • Reconstruir o prompt system de nível superior ou o array tools entre requisições na mesma conversa, por exemplo para atualizar a data atual ou para adicionar ou remover uma ferramenta. Em vez disso, anexe uma mensagem do sistema no meio da conversa que carregue a nova instrução ("A data atual é 2026-09-14.") ou blocos tool_addition e tool_removal. Uma ferramenta que não foi declarada em tools no início pode ser definida dentro do bloco tool_addition (cabeçalho beta inline-tools-2026-09-15).
    • Uma URL de imagem ou documento que serve bytes diferentes em uma requisição posterior. A verificação abrange os bytes, não a string da URL, então uma URL assinada rotativa para o mesmo arquivo não causa problema. Para conteúdo que você referencia em vários turnos, faça o upload uma vez com a Files API e envie o file_id, ou envie em base64.

    Cada substituição também mantém os turnos anteriores idênticos byte a byte e preserva os acertos de cache de prompt que editar o histórico, o prompt system ou o array tools perderia.

    Padrões que continuam funcionando:

    • Históricos somente de anexação: adicionar turnos e passar os turnos anteriores de volta exatamente como enviados e recebidos, incluindo mensagens role: "system" anexadas.
    • Remover blocos de pensamento de turnos anteriores do assistente, os mais antigos primeiro.
    • Alterar effort, max_tokens ou qualquer outro parâmetro de requisição fora de system, tools e messages, e adicionar ou mover marcadores cache_control.
    • Compactação no lado do servidor e edição de contexto, incluindo limpeza de blocos de pensamento. Elas não contam como edições, porque a verificação compara a conversa como você a enviou.

    Para verificar uma integração existente:

    1. Capture os corpos exatos das requisições que ela envia ao longo de alguns turnos normais, incluindo uma compactação ou uma alteração de ferramenta, se o seu produto tiver isso. Para cada par de requisições consecutivas, compare o prompt system, o array tools e o prefixo compartilhado de messages. Eles devem ser idênticos byte a byte até os turnos recém-anexados. Uma exceção esperada é uma requisição que insere um bloco compaction assinado da compactação sob demanda: o bloco substitui as mensagens que resume no início de messages, e tudo o que vem depois dele ainda deve corresponder.
    2. Execute uma sessão normal de vários turnos com claude-fable-5-1 usando o cabeçalho beta thinking-binding-controls-2026-08-01 e prefix_mismatch_behavior: "drop_block", e registre input_transformations em cada resposta. Um array vazio em todos os turnos significa que o histórico está intacto. Uma entrada com reason: "prefix_binding_mismatch" significa que algo antes do bloco em path mudou desde a requisição anterior. Uma entrada com reason: "model_binding_mismatch" significa que a conversa trocou de modelo, o que não é um bug no seu código. Isso funciona a partir de qualquer conta, porque definir o campo ativa a aplicação para a requisição. Em CI, defina "error" em vez disso para que uma edição faça a execução falhar.
    3. Escolha uma configuração de produção. Mantenha o padrão "error" se uma incompatibilidade de prefixo só puder significar um bug no seu código, ou defina "drop_block" para descartar os blocos afetados em vez de falhar, e monitore os erros 400 ou as entradas de input_transformations em qualquer um dos casos.

    Descartar blocos de pensamento uma vez, em um limite de compactação por exemplo, tem pouco efeito. Uma integração que invalida o pensamento anterior em cada requisição reinicia o cache de prompt a cada vez, o que pode aumentar o custo por tarefa (consulte Mantenha o histórico de conversa somente de anexação).

Mudanças de comportamento

  1. Menos chamadas de ferramentas paralelas em loops de agente longos: Em loops de longa duração onde as próximas leituras independentes são apenas implícitas pela tarefa (agentes de codificação personalizados, harnesses de bash e editor, uso de computador), o Claude Fable 5.1 pode emitir uma chamada de ferramenta por turno. Cada turno extra custa tokens, uma ida e volta e tempo de relógio. Anexe uma instrução de agrupamento de uma frase após cada mensagem do usuário como uma mensagem de sistema com escopo de turno (clear_at: "next_user_message", beta), ou, sem o beta, em um bloco de texto após os blocos tool_result, e deixe as cópias anteriores no histórico em requisições posteriores. Consulte Agrupe chamadas de ferramentas independentes em loops de agente.

  2. Menos mensagens de progresso entre chamadas de ferramentas: O Claude Fable 5.1 escreve menos atualizações de status durante sequências longas de ferramentas do que o Claude Fable 5, e seus resumos de codificação agêntica são mais curtos. Se a sua interface renderiza essas atualizações, defina thinking.display como "updates" (beta) ou "summarized" e solicite-as explicitamente no prompt. Consulte Atualizações de progresso entre chamadas de ferramentas e Peça atualizações de progresso voltadas ao usuário.

  3. Menos chamadas de busca e recuperação em esforço baixo: Em esforço low, o Claude Fable 5.1 responde de memória com mais frequência do que o Claude Fable 5 em vez de chamar uma ferramenta de busca ou recuperação. Se o seu produto depende de recuperação em esforço baixo, aumente o esforço para essas requisições ou diga ao modelo quando buscar. Consulte Acionamento de busca em esforço baixo.

Para as diferenças em densidade de prosa, formatação de chat, citações em resumos e edições de arquivos, que não afetam a integração com a API, consulte Alterado em relação ao Claude Fable 5.

Essas mudanças não são obrigatórias, mas cada uma reduz custo ou latência ou remove um modo de falha:

  1. Altere o esforço no meio da conversa (beta): No Claude Fable 5, output_config.effort é de nível de requisição, e alterá-lo entre requisições descarta prefixos em cache de turnos anteriores. No claude-fable-5-1, uma mensagem role: "system" carregando apenas output_config aumenta o esforço para uma etapa difícil ou o reduz para etapas rotineiras sem invalidar o cache de prompt:

    client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=4096,
    output_config={"effort": "high"},
    messages=[
        {
            "role": "user",
            "content": "Plan a migration from SQLite to PostgreSQL in three short steps.",
        },
        {
            "role": "assistant",
            "content": "1. Export the SQLite data. 2. Create the PostgreSQL schema. 3. Import the data and verify row counts.",
        },
        # Mensagem do sistema só de esforço: o novo nível vale a partir do próximo turno do usuário.
        {"role": "system", "content": [], "output_config": {"effort": "low"}},
        {"role": "user", "content": "Summarize the plan in one sentence."},
    ],
    betas=["mid-conversation-output-config-2026-07-01"],
)

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

    Posicionada entre um turno assistant e o próximo turno user, como aqui, a mensagem entra em vigor a partir desse turno user. Posicionada diretamente após um turno user com nova entrada, ela define o nível para a resposta do Claude a esse turno. Um turno user que contém apenas resultados de ferramentas não conta como nova entrada: a mudança aguarda o próximo turno user com nova entrada. O nível então se mantém até que outra mensagem role: "system" o altere. Apenas os níveis nomeados são aceitos (low, medium, high, xhigh, max), e o cabeçalho beta mid-conversation-output-config-2026-07-01 é obrigatório. Consulte Esforço por mensagem.

  2. Altere instruções e ferramentas com mensagens do sistema no meio da conversa: Para alterar instruções ou ferramentas no decorrer de uma sessão, anexe uma mensagem role: "system", com blocos tool_addition e tool_removal para mudanças de ferramentas (cabeçalho beta inline-tools-2026-09-15 na Claude API). Um bloco tool_addition pode nomear uma ferramenta declarada em tools no início da sessão ou conter a definição completa da ferramenta, de modo que uma ferramenta desconhecida no início da sessão não precisa estar em tools. Isso preserva os acertos de cache de prompt nos turnos anteriores e mantém o histórico da conversa somente de anexação. O cabeçalho mais antigo mid-conversation-tool-changes-2026-07-01 ainda funciona para mudanças que nomeiam uma ferramenta por referência, na Claude API, no Amazon Bedrock e no Google Cloud. A mesma mensagem substitui o tool_choice forçado quando uma ferramenta específica precisa ser executada no turno atual (consulte Mudanças incompatíveis). Para um lembrete que se aplica a apenas um turno, envie-o como uma mensagem role: "system" separada, somente de texto, com clear_at: "next_user_message" (mensagens do sistema com escopo de turno, cabeçalho beta mid-conversation-system-clear-at-2026-08-21) e deixe-a no histórico: ela deixa de ser renderizada após a próxima mensagem do usuário e não custa tokens depois de limpa. Uma mensagem que contém blocos tool_addition ou tool_removal não pode ter escopo de turno.

  3. Use fallbacks: "default" para recusas: Continue tratando stop_reason: "refusal" e lendo stop_details.category antes do conteúdo da resposta. Para reexecutar automaticamente requisições recusadas em outro modelo, defina fallbacks: "default" (beta, cabeçalho server-side-fallback-2026-07-01). "default" tenta novamente uma requisição recusada no modelo que a Anthropic recomenda para aquela categoria. Os destinos de fallback permitidos para o Claude Fable 5.1 são o Claude Opus 4.8 (claude-opus-4-8) e o Claude Opus 5 (claude-opus-5). Uma lista fallbacks explícita pode nomear qualquer um deles. O modelo de fallback não recebe os blocos de pensamento do Claude Fable 5.1. O parâmetro fallbacks não está disponível no Amazon Bedrock, no Google Cloud nem no Microsoft Foundry. Nessas plataformas, use o fallback no lado do cliente em vez disso. Se você mesmo implementar a nova tentativa, o crédito de fallback se aplica nos mesmos termos do Claude Fable 5. Consulte Recusas e fallback.

  4. Comece no esforço high e faça uma varredura: O padrão do parâmetro effort é high, e todos os cinco níveis são suportados. Mantenha a orientação do Claude Fable 5: high para a maior parte do trabalho, e medium como um controle de custo que vale a pena testar. Os ganhos do Claude Fable 5.1 sobre o Claude Fable 5 são maiores em xhigh e max, mas esses níveis também adicionam tempo de pensamento e tempo até a primeira resposta, então suba para eles nas tarefas mais sensíveis à capacidade e onde suas avaliações mostrarem o ganho. Execute uma nova varredura nas suas próprias avaliações em vez de reaproveitar uma configuração ajustada para o Claude Fable 5. Consulte Níveis de esforço recomendados para o Claude Fable 5.1.

  5. Reduza o contexto no servidor, ou compacte em um formato que não carregue pensamento obsoleto: Se o seu código trunca ou resume turnos mais antigos no cliente, a correção mais simples é mover esse trabalho para a compactação ou a edição de contexto no lado do servidor. Nenhuma delas conta como edição, porque a verificação de histórico compara a conversa como você a enviou, então nada do que elas removem invalida blocos de pensamento posteriores, e o parâmetro instructions da compactação aceita o seu próprio prompt de resumo. Se você mantém turnos recentes literalmente atrás do resumo, ou resume em segundo plano enquanto a conversa continua, use a compactação sob demanda (cabeçalho beta compact-2026-09-04) em vez de um resumo escrito pelo cliente. A API escreve um bloco de resumo assinado que você coloca no lugar das mensagens que ele resume. Os blocos de pensamento nos turnos que você mantém podem continuar válidos, nas condições descritas em Compactação e pensamento preservado. Se você mantiver a compactação no cliente, escolha um destes três formatos:

    • Compactação simples (recomendada): substitua todo o histórico por uma mensagem de resumo mais o novo turno do usuário e não reproduza mais nada. Nenhum bloco de pensamento é carregado, então nada falha. 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.
    • Compactação com manutenção da cauda: se você mantém os turnos mais recentes literalmente atrás de um resumo, remova os blocos thinking e redacted_thinking desses turnos (texto e chamadas de ferramentas podem ficar), ou defina prefix_mismatch_behavior: "drop_block". O pensamento deles foi produzido em relação ao histórico completo e, caso contrário, falha atrás do resumo.
    • Compactação em segundo plano: se você constrói o resumo fora do caminho crítico e o insere depois, cada turno produzido nesse meio-tempo carrega pensamento anterior à troca. Envie "drop_block" em cada requisição que ainda carregue blocos de pensamento produzidos antes da troca (ou remova esses blocos você mesmo; input_transformations na primeira resposta após a troca lista exatamente quais), ou compacte de forma síncrona.

    Não recorte turnos individuais do meio da transcrição: isso invalida todos os blocos de pensamento posteriores, e nenhum formato no lado do cliente evita isso. Use uma mensagem de sistema no meio da conversa para a alteração de instrução que você estava fazendo, ou a edição de contexto no lado do servidor para remoção seletiva. Consulte Enviando os blocos de compactação de volta.

Checklist de migração

  • Atualize o nome do modelo de claude-fable-5 para claude-fable-5-1 (ou de claude-mythos-5 para claude-mythos-5-1).
  • Substitua o tool_choice forçado ({type: "any"} ou {type: "tool", ...}). Ele retorna um erro 400. Use {type: "auto"} mais uma instrução explícita e ferramentas com strict: true, ou saídas JSON. Coloque a instrução no turno user, ou em uma mensagem role: "system" no meio da conversa quando a sua aplicação exigir a chamada.
  • Continue repassando os blocos thinking sem alterações em todos os turnos, incluindo os vazios. O Claude Fable 5.1 lê blocos do Claude Opus 5, Claude Fable 5, Claude Mythos 5 e de modelos anteriores. Mover uma conversa do Claude Fable 5.1 para qualquer modelo que não seja o Claude Mythos 5.1 descarta seus blocos.
  • Se o seu código monta o array messages por conta própria, verifique se ele edita turnos anteriores: execute uma sessão com o cabeçalho beta thinking-binding-controls-2026-08-01 e prefix_mismatch_behavior: "drop_block", registre input_transformations e corrija cada prefix_binding_mismatch. Entradas model_binding_mismatch após uma troca de modelo são esperadas.
  • Mantenha o histórico da conversa somente de anexação: congele system e tools no início da sessão e mova as mudanças no meio da sessão para mensagens role: "system" e blocos tool_addition / tool_removal, envie lembretes por turno como mensagens do sistema com escopo de turno que você nunca remove, reduza o contexto no lado do servidor ou remova os blocos de pensamento de quaisquer turnos que você carregue através de um resumo no lado do cliente, e referencie arquivos usados em vários turnos por file_id.
  • Escolha um prefix_mismatch_behavior de produção ("error" por padrão, ou "drop_block") e monitore-o. Se você mantém uma ferramenta que outras pessoas executam com sua própria chave de API, teste com o campo definido: novas contas têm a aplicação ativada por padrão, mesmo que a sua não tenha.
  • Revise os loops de agente quanto ao comportamento de uma chamada de ferramenta por turno e adicione a instrução de agrupamento.
  • Se a sua interface exibe texto de progresso entre chamadas de ferramentas, defina thinking.display como "updates" (beta) ou "summarized" e solicite atualizações no prompt.
  • Se você altera o esforço entre requisições, mova a alteração para uma mensagem role: "system" de esforço por mensagem (beta) para manter os acertos de cache.
  • Trate stop_reason: "refusal" e leia stop_details.category. Considere fallbacks: "default" (beta).
  • Reavalie o effort com uma nova varredura, começando em high, e restabeleça a linha de base de custo e latência nas suas próprias cargas de trabalho. O tokenizador não mudou. Leituras do cache de prompt custam um quarto da tarifa do Claude Fable 5.

Migrando para o Claude Fable 5.1 a partir do Claude Opus 5

O Claude Fable 5.1 usa os mesmos padrões da Messages API e de uso de ferramentas que o Claude Opus 5. Ele mantém a janela de contexto de 1M de tokens por padrão, 128k de tokens máximos de saída, o mínimo de 512 tokens para cache de prompt e o suporte a mensagens do sistema no meio da conversa. A restrição de prefill, a restrição de parâmetros de amostragem e o padrão "omitted" para thinking.display também são mantidos. Aplique tudo o que está em Migrando para o Claude Fable 5.1 a partir do Claude Fable 5, mais o seguinte.

Atualize o nome do seu modelo

model = "claude-opus-5"  # Before
model = "claude-fable-5-1"  # After

# Ou, para o Claude Mythos 5.1, que oferece os mesmos recursos a organizações verificadas:
model = "claude-mythos-5-1"  # After

O que mudou

  1. O pensamento não pode mais ser desativado: O Claude Opus 5 aceita thinking: {type: "disabled"} em um nível de esforço high ou inferior. No claude-fable-5-1 e no claude-mythos-5-1, o pensamento adaptativo está sempre ativado, e thinking: {type: "disabled"} retorna um erro 400 em qualquer nível de esforço. Remova o campo, controle o gasto de tokens com níveis de esforço mais baixos e revise max_tokens para cargas de trabalho que eram executadas com o pensamento desativado.

  2. A escolha forçada de ferramenta não é suportada: O Claude Opus 5 aceita tool_choice any e tool. O claude-fable-5-1 retorna um erro 400. Consulte Mudanças incompatíveis.

  3. Pensamento preservado entre modelos: O Claude Fable 5.1 lê os blocos de pensamento do Claude Opus 5: conversas que passam de claude-opus-5 para claude-fable-5-1 mantêm seu raciocínio. O Claude Opus 5 não consegue ler os blocos do Claude Fable 5.1. Os blocos do Claude Fable 5.1 também deixam de ser válidos quando turnos anteriores mudam: se o seu código edita mensagens anteriores, reconstrói system ou tools, ou compacta no cliente entre requisições, o Claude Opus 5 não se opunha, mas o claude-fable-5-1 rejeita ou descarta todos os blocos de pensamento posteriores. Execute a verificação de três etapas daquela seção antes de redirecionar o tráfego. Consulte Mudanças incompatíveis.

  4. O texto entre chamadas de ferramentas é retornado em blocos de pensamento: No Claude Opus 5, o texto que o modelo escreve entre chamadas de ferramentas retorna como blocos text. No claude-fable-5-1, assim como no Claude Fable 5, essa narração retorna como blocos thinking de atualização de progresso, um antes de cada chamada de ferramenta. Sob o thinking.display padrão de "omitted", eles não carregam texto legível. Se a sua interface renderiza essa narração, defina display: "updates" (beta) para receber atualizações de progresso como texto enquanto o raciocínio permanece oculto, ou "summarized" para receber ambos. Em seguida, renderize os blocos thinking não vazios entre os blocos tool_use. Consulte Atualizações de progresso entre chamadas de ferramentas.

  5. Classificadores de segurança e roteamento de fallback: O Claude Fable 5.1 executa classificadores de segurança que cobrem as mesmas categorias de stop_details que o Claude Fable 5, um conjunto mais amplo do que os classificadores do Claude Opus 5. Espere valores adicionais de stop_details.category, como "bio"; consulte a tabela de categorias de recusa para o conjunto completo. Para a configuração de fallbacks e os destinos permitidos, consulte Use fallbacks: "default" para recusas.

  6. Preços: $10 USD por milhão de tokens de entrada e $50 USD por milhão de tokens de saída, em comparação com $5 USD e $25 USD para o Claude Opus 5. As leituras do cache de prompt custam $0,25 USD por milhão de tokens, metade da tarifa do Claude Opus 5. Consulte Preços do Claude.

  7. Retenção de dados: O Claude Fable 5.1 e o Claude Mythos 5.1 exigem retenção de dados de 30 dias, não estão disponíveis sob acordos de "zero data retention" (retenção zero de dados), ou ZDR, a menos que expressamente autorizado pela Anthropic, e são designados como Covered Models. O Claude Opus 5 está disponível sob ZDR. Consulte Requisitos de retenção de dados específicos por modelo.

Checklist de migração

  • Se sua organização tem um acordo de "zero data retention" (retenção zero de dados), ou ZDR, confirme a elegibilidade primeiro: esses modelos não estão disponíveis sob ZDR, a menos que expressamente autorizado pela Anthropic. Consulte Requisitos de retenção de dados específicos do modelo.
  • Atualize o nome do modelo de claude-opus-5 para claude-fable-5-1 (ou claude-mythos-5-1).
  • Remova qualquer configuração thinking: {type: "disabled"}: ela retorna um erro 400 no claude-fable-5-1. Controle o gasto de tokens com níveis mais baixos de "effort" (esforço) e revise max_tokens.
  • Substitua o tool_choice forçado (any ou tool) por auto mais uma instrução explícita (turno user ou mensagem do sistema no meio da conversa) e ferramentas com strict: true, ou por saídas JSON.
  • Se sua interface renderiza texto entre chamadas de ferramentas, defina display: "updates" (beta) ou "summarized" e renderize os blocos thinking não vazios.
  • Aplique os itens de "preserved thinking" (pensamento preservado), edição de histórico, comportamento, effort e "fallback" (alternativa de contingência) da lista de verificação do Claude Fable 5.
  • Restabeleça a linha de base de custo nas suas próprias cargas de trabalho. O "tokenizer" (tokenizador) não mudou. O preço por token é diferente.

Migrando para o Claude Fable 5.1 a partir do Claude Opus 4.8 ou anterior

Siga o checklist abaixo. No Claude Opus 4.7 ou anterior, comece pela seção correspondente do guia de migração do Claude Opus 5.5.

Atualize o nome do seu modelo

model = "claude-opus-4-8"  # Before
model = "claude-fable-5-1"  # After

# Ou, para o Claude Mythos 5.1, que oferece os mesmos recursos a organizações verificadas:
model = "claude-mythos-5-1"  # After

Checklist de migração

  • Se a sua organização tem um acordo de retenção zero de dados (ZDR), confirme a elegibilidade primeiro: esses modelos não estão disponíveis sob ZDR a menos que expressamente autorizado pela Anthropic. O Claude Opus 4.8 está disponível sob ZDR.
  • Atualize o nome do modelo de claude-opus-4-8 para claude-fable-5-1 (ou claude-mythos-5-1).
  • Remova qualquer configuração thinking: {type: "disabled"} e revise max_tokens. Requisições sem um campo thinking são executadas com pensamento adaptativo.
  • Atualize a análise de respostas que lê o conteúdo por posição, como content[0].text: uma resposta agora pode começar com blocos thinking, então selecione os blocos de conteúdo por type.
  • Substitua o tool_choice forçado (any ou tool) por auto mais uma instrução explícita (turno user ou mensagem do sistema no meio da conversa) e ferramentas com strict: true, ou por saídas JSON.
  • Passe os blocos thinking de volta inalterados e trate o texto deles como somente para exibição. O Claude Fable 5.1 lê os blocos de pensamento do Claude Opus 4.8: uma conversa que passa para o claude-fable-5-1 mantém seu raciocínio anterior. O Claude Opus 4.8 não consegue ler os blocos do Claude Fable 5.1.
  • Se o seu código monta o array messages por conta própria, verifique se ele edita turnos anteriores. Integrações escritas para o Claude Opus 4.8 e anteriores frequentemente truncam turnos antigos, removem ou reconstroem mensagens anteriores, ou atualizam o prompt system a cada requisição, e o Claude Opus 4.8 nunca se opôs. No claude-fable-5-1, cada uma dessas ações invalida os blocos de pensamento posteriores.
  • Trate stop_reason: "refusal", leia stop_details.category e considere fallbacks: "default" (beta).
  • Aplique os itens de pensamento preservado, edição de histórico, comportamento, esforço por mensagem e atualização de progresso do checklist do Claude Fable 5.
  • Reavalie effort (comece em high), revise prompts próximos ao mínimo de cache de 512 tokens (1.024 tokens no Claude Opus 4.8) e restabeleça a linha de base de custo e latência. O preço por token é diferente, e os tokens de pensamento são cobrados como tokens de saída, então cargas de trabalho que eram executadas sem pensamento no Claude Opus 4.8 podem produzir mais tokens de saída por requisição.

Migrando para o Claude Mythos 5.1 a partir do Claude Mythos 5

O Claude Mythos 5.1 é a contraparte do Claude Fable 5.1 para organizações verificadas por meio dos programas de verificação da Anthropic, como o Cyber Verification Program. Confirme que sua organização tem acesso ao Claude Mythos 5.1 antes de trocar os IDs de modelo.

A diferença no nível da API corresponde a Migrando para o Claude Fable 5.1 a partir do Claude Fable 5: a escolha forçada de ferramenta retorna um erro 400, e apenas o Claude Mythos 5.1 e o Claude Fable 5.1 leem os blocos de pensamento do Claude Mythos 5.1 (o Claude Mythos 5.1 lê os blocos do Claude Mythos 5, não o contrário). Diferentemente do Claude Fable 5.1, o Claude Mythos 5.1 não executa a verificação de conversa, portanto editar turnos anteriores não invalida os blocos de pensamento, embora ainda reinicie o cache de prompt.

Atualize o nome do seu modelo

model = "claude-mythos-5"  # Before
model = "claude-mythos-5-1"  # After

Checklist de migração

  • Atualize o nome do modelo de claude-mythos-5 para claude-mythos-5-1.
  • Substitua o tool_choice forçado (any ou tool) por auto mais uma instrução explícita (turno user ou mensagem do sistema no meio da conversa) e ferramentas com strict: true, ou por saídas JSON.
  • Trate stop_reason: "refusal" e leia stop_details.category antes do conteúdo da resposta. Consulte Recusas e fallback.
  • Continue passando os blocos thinking de volta inalterados em cada turno, incluindo os vazios.
  • Se o seu código monta o array messages por conta própria, mantenha o histórico da conversa somente com acréscimos (append-only) para manter o cache de prompt aquecido. O Claude Mythos 5.1 não executa a verificação de conversa, portanto as edições não invalidam seus blocos de pensamento.
  • Aplique as mudanças de comportamento e as mudanças recomendadas da seção do Claude Fable 5, exceto os itens de edição de histórico, que não se aplicam ao Claude Mythos 5.1.
  • Reavalie effort com uma nova varredura e refaça a linha de base de custo e latência. As leituras do cache de prompt custam um quarto da tarifa do Claude Mythos 5.

Was this page helpful?