The anthropic. Prefix Rule: Why Bedrock Model IDs Are Different

Amazon Bedrock is a multi-vendor catalog: Anthropic's models sit alongside models from other providers, so every ID carries a provider prefix. That is the whole reason the rule exists — Bedrock needs anthropic. to namespace the catalog, while platforms that only serve Claude under Anthropic's own publisher path (the Claude API, Claude Platform on AWS, Google Cloud, Microsoft Foundry) use bare first-party IDs. Simple enough, except that Bedrock has two API surfaces and each formats the rest of the ID differently.

Three ID forms on one cloud

Two details keep tripping people up. First, the dateless 4.6+ IDs are still pinned snapshots, not evergreen pointers — Anthropic changed the naming convention with the 4.6 generation, not the pinning semantics. Second, the legacy surface's routing prefix is part of the model ID string itself: switching a workload from global to US-geography routing means editing the ID (global.anthropic.claude-opus-4-6-v1 → us.anthropic.claude-opus-4-6-v1), not a separate parameter.

Availability is not symmetrical

You cannot mechanically translate every ID between the two Bedrock surfaces, because the catalogs differ: Claude Fable 5, Opus 4.8, and Opus 4.7 have no ARN-versioned model IDs, and Claude Sonnet 5 is not available on the legacy surface at all. Current-generation models effectively require the Mantle surface (or Claude Platform on AWS, which uses bare 1P IDs). To see what the legacy surface offers in your account, run aws bedrock list-foundation-models --by-provider anthropic.

A resolver, not string surgery

The tempting shortcut — "anthropic." + model_id — breaks on every pre-4.6 model and on the legacy surface. The robust approach is a lookup table keyed by canonical (first-party) ID, with per-platform overrides and a bare-ID default:

CANONICAL_TO_PLATFORM = {
    "claude-opus-4-8":  {"bedrock": "anthropic.claude-opus-4-8"},
    "claude-fable-5":   {"bedrock": "anthropic.claude-fable-5"},
    "claude-sonnet-5":  {"bedrock": "anthropic.claude-sonnet-5"},
    "claude-haiku-4-5": {"bedrock": "anthropic.claude-haiku-4-5-20251001-v1:0",
                         "vertex":  "claude-haiku-4-5@20251001"},
}

def resolve(canonical: str, platform: str) -> str:
    forms = CANONICAL_TO_PLATFORM.get(canonical, {})
    return forms.get(platform, canonical)  # bare 1P ID is the default

This is deliberately boring: a data table your team can review against the official models overview, extended one row per model. Log the canonical ID everywhere (metrics, cost dashboards, evals) and translate at the last moment, inside the request path. If you support the legacy Bedrock surface, add a distinct platform key for it ("bedrock_legacy") rather than overloading "bedrock" — the two surfaces take different ID forms for the same model and have separate quotas.

Everyone else: bare IDs

Claude Platform on AWS uses model IDs identical to the first-party Claude API — bare strings, no prefixes, no ARNs — despite also living on AWS. Google Cloud uses bare IDs for the 4.6+ generation with an @date suffix on older models (covered in the Vertex lookup article). Foundry's deployment names default to bare model IDs. So the resolver table above stays small: for current-generation models, only the Bedrock row differs.

Where to go next

See model IDs across platforms for the beginner-level tour, and the provider factory for where the resolver slots into application code.

Sources

• Claude in Amazon Bedrock
• Claude on Amazon Bedrock (legacy)
• Models overview
• Claude Platform on AWS