Google Cloud serves Claude with bare, Anthropic-style model IDs — no anthropic. prefix, that convention is Bedrock-only. But Anthropic's ID table for the platform shows some older models carrying a version-date suffix in @YYYYMMDD form: claude-haiku-4-5@20251001, claude-sonnet-4-5@20250929, claude-opus-4-5@20251101. Current-generation models — Claude Fable 5, Opus 4.8, 4.7, 4.6, Sonnet 5, Sonnet 4.6 — are undated. If your code assumes one form or the other everywhere, one class of model will 404 on you.
Why the split exists
Every Claude model ID is a pinned snapshot. What changed with the Claude 4.6 generation is the naming: starting at 4.6, IDs use a dateless format that is still a pinned snapshot, while pre-4.6 models keep dated identifiers (on the first-party API the dated form is claude-haiku-4-5-20251001, with claude-haiku-4-5 as a convenience alias). Each platform renders that date its own way — Google appends @20251001, Bedrock embeds -20251001-v1:0 — but they are the same snapshot underneath. So the "@date rule" is really the generation rule wearing Google syntax: 4.6 and later, bare; earlier, dated.
One caveat: Google's own usage page also lists short undated names for some older models (e.g. claude-haiku-4-5, claude-3-7-sonnet). Where Anthropic documents the @date form, prefer it — the explicit snapshot is unambiguous, and it matches what the rest of your fleet pins on other platforms.
Where the model ID goes on Vertex
Remember that on Vertex the model is not a body field — it is part of the endpoint URL (.../publishers/anthropic/models/claude-haiku-4-5@20251001:rawPredict). The AnthropicVertex client handles that placement; you still pass the platform-correct string:
from anthropic import AnthropicVertex
client = AnthropicVertex(project_id="my-project", region="global")
msg = client.messages.create(
model="claude-haiku-4-5@20251001", # dated: pre-4.6 model
max_tokens=512,
messages=[{"role": "user", "content": "Hello"}],
)
# current generation is bare on Vertex: model="claude-opus-4-8"The cross-platform lookup table
Combined with Bedrock's prefix rule, you now have every reason to stop constructing IDs in code and start maintaining one table. Rows are canonical (first-party) IDs; columns are platforms; blank cells default to the canonical form:
| Canonical (1P / P-AWS / Foundry) | Amazon Bedrock | Google Cloud |
|---|---|---|
claude-fable-5 | anthropic.claude-fable-5 | claude-fable-5 |
claude-opus-4-8 | anthropic.claude-opus-4-8 | claude-opus-4-8 |
claude-sonnet-5 | anthropic.claude-sonnet-5 | claude-sonnet-5 |
claude-haiku-4-5 | anthropic.claude-haiku-4-5-20251001-v1:0 | claude-haiku-4-5@20251001 |
Practical rules for maintaining it:
- Source it from documentation, not experimentation. Anthropic's models overview publishes the per-platform ID for every model; copy, don't infer.
- Keep it as data (a dict, a YAML file, a database row per model) so a model addition is a reviewable one-line diff, and unit-test that every row resolves on every platform you deploy to.
- Log canonical IDs everywhere. Metrics, cost reports, and evals should never contain platform forms; translate only at the request boundary.
- Track lifecycle per platform. Model retirement dates on Vertex are set by Google (e.g. Fable 5 "not sooner than June 8, 2027"), and Bedrock's schedule is set by AWS — the same canonical model can retire on different dates on different platforms, so the table is also the natural place to annotate end-of-life.
@date suffix is the usual culprit.Where to go next
See the Vertex model ID format guide for the single-platform basics, and the provider factory for where this table plugs into application code.