Claude Fable 5.1 na AWS: o modelo que exige histórico imutável
Anúncio de modelo novo é o tipo de notícia que envelhece em três semanas, então prefiro ler as notas de release do que o press release. No caso do Claude Fable 5.1, disponível no Amazon Bedrock desde 1º de setembro de 2026, a leitura muda completamente a conversa: a manchete é "mais inteligência nas tarefas difíceis", mas o que efetivamente entra no meu backlog de arquitetura são três quebras de contrato na API, uma economia de cache que reescreve o custo de sessões agênticas longas e uma lista de features que simplesmente não existe no caminho Bedrock. Este é um review de quem vai operar isso em produção, não de quem vai testar no console.
Os três números que mudam decisão de arquitetura
high, cutoff de conhecimento em junho de 2026.O que exatamente entrou no catálogo
Existem dois caminhos distintos e a escolha entre eles não é cosmética. O primeiro é Claude in Amazon Bedrock, com o ID anthropic.claude-fable-5-1, servido pelo endpoint bedrock-mantle.{region}.api.aws/anthropic/v1/messages, a Messages API da Anthropic assinada com SigV4, não mais o InvokeModel/Converse de ARN versionado. A AWS opera a stack, é a única processadora de dados e a autorização passa a ser bedrock-mantle:CreateInference sobre o ARN do modelo. O segundo é Claude Platform on AWS, operado pela Anthropic, faturado via AWS Marketplace, com acesso a features tipicamente no mesmo dia do lançamento e suporte a PrivateLink.
As especificações são idênticas nos dois: 1M de contexto, 128K de saída, adaptive thinking sempre ativa com effort default em high, entrada de texto e imagem. O endpoint global está disponível para o Fable 5.1; endpoints regionais, hoje, só em us-east-1, e endpoint regional custa 10% a mais que o global, o que é um detalhe caro de descobrir depois de escrever a política de residência de dados. O blog de lançamento cita ainda os perfis de inferência us. e global. e suporte em GovCloud (US).
Vale registrar o que a própria documentação recomenda: para a maioria das cargas, comece pelo Claude Opus 5 (US$ 5 / US$ 25 por milhão) e só suba para o Fable 5.1 quando suas avaliações no Opus 5 em effort alto ainda não fecharem. Isso é uma orientação de custo dita pelo fornecedor, e eu a levo a sério.
O ciclo de um turno agêntico no Bedrock, e onde ele quebra
O contrato do Fable 5.1 é append-only: o prefixo (system + tools) fica estável, o histórico só cresce e os thinking blocks voltam intactos. É isso que mantém o cache quente a US$ 0,25/MTok, e é isso que produz um 400 quando o orquestrador edita um turno anterior.
- Prefixo estável · system + tools · mín. 512 tokens
- Histórico append-only · thinking blocks devolvidos intactos
- System message turn-scoped · clear_at: next_user_message (beta)
- IAM · SigV4 · bedrock-mantle:CreateInference
- bedrock-mantle · /anthropic/v1/messages
- CloudTrail + CloudWatch · retenção rolante de 30 dias
- Fable 5.1 · 1M ctx · 128K out · effort=high
- Adaptive thinking · sempre ligada · display=omitted
- tool_choice: auto | none · forçado ⇒ 400
- Cache write 5m · US$ 12,50/MTok
- Cache read · US$ 0,25/MTok = 0,025× input
- 400 · "block is bound to · a different conversation"
- Sem anthropic-beta no Bedrock · ⇒ sem drop_block, sem turn-scoped
Onde ele brilha de verdade
O novo contrato é o histórico imutável
Aqui está a parte que vai custar sprint. Três mudanças são quebra de contrato para quem já chama o Fable 5.
Primeira: tool_choice forçado deixou de existir. {"type": "any"} e {"type": "tool", "name": "..."} retornam 400 invalid_request_error. A justificativa é técnica e boa, thinking está sempre ligada, e uma chamada forçada pularia o raciocínio, empurrando o "pensar" para dentro dos argumentos da ferramenta e degradando a qualidade deles. Só que metade dos orquestradores que já vi em produção usa tool_choice forçado como mecanismo de saída estruturada. A migração é ir para strict tool use ou structured outputs, e structured outputs não está disponível no Bedrock. No caminho AWS-nativo, sobra instrução explícita em prompt mais validação de schema do seu lado.
Segunda e terceira, que são a mesma dor: thinking blocks são vinculados. Cada bloco registra qual modelo o produziu e é preservado numa direção só. E modificar qualquer coisa antes de um thinking block, o system, o array tools, uma mensagem anterior, resulta em erro na próxima requisição: 400 com "The block is bound to a different conversation". Isso é enforced para contas criadas a partir de 31 de agosto de 2026.
Os padrões que quebram são banais: injetar um lembrete por requisição e removê-lo depois, reordenar turnos, reconstruir o system entre chamadas na mesma conversa. Todo mundo faz isso.
A válvula de escape existe, mas não no Bedrock
A Anthropic oferece saídas elegantes para o problema do histórico imutável: thinking.block_binding.prefix_mismatch_behavior: "drop_block" sob o header thinking-binding-controls-2026-08-01, system messages com escopo de turno via mid-conversation-system-clear-at-2026-08-21, effort por mensagem via mid-conversation-output-config-2026-07-01 e progress updates legíveis via thinking-display-updates-2026-08-18. Todas são beta. E a tabela comparativa da própria documentação registra que o header anthropic-beta não é suportado no Claude in Amazon Bedrock. Ou seja: quem escolhe o Bedrock pela fronteira de segurança e pelo processador de dados único fica, hoje, com o contrato rígido e sem as ferramentas de diagnóstico e mitigação, inclusive sem o input_transformations que diria quais blocos foram descartados silenciosamente. Também ficam de fora Message Batches (adeus desconto de 50% pela API de lote), Files API, ferramentas server-side (code execution, web search, web fetch), Agent Skills, conector MCP e o fallback server-side, que precisa ser reimplementado no cliente.
Bedrock, Claude Platform on AWS ou o caminho legado
| Claude in Amazon Bedrock | Claude Platform on AWS | Bedrock legado (Opus 4.6 e anteriores) | |
|---|---|---|---|
| Quem opera a stack | AWS, processadora única dos dados de inferência | Anthropic; a AWS entrega autenticação e faturamento | AWS |
| Superfície de API | Messages API em /anthropic/v1/messages | Claude API completa em /v1/{endpoint} | Converse / InvokeModel com ARN versionado |
| Headers beta | Não suportados | Passam via anthropic-beta | Não suportados |
| Cotas e limites | AWS: 2M TPM de entrada por padrão, até 5M/500K sob pedido | Anthropic: organizações novas entram no tier Start | AWS, por cota de serviço |
| Faturamento e residência | Uso de serviço AWS; endpoint regional custa 10% a mais que o global | AWS Marketplace; dados podem não residir na AWS, fixe inference_geo | Uso de serviço AWS |
| Quando eu escolheria | FedRAMP High, IL4/IL5, HIPAA, ou exigência de processadora única | Quando você precisa de Agent Skills, betas e paridade de features no mesmo dia | Só para não reescrever integração existente que ainda funciona |
A conta muda de forma, não de tamanho
US$ 10 por milhão de tokens de entrada e US$ 50 de saída é caro, e continua igual ao Fable 5. O que mudou é onde o dinheiro é gasto.
Em agente de longa duração, o volume dominante não é prompt novo: é reler o mesmo prefixo, instruções, definição de ferramentas, arquivos carregados, a cada turno. Com leitura de cache a 0,025× do input em vez de 0,1×, esse componente cai a um quarto. Faça a conta com números plausíveis: prefixo de 200 mil tokens, 50 turnos, cache quente. São 10 milhões de tokens de cache read: US$ 2,50 no Fable 5.1 contra US$ 10,00 no Fable 5. A escrita de cache não mudou (US$ 12,50/MTok para 5 minutos, US$ 20 para 1 hora) e o mínimo cacheável continua em 512 tokens.
Dois contrapesos honestos. Primeiro, a saída a US$ 50/MTok é onde o Fable 5.1 dói mais, e a documentação registra uma regressão de custo específica: o modelo tende a reescrever arquivos inteiros em vez de fazer edições cirúrgicas. Num agente de código, isso é dinheiro queimado em tokens de saída, a correção é de prompt, mas você precisa saber que existe. Segundo, o tokenizador atual produz cerca de 30% mais tokens para o mesmo texto do que os modelos anteriores ao Opus 4.7. Comparar preço de tabela entre gerações sem corrigir por isso dá o número errado.
O desconto de 50% em lote (US$ 5 / US$ 25) existe, mas a Message Batches API não está no Bedrock.
Como eu adotaria isso numa base que já roda
- 1
1. Audite
tool_choiceantes de trocar o ID do modeloUm grep por
"type": "any"e"type": "tool"encontra tudo o que vai virar 400. A mesma validação vale no endpoint de contagem de tokens, então nem o pré-cálculo de custo escapa. Substitua por instrução explícita no prompt ("use a ferramenta X para responder isso") mais validação de schema no cliente, já que structured outputs não existe no Bedrock. - 2
2. Prove que seu histórico é append-only
Se o seu código monta o array
messagesna mão, esse é o teste que decide a migração. Rode uma sessão real e faça o diff de cada requisição contra a anterior: nenhum byte antes do último thinking block pode mudar. Lembretes por turno saem de injeção-e-remoção; mudanças detoolsviram mid-conversation tool changes. Poda de contexto só server-side. - 3
3. Fixe o perfil de inferência conscientemente
global.anthropic.claude-fable-5-1maximiza disponibilidade sem prêmio de preço; endpoint regional (hoje sóus-east-1para o Fable 5.1) custa 10% a mais e existe para atender residência de dados. Escolha por requisito escrito, não por default de SDK, e documente a decisão num ADR, porque ela vai ser questionada na primeira auditoria. - 4
4. Recalibre effort em vez de aceitar o default
O default é
highe o ganho do 5.1 sobre o 5 é maior justamente nos níveis altos, mas o custo também. Atenção a um efeito colateral documentado: em effortlowo modelo responde de memória com mais frequência e chama menos ferramentas de busca. Se o turno precisa de informação fresca, suba o effort ou adicione a instrução de verificação. - 5
5. Reimplemente o fallback no cliente
Uma recusa volta como HTTP 200 com
stop_reason: "refusal"e umstop_detailsnomeando a política, não como erro. Se o seu tratamento só olha status code, você vai servir resposta vazia ao usuário. Os alvos de fallback permitidos são Opus 4.8 e Opus 5, e o fallback server-side não existe no Bedrock: é padrão client-side. - 6
6. Ponha guardrail de custo antes do primeiro turno em produção
IAM com
bedrock-mantle:CreateInferencerestrito aos ARNs aprovados, CloudTrail para quem chamou o quê, CloudWatch com retenção rolante de 30 dias e AWS Budgets com alarme por anomalia. Uma sessão agêntica de horas com saída a US$ 50/MTok é a coisa mais fácil de explodir num mês. E use Claude Code 2.1.255 ou superior se for por ali.
Governança: Covered Model, 30 dias de retenção e o que é EFS
Esta é a parte que decide se o modelo entra num ambiente financeiro regulado, e é onde o anúncio é mais denso do que parece.
O Fable 5.1 é um Covered Model: carrega retenção de dados de 30 dias e não está disponível sob zero data retention a menos que expressamente autorizado pela Anthropic. Para quem tem cláusula contratual de ZDR, isso é um bloqueio, não um detalhe. A resposta é o Enterprise Frontier Safeguards, construído em parceria entre AWS e Anthropic: em vez de escolher entre privacidade e detecção de uso indevido, os dados de atividade ficam no seu bucket S3, sob suas chaves de criptografia e suas políticas de acesso, com análise automatizada procurando sinais de abuso, sem revisão humana por funcionários da Anthropic. A Anthropic não cobra pelo EFS; você paga o armazenamento, as leituras, as escritas e o egress à AWS.
O detalhe operacional que importa: o EFS entra em fases a partir do fim deste outono no hemisfério norte, e o blog da AWS registra que clientes elegíveis recebem ZDR em Fable 5 e 5.1 no Bedrock e no Claude Platform on AWS até 31 de dezembro de 2026. É uma janela contratual com data de validade, se o seu programa depende dela, coloque no calendário de risco agora.
Acrescente a isso a proveniência de conteúdo: todo texto gerado carrega a marca d'água estatística da Anthropic, e arquivos de imagem e vídeo produzidos pelo modelo carregam Content Credentials C2PA assinadas quando recuperados pela Files API, que, lembre, não está no Bedrock.
O que eu não faria com o Fable 5.1
- Trocar o ID do modelo em produção e esperar que passe. Três quebras de contrato e sete diferenças de comportamento sem mudança de código: a migração exige rodar suas avaliações de novo, não um pull request de uma linha.
- Usar o Fable 5.1 como modelo default de toda a plataforma. A própria Anthropic recomenda começar pelo Opus 5, metade do preço, e só escalar quando as avaliações não fecharem. Roteamento por dificuldade de tarefa é engenharia; usar o topo da linha para tudo é desperdício com narrativa de qualidade.
- Injetar um lembrete no histórico e removê-lo na requisição seguinte. É o padrão mais comum de agente e é exatamente o que invalida todos os thinking blocks posteriores, e, no Bedrock, sem o header beta que permitiria descartar o bloco em vez de falhar.
- Rotear de volta para um modelo anterior no meio da conversa. Modelos anteriores não leem os thinking blocks do Fable 5.1; a API os descarta antes da inferência. Sem o header beta, o descarte é silencioso, o roteador "funciona" e a qualidade cai sem sinal em lugar nenhum.
- Assumir que a UI vai continuar narrando o progresso. O 5.1 escreve menos atualizações entre chamadas de ferramenta do que o 5, principalmente em effort alto, e o default de
thinking.displayéomitted. Um turno agêntico longo pode parecer travado para o usuário.
Lente Well-Architected sobre a adoção
Segurança
No caminho Bedrock, a AWS é a processadora única e a Anthropic não tem acesso à infraestrutura de inferência, é o que sustenta FedRAMP High, IL4/IL5 e cargas HIPAA-ready. Restrinja bedrock-mantle:CreateInference aos ARNs aprovados e negue bedrock:CallWithBearerToken fora de tokens de curta duração via condição bedrock:BearerTokenType. Sessões de role assumida expiram em 12 horas: agentes que rodam por horas precisam renovar credencial, não segurar uma.
Confiabilidade
Endpoint global dá roteamento dinâmico entre regiões sem prêmio de preço; regional fixa uma região e cobra 10% a mais. Como o Claude Platform on AWS usa um pool de capacidade separado do Bedrock e da API de primeira parte, ele é uma rota de failover legítima, desde que o seu código trate stop_reason: "refusal" como caminho normal e não como exceção.
Se eu tivesse que decidir amanhã, faria o seguinte: mantenho o Opus 5 como modelo de trabalho da plataforma e habilito o Fable 5.1 apenas atrás de um roteador, para as tarefas onde minhas avaliações no Opus 5 em effort alto não fecham, que na minha experiência são refactor multi-arquivo e extração sobre documento denso, não chat. Antes disso, gastaria um dia inteiro só no teste de histórico append-only, porque já perdi tempo demais debugando orquestrador que injeta lembrete e apaga depois; agora isso deixou de ser feio e virou 400. A lição que carrego de migrações anteriores é que o custo real de uma troca de modelo nunca está no preço por token, está nas suposições que o seu código faz sobre a API e que ninguém escreveu em lugar nenhum. E deixo um alerta de calendário para 31 de dezembro de 2026: a janela de ZDR provisória para Covered Models tem data de validade, e descobrir isso em janeiro é descobrir tarde.
Perguntas que aparecem na primeira reunião
Preciso trocar do InvokeModel/Converse para o novo endpoint?
A integração legada com identificadores de modelo em ARN versionado continua disponível e documentada, mas o Fable 5.1 vive no caminho bedrock-mantle, com a Messages API em /anthropic/v1/messages, streaming SSE padrão e o mesmo formato de corpo da API de primeira parte. Se você quer o modelo novo, a mudança de endpoint vem junto.
Dá para desligar o thinking para reduzir custo e latência?
Não. Adaptive thinking é sempre ligada: thinking: {"type": "enabled"} com budget_tokens e {"type": "disabled"} retornam 400. Omita o campo ou envie {"type": "adaptive"}. O controle disponível é o parâmetro effort. Prefill de resposta do assistente e valores não-default de temperature, top_p ou top_k também retornam 400.
O que é o Claude Mythos 5.1?
O mesmo modelo subjacente, com as capacidades completas de cyber e bio preservadas para pesquisa em segurança e biologia, oferecido apenas a participantes aprovados do Project Glasswing. Compartilha especificações e preço com o Fable 5.1, e o acesso passa pelo seu time de conta na Anthropic, AWS ou Google Cloud. Não é um caminho de autoatendimento.
Fontes consultadas
Veredito
O Fable 5.1 é o modelo mais capaz que já esteve disponível dentro do perímetro AWS, e a leitura de cache a 0,025× do input torna economicamente viável um tipo de agente que antes só existia em demo. Mas ele não é um upgrade transparente: é um contrato mais rígido, histórico imutável, sem chamada de ferramenta forçada, latência maior, trocado por raciocínio melhor e menos falso sucesso. E, no caminho Bedrock, você paga esse contrato sem receber as válvulas de escape beta que a Claude API oferece. Recomendo adotar seletivamente: mantenha o Opus 5 como default da plataforma, coloque o Fable 5.1 atrás de um roteador para refactor multi-arquivo, pesquisa multi-etapa e extração sobre documento denso, e só depois de provar que o seu orquestrador nunca edita o passado. Quem tem exigência contratual de zero data retention deve tratar a janela até 31/12/2026 como risco datado, não como estado permanente. Se a sua carga é chat síncrono, este não é o seu modelo, e essa é a resposta mais barata deste review.
Continue lendo
Deep dives de arquitetura, AWS, IA e mercado: direto no seu email. Grátis.
Sem spam · cancele quando quiser
Pergunte ao Fernando sobre isto
Uma resposta focada sobre este artigo, do meu assistente de IA, baseada no meu trabalho.
Participe da conversa
Entre para comentar
Confirme seu e-mail para participar, você também recebe a newsletter. Sem senha.