Why Model IDs Differ Across Platforms

Every Claude request names its model with an ID string like claude-sonnet-5. Get it right and everything works; get it subtly wrong and you get a model-not-found error — often in the middle of a migration, demo, or on-call incident. The rule that governs these IDs across platforms is mercifully short, but teams trip over it constantly because it is asymmetric: three platforms agree, and one does not.

The rule in one sentence

Amazon Bedrock prefixes every Claude model ID with anthropic.; every other platform — Google Vertex AI, Microsoft Foundry, Claude Platform on AWS, and the first-party API — uses the bare ID.

Why the prefix? Bedrock is a multi-vendor catalog — it serves models from several providers, so its IDs carry a namespace identifying whose model you mean. The other platforms hand you a dedicated Anthropic client, so the namespace would be redundant and the first-party ID is used as-is. Neither spelling changes what you get: anthropic.claude-sonnet-5 on Bedrock and claude-sonnet-5 on Vertex AI are the same Claude Sonnet 5.

How this bites in practice

Copy-paste across platforms. An engineer lifts working Bedrock code into a Vertex project (or vice versa) and the model ID travels with it. The code looks correct, the client authenticates fine, and the request fails only at call time with an unrecognized-model error. Migrations between clouds hit this on day one, reliably.

Hardcoded IDs scattered through a codebase. If the model string appears in fourteen files, a platform switch means fourteen edits and, in practice, thirteen. The fix is the same discipline you already apply to database connection strings: define the ID once, in configuration.

Documentation mixing. Blog posts and internal wikis quote whichever spelling their author used. When an example fails, check the ID format against the platform before debugging anything deeper — it is the cheapest check available.

The pattern that makes it a non-issue

Treat the model ID as per-platform configuration, resolved in exactly one place:

MODEL_IDS = {
    "bedrock":             "anthropic.claude-sonnet-5",
    "vertex":              "claude-sonnet-5",
    "foundry":             "claude-sonnet-5",
    "claude_platform_aws": "claude-sonnet-5",
}

def model_for(platform: str) -> str:
    return MODEL_IDS[platform]

Your application code asks for "the Sonnet tier" and the mapping supplies the right spelling for the platform in play. Combined with the fact that all platforms share the same official anthropic SDK — differing only in client class and credentials — this single table is most of what "multi-platform support" actually requires. Everything downstream of the client and the model string is identical code.

The mapping approach earns its keep beyond correctness. It gives you one audited place where model choices live, which is exactly what a change-review process wants to see; it makes tier changes (say, moving a workload from Sonnet to Haiku) a one-line configuration change rather than a code hunt; and it means a future platform migration starts from a known-complete inventory of every model reference in the system. Teams that skip it invariably rebuild it later, after the second grep-driven migration weekend.

If you operate on multiple platforms simultaneously, add one cheap test to your suite: assert that every ID in the mapping matches the expected format for its platform — prefixed for Bedrock, bare for the rest. It runs in milliseconds and converts this entire class of runtime failure into a build-time failure.

One habit for the team wiki

Write the rule into your internal engineering docs exactly once, next to your standard client-setup snippet, and link it from your migration checklist. It is a thirty-second read that removes a recurring class of "the model is broken" tickets — which, on inspection, are never about the model.

Where to go next

See what the IDs actually name in the model lineup explained, and the full porting checklist in switching clouds. The models section of the main guide keeps the current ID table.