# Claude Fable 5.1 na AWS: o modelo que exige histórico imutável

O Fable 5.1 chegou ao Bedrock em 1º de setembro de 2026 com o mesmo preço de entrada e saída do Fable 5, mas com leitura de cache a um quarto do custo. O que ninguém colocou no anúncio é que ele troca flexibilidade de orquestração por qualidade de raciocínio: tool_choice forçado morreu e editar o histórico passa a ser erro. Avaliei o que isso significa para quem opera agentes de longa duração dentro do perímetro AWS.

- URL: https://fernando.moretes.com/blog/claude-fable-5-1-na-aws-o-modelo-que-exige-historico-imutavel-claude-fable

- Markdown: https://fernando.moretes.com/blog/claude-fable-5-1-na-aws-o-modelo-que-exige-historico-imutavel-claude-fable/article.md?lang=pt

- Published: 2026-09-01T20:42:30.355Z

- Category: IA & Agentes

- Tags: amazon-bedrock, claude, agentes, finops, llmops, governanca, aws

- Reading time: 10 min

- Source: [Claude Fable 5.1, Anthropic's new frontier model is now available on AWS](https://aws.amazon.com/about-aws/whats-new/2026/09/claude-fable-5-1-aws/)

---

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

- **US$ 0,25/MTok** — leitura de cache — 0,025× o preço de entrada. Contra 0,1× nos demais modelos Claude e US$ 1,00/MTok no Fable 5. Entrada e saída ficam em US$ 10 e US$ 50 por milhão.
- **1M / 128K** — janela de contexto e saída máxima síncrona. Preço padrão por token em toda a janela. Adaptive thinking sempre ligada, effort default `high`, cutoff de conhecimento em junho de 2026.
- **2M TPM** — cota padrão de tokens de entrada por minuto no Bedrock. Elevável a 5M de entrada e 500K de saída sem aprovação adicional da Anthropic. O limite de requisições por minuto é da AWS e vai por ticket de suporte.

## 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.

### 🧭 Contrato da sessão (append-only)

- Prefixo estável system + tools · mín. 512 tokens (data)
- Histórico append-only thinking blocks devolvidos intactos (data)
- System message turn-scoped clear_at: next_user_message (beta) (compute)

### 🟧 AWS — Claude in Amazon Bedrock

- IAM · SigV4 bedrock-mantle:CreateInference (security)
- bedrock-mantle /anthropic/v1/messages (compute)
- CloudTrail + CloudWatch retenção rolante de 30 dias (network)

### 🧠 Claude Fable 5.1 — anthropic.claude-fable-5-1

- Fable 5.1 1M ctx · 128K out · effort=high (ai)
- Adaptive thinking sempre ligada · display=omitted (ai)
- tool_choice: auto | none forçado ⇒ 400 (ai)

### 💸 Economia do token

- Cache write 5m US$ 12,50/MTok (storage)
- Cache read US$ 0,25/MTok = 0,025× input (storage)

### ⚠️ Modos de falha

- 400 · "block is bound to a different conversation" (external)
- Sem anthropic-beta no Bedrock ⇒ sem drop_block, sem turn-scoped (external)

### Fluxos

- orch -> prefix: 1. fixa system + tools
- prefix -> cwrite: primeira chamada grava o cache
- prefix -> endpoint: 2. request assinado SigV4
- iam -> endpoint: condição no ARN do modelo
- endpoint -> model: 3. Messages API
- model -> think: 4. raciocínio adaptativo
- think -> tools: 5. decide chamar ferramenta
- tools -> history: 6. resultado anexado ao FIM
- turnsys -> history: lembrete por turno sem editar o passado
- history -> cread: 7. turno seguinte relê o prefixo
- cread -> model: 8. loop a 1/40 do preço de entrada
- history -> err400: ✗ se você editar/reordenar um turno
- err400 -> nobeta: escape hatch indisponível neste caminho
- endpoint -> obs: invocação, latência, erro

## Onde ele brilha de verdade

- **Sessões de horas, não de minutos.** Os ganhos declarados se concentram em coding agêntico multi-arquivo, refactors grandes, migrações e revisão de código ao longo de sessões longas — exatamente a carga que quebrava por deriva de contexto nas gerações anteriores.
- **Admitir que travou.** O comportamento anunciado de dizer que não conseguiu, em vez de reportar sucesso, e de não desabilitar um teste que falha, é o item mais relevante para automação sem humano no loop. Vale mais do que qualquer ponto de benchmark.
- **Leitura de cache a 0,025× do input.** Uma sessão agêntica que relê um prefixo de 200 mil tokens ao longo de 50 turnos paga US$ 2,50 em cache read no Fable 5.1 contra US$ 10,00 no Fable 5. É a diferença entre um piloto e um serviço.
- **Visão sobre documento denso.** Ler gráficos, demonstrativos e tabelas aninhadas em PDF, com crop-and-zoom, é a capacidade que destrava extração em serviços financeiros sem montar um pipeline de OCR próprio.
- **Thinking preservado ao subir de modelo.** O Fable 5.1 lê os thinking blocks de modelos anteriores. Uma conversa que começa no Sonnet 5 e escala para o Fable 5.1 mantém o raciocínio — só não faz o caminho de volta.

## 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
| Critério | 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_choice` antes de trocar o ID do modelo** — Um 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 `messages` na 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 de `tools` viram mid-conversation tool changes. Poda de contexto só server-side.

3. **3. Fixe o perfil de inferência conscientemente** — `global.anthropic.claude-fable-5-1` maximiza disponibilidade sem prêmio de preço; endpoint regional (hoje só `us-east-1` para 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 é `high` e 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 effort `low` o 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 um `stop_details` nomeando 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:CreateInference` restrito 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

- **security**: 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.
- **reliability**: 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.

> **Nota de curadoria:** 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

- [AWS What's New — Claude Fable 5.1 is now available on AWS](https://aws.amazon.com/about-aws/whats-new/2026/09/claude-fable-5-1-aws/)
- [AWS Machine Learning Blog — Introducing Claude Fable 5.1 on AWS](https://aws.amazon.com/blogs/machine-learning/introducing-claude-fable-5-1-on-aws/)
- [Anthropic Docs — Claude Fable 5.1 overview (specs, model IDs, pricing)](https://platform.claude.com/docs/en/models/fable-5-1/overview)
- [Anthropic Docs — What's new in Claude Fable 5.1 (breaking changes)](https://platform.claude.com/docs/en/models/fable-5-1/whats-new-fable-5-1)
- [Anthropic Docs — Claude in Amazon Bedrock (auth, quotas, regions, feature gaps)](https://platform.claude.com/docs/en/build-with-claude/claude-in-amazon-bedrock)
- [Anthropic Docs — Claude Platform on AWS (comparison with Bedrock)](https://platform.claude.com/docs/en/build-with-claude/claude-platform-on-aws)
- [Anthropic — Developing Enterprise Frontier Safeguards with our customers](https://www.anthropic.com/news/enterprise-frontier-safeguards)
- [Anthropic Docs — Preserved thinking and block binding controls](https://platform.claude.com/docs/en/build-with-claude/thinking)

## 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.

**Rating:** 8.5/10