Where each model is available: API, Bedrock, Vertex, Foundry

Why platform availability is worth checking separately from model choice

A model's price and capability are only part of the decision if you're not deploying through the first-party API directly — a model available on the Claude API is not automatically available, at the same terms or at all, on every cloud-hosted platform Claude models also run on. This table exists because that gap is easy to assume away until a deploy target changes and something that worked in testing stops resolving in production.

Where this bites hardest

The riskiest version of this gap isn't discovering it during initial platform selection — it's discovering it after committing to a platform for unrelated reasons (procurement, existing infrastructure, compliance) and only then finding that a model or capability the integration depends on isn't available there. Check platform-specific availability before committing to a platform, not after, wherever the choice of platform is still open.

What tends to differ across platforms

Beyond raw model availability, capability-level differences also apply per platform — the Batch API specifically is not available on any of the major cloud-hosted platforms, regardless of which model you'd otherwise target through them. See the Batch API isn't available on your platform for exactly this gap in practice.

Fallback chains need the same check as a primary choice

A fallback model chosen purely for availability reasons deserves the same platform-availability check as a primary choice — a fallback that isn't actually reachable on the platform you're deploying to is not a working fallback at all, and that gap only becomes visible the first time the fallback path actually triggers, which tends to be exactly the moment something else has already gone wrong.

Related

See each model's own reference page for its specific platform list, and the Message Batches API, in full for the capability-level gap that applies independent of model choice.