Claude Fable 5.1 on AWS: the model that demands an immutable history

There are two distinct paths, and choosing between them is not cosmetic. The first is Claude in Amazon Bedrock, model ID anthropic.claude-fable-5-1, served at bedrock-mantle.{region}.api.aws/anthropic/v1/messages — Anthropic's Messages API signed with SigV4, no longer the ARN-versioned InvokeModel/Converse pair. AWS operates the stack, is the sole data processor, and authorization becomes bedrock-mantle:CreateInference scoped to the model ARN. The second is Claude Platform on AWS, operated by Anthropic, billed through AWS Marketplace, with feature availability typically same-day and PrivateLink support.

Specs are identical on both: 1M context, 128K output, adaptive thinking always on with default effort of high, text and image input. The global endpoint is available for Fable 5.1; regional endpoints today are us-east-1 only — and a regional endpoint carries a 10% premium over global, an expensive detail to discover after you've written the data-residency policy. The launch blog also cites the us. and global. inference profiles and GovCloud (US) support.

Worth recording what the vendor's own documentation recommends: for most workloads, start with Claude Opus 5 (US$5 / US$25 per million) and only move up to Fable 5.1 when your evals on Opus 5 at high effort still fall short. That is a cost guardrail stated by the supplier, and I take it seriously.

Here's the part that will cost you a sprint. Three changes break the contract for anyone already calling Fable 5.

First: forced tool_choice is gone. {"type": "any"} and {"type": "tool", "name": "..."} return a 400 invalid_request_error. The rationale is technical and sound — thinking is always on, and a forced call would skip it, pushing the model's working-out into the tool arguments and degrading their quality. Except half the orchestrators I've seen in production use forced tool_choice as their structured-output mechanism. The migration path is strict tool use or structured outputs — and structured outputs is not available on Bedrock. On the AWS-native path you're left with explicit prompt instructions plus schema validation on your side.

Second and third, which are the same pain: thinking blocks are bound. Each block records which model produced it and is preserved in one direction only. And modifying anything before a thinking block — the system prompt, the tools array, an earlier message — errors on the next request: a 400 saying "The block is bound to a different conversation." This is enforced for accounts created on or after August 31, 2026.

The patterns that break are mundane: injecting a per-request reminder and deleting it, reordering turns, rebuilding system between calls in the same conversation. Everyone does this.

US$10 per million input tokens and US$50 output is expensive, and it's unchanged from Fable 5. What changed is where the money goes.

In a long-horizon agent, the dominant volume isn't new prompt: it's re-reading the same prefix — instructions, tool definitions, loaded files — every turn. With cache reads at 0.025× input instead of 0.1×, that component drops to a quarter. Run the numbers with plausible values: a 200k-token prefix, 50 turns, warm cache. That's 10 million cache-read tokens: US$2.50 on Fable 5.1 against US$10.00 on Fable 5. Cache writes are unchanged (US$12.50/MTok for 5 minutes, US$20 for 1 hour) and the minimum cacheable prompt is still 512 tokens.

Two honest counterweights. First, output at US$50/MTok is where Fable 5.1 hurts most, and the documentation records a specific cost regression: the model tends to rewrite whole files instead of making targeted edits. In a coding agent that's money burned on output tokens — the fix is a prompt line, but you need to know it exists. Second, the current tokenizer produces roughly 30% more tokens for the same text than models older than Opus 4.7. Comparing list prices across generations without correcting for that gives you the wrong number.

The 50% batch discount (US$5 / US$25) exists — but the Message Batches API isn't on Bedrock.

This is the part that decides whether the model enters a regulated financial environment, and it's where the announcement is denser than it looks.

Fable 5.1 is a Covered Model: it carries 30-day data retention and is not available under zero data retention unless expressly authorized by Anthropic. If you have a contractual ZDR clause, that's a blocker, not a detail. The answer is Enterprise Frontier Safeguards, built in partnership between AWS and Anthropic: instead of choosing between privacy and misuse detection, activity data lives in your own S3 bucket, under your encryption keys and your access policies, with automated analysis looking for abuse signals — no human review by Anthropic employees required. Anthropic doesn't charge for EFS; you pay AWS for storage, reads, writes and egress.

The operational detail that matters: EFS rolls out in phases starting later this fall, and the AWS blog records that eligible customers get ZDR on Fable 5 and 5.1 on Bedrock and Claude Platform on AWS through December 31, 2026. That's a contractual window with an expiry date — if your program depends on it, put it on the risk calendar now.

Add content provenance on top: all generated text carries Anthropic's statistical watermark, and image and video files the model produces carry signed C2PA Content Credentials when retrieved through the Files API — which, remember, isn't on Bedrock.