Anthropic Bedrock Mantle: Claude Messages API Routing on AWS

For teams searching for AnthropicBedrockMantle, bedrock messages api, or claude code bedrock mantle, the important point is simple: Amazon Bedrock can now accept Claude Messages API-shaped requests through a Mantle endpoint, but it is not a full Anthropic API clone. That one endpoint choice now carries real architectural weight for routing policy.

On June 10, Anthropic published updated docs for a new Bedrock integration called Claude in Amazon Bedrock. The key change: a new endpoint called bedrock-mantle that serves Claude models through the standard Anthropic Messages API at /anthropic/v1/messages over SSE — the same request shape and SDK used with Anthropic's first-party API. This replaces the old InvokeModel and Converse path as the recommended integration, though that legacy path remains available.

Fable 5 was available on the new endpoint from day one; AWS later noted that Anthropic asked AWS to revoke Fable 5 and Mythos 5 access for export-control compliance, while other models such as Opus 4.8 were not affected. The practical result is that teams operating Claude workloads on AWS now have three distinct endpoint choices, each with different security, latency, and feature characteristics.

What changed

The new bedrock-mantle endpoint has the following properties:

• API shape: Anthropic Messages API (/anthropic/v1/messages), with SSE streaming. No more AWS event-stream encoding.
• Model IDs: Prefixed with anthropic. — e.g. anthropic.claude-fable-5, anthropic.claude-opus-4-8.
• Authentication: Three paths — Bedrock service role (recommended), IAM assumed roles, or bearer tokens. All go through AWS SigV4 signing.
• Zero operator access: Anthropic personnel have no access to the inference infrastructure running on AWS. This is a meaningful security differentiation for regulated workloads.
• Models at launch: Claude Fable 5, Opus 4.8, Opus 4.7, Haiku 4.5 (open at launch); Mythos Preview (invitation only via Project Glasswing, us-east-1 only). AWS later updated its announcement to say Fable 5 and Mythos 5 access was unavailable after Anthropic's export-control compliance request; Opus 4.8 and other models were not affected.
• Regions: Global endpoint for Fable 5, Opus 4.8, Opus 4.7, and Haiku 4.5. Regional endpoints carry a 10% pricing premium for data residency.
• Default quota: 2 million input tokens per minute; up to 4 million without Anthropic approval (AWS-side RPM limits apply).
• SDK support: AnthropicBedrockMantle client available across Python, TypeScript, C#, Go, Java, PHP, Ruby. Endpoint pattern: https://bedrock-mantle.{region}.api.aws/anthropic/v1/messages.

The feature gap between the new endpoint and the Anthropic first-party API is significant. Not supported on bedrock-mantle: server-side tools (code execution, web search, web fetch), Agent infrastructure (Agent Skills, MCP connector), Message Batches API, Files API, URL source inputs, and server-side fallback — the fallback path requires client-side orchestration instead.

This matters because it creates a real tradeoff matrix for routing policy, not a trivial endpoint swap.

Why it matters for AI engineering teams

The last time teams had to think about Claude-on-AWS endpoint architecture, there was one choice: legacy Bedrock with InvokeModel. That path was functional but incompatible with the Anthropic SDK — you needed AWS SDK wrappers, ARN-versioned model identifiers, and event-stream encoding.

Now there are three paths, and the decision is non-trivial:

This table is the core decision. Each path has a different answer to "which teams should use which endpoint when."

Direct Anthropic API is the default for teams that need full feature parity — server-side tools, Claude Managed Agents, MCP connector, or Message Batches for bulk inference. The tradeoff is a separate billing relationship and no AWS-native auth boundary.

Claude Platform on AWS is the choice for teams that want Anthropic-operated inference with AWS Marketplace billing and near-day-one feature updates. It gives a middle ground between native API and AWS-managed infrastructure.

Bedrock Messages API is the right fit for regulated workloads, AWS-embedded architecture teams, and anyone who requires zero operator access (no Anthropic personnel on inference infrastructure) plus IAM-based governance. The feature gap is real, but for pure inference workloads — sending prompts, getting completions — the Messages API shape with SigV4 auth is a clean fit.

The router/operator angle

For multi-provider routing teams, this is not a "just pick one" decision. It changes three operational layers:

Fallback policy. The lack of server-side fallback on bedrock-mantle means client-side fallback orchestration is mandatory for teams that use that endpoint for latency-sensitive or availability-critical traffic. If a Fable 5 request fails on Bedrock, the gateway must catch, retry, and fall back to another Claude endpoint or a different model — Bedrock will not do it for you. This is where a routing layer with per-model fallback chains earns its keep.

Cost and quota routing. The 2 million TPM default quota on Bedrock is generous but bounded. Teams running high-throughput inference should route overflow traffic to the direct Anthropic API or use Bedrock's global endpoint (which distributes load across regions automatically). The 10% regional premium means a cost-aware router should distinguish between latency-optimized global routing and data-residency-required regional routing.

Feature-aware dispatch. If a workload uses server-side tools, MCP connectors, or agent skills, bedrock-mantle cannot serve it. A routing layer that inspects request features and dispatches accordingly — Bedrock for pure inference, direct API for tool-augmented workflows — avoids runtime failures that would otherwise surface as opaque 400 errors.

The auth path choice also has governance implications. Bearer tokens are least-preferred (short-term, no long-lived key). IAM assumed roles give 12-hour federated sessions. Bedrock service roles are the most secure for persistent infrastructure. Teams should encode their auth strategy into the routing policy rather than leaving it as an application-level concern.

What TheRouter users should watch or try

If you are routing Claude traffic and currently using a single endpoint, this is the moment to evaluate a multi-endpoint strategy. A few concrete steps:

1. Audit your Claude workloads. Separate pure-inference traffic (prompts in, completions out) from tool-augmented traffic (MCP, code execution, agent workflows). Only the first category is eligible for bedrock-mantle.

2. Check your fallback chains. If you currently fall back from Anthropic API to Bedrock or vice versa, verify that the fallback target supports the features your workload uses. Falling back to bedrock-mantle on a request that needs server-side tools will produce a hard failure.

3. Review your auth strategy. If you are still using bearer tokens on Bedrock, upgrade to IAM assumed roles or service roles. The bearer token path is explicitly documented as least-preferred and adds operational fragility.

4. Watch the feature parity delta. Anthropic's docs now have a clear "supported / not supported" table for bedrock-mantle. Track it — as Anthropic closes the gap, more workloads become eligible for the AWS-managed path, which shifts the routing calculus.

5. Test regional premium in your cost model. The 10% regional pricing premium is new. If you are routing globally, the global endpoint with no premium is likely the right default; add regional routing only for compliance-mandated traffic.

The source documentation is now live at Claude in Amazon Bedrock and the AWS blog announcement.