Run Claude anywhere

1 · One Claude, three front doors essential

You already know the everyday call: build a client, hand it a list of messages, read the reply. What most people don't realize is that the exact same call works whether Claude is served by Anthropic directly, by Amazon Bedrock inside your AWS account, or by Google Vertex AI inside your GCP project. Same model, same Messages API, same response shape — the only thing that changes is which client object you build.

The anthropic Python SDK ships three client classes for exactly this: Anthropic, AnthropicBedrock, and AnthropicVertex. All three are real, first-class classes; all three expose the identical client.messages.create(...) method. Pick the client that matches where you want the request billed and governed — and leave every line about the conversation untouched.

2 · The shape of portability essential

Picture your app calling one client factory. The factory reads a config value and returns the right client; from there a single messages.create lands on whichever provider you chose:

Read it left to right. Your app never names a provider — it calls make_client(). The factory looks at one config value and returns Anthropic(), AnthropicBedrock(...), or AnthropicVertex(...). All three converge on the same messages.create. The branch that picks a provider lives in one function; everything downstream is provider-agnostic.

3 · Recipe 1 — the direct Anthropic API essential

Start with the baseline everyone knows. The direct client reads ANTHROPIC_API_KEY from the environment, so the key never appears in code. Note the model-ID: on the direct API it's the plain, current alias claude-opus-4-8.

direct_api.py# needs: pip install anthropic
# Anthropic: ANTHROPIC_API_KEY in the environment; makes a real API call
from anthropic import Anthropic

client = Anthropic()   # reads ANTHROPIC_API_KEY from the environment

resp = client.messages.create(
    model="claude-opus-4-8",              # direct API: plain model alias
    max_tokens=300,
    system="You are a concise SRE assistant.",
    messages=[{"role": "user", "content": "In one sentence, what is an SLO?"}],
)
print(resp.content[0].text)

4 · Recipe 2 — Amazon Bedrock intermediate

AnthropicBedrock routes the same request through your AWS account. There is no API key — auth is your AWS credentials (an IAM role on Lambda/EC2/ECS, or your local ~/.aws profile), and you must have requested model access to Claude in the Bedrock console for your region. The model-ID takes an anthropic. prefix.

bedrock.py# needs: pip install "anthropic[bedrock]"
# Bedrock: AWS creds (IAM role / ~/.aws profile) + Bedrock model access; real API call
from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")   # no API key — uses AWS creds

resp = client.messages.create(
    model="anthropic.claude-opus-4-8",    # Bedrock: anthropic. prefix on the id
    max_tokens=300,
    system="You are a concise SRE assistant.",
    messages=[{"role": "user", "content": "In one sentence, what is an SLO?"}],
)
print(resp.content[0].text)

5 · Recipe 3 — Google Vertex AI intermediate

AnthropicVertex routes the request through your GCP project. Auth is Google Application Default Credentials (ADC) — run gcloud auth application-default login locally, or use the attached service account on GCP compute. You pass a project_id and a region. The model-ID for current-generation models is the bare alias (no prefix).

vertex.py# needs: pip install "anthropic[vertex]"
# Vertex: gcloud ADC + a GCP project with the Vertex AI API enabled; real API call
from anthropic import AnthropicVertex

client = AnthropicVertex(project_id="my-gcp-project", region="us-east5")

resp = client.messages.create(
    model="claude-opus-4-8",              # Vertex: bare id (dated snapshots use @date)
    max_tokens=300,
    system="You are a concise SRE assistant.",
    messages=[{"role": "user", "content": "In one sentence, what is an SLO?"}],
)
print(resp.content[0].text)

Put the three recipes side by side and the pattern jumps out: lines 3–4 (the import and the client) and the model string are the only differences. The messages.create(...) block — max_tokens, system, messages — is copy-pasted verbatim across all three.

6 · Auth & model-IDs at a glance advanced

Everything that differs between the three doors fits in one table. Learn this and the rest is muscle memory:

The bottom row is the payoff. The request body — system prompt, messages, tools, streaming, prompt caching, structured output — is the same object on every provider. The top four rows are the only per-provider knobs, and a factory can set all of them from one config value.

7 · The mapper (this one runs offline) professional

Before wiring a live factory, encode the per-provider differences in a tiny, testable function. The helper below is pure stdlib and runs with a plain python file.py — no keys, no network. Given a logical model name and a provider, it returns the right client class name and the correctly-formatted model-ID, so the naming rules live in one auditable place.

pick_provider.pydef pick_provider(provider, logical_model="opus"):
    """Map (provider, logical_model) -> the client class name + provider-specific
    model-id string. Pure stdlib: no SDK, no network. Encapsulates the naming rules
    so no other code has to remember the anthropic. prefix or the bare-alias quirk."""
    base = {"opus": "claude-opus-4-8", "haiku": "claude-haiku-4-5"}[logical_model]
    table = {
        # provider  -> (client class,        model-id transform)
        "api":     ("Anthropic",        base),
        "bedrock": ("AnthropicBedrock",  "anthropic." + base),   # Bedrock: prefix
        "vertex":  ("AnthropicVertex",   base),                  # Vertex: bare alias
    }
    client_class, model_id = table[provider]
    return {"client_class": client_class, "model_id": model_id}

for prov in ["api", "bedrock", "vertex"]:
    r = pick_provider(prov, "opus")
    print(f"{prov:8} {r['client_class']:18} model_id={r['model_id']}")

api      Anthropic          model_id=claude-opus-4-8
bedrock  AnthropicBedrock   model_id=anthropic.claude-opus-4-8
vertex   AnthropicVertex    model_id=claude-opus-4-8

8 · Why teams pick each door professional

Portability is only useful if you know why you'd move. The choice is almost never about the model — it's identical — and almost always about compliance, existing cloud commitments, and latency:

A useful rule of thumb: if you already live in AWS or GCP, use the matching door so AI spend, identity, and data stay in the cloud you already trust and audit. If you have no such constraint, the direct API is the simplest path and the first to get new capabilities.

9 · Feature availability & lag advanced

The models are the same, but not every API feature ships on every provider at the same time. New capabilities land on the direct Anthropic API first and reach the cloud providers on their own schedule. A few concrete gaps worth knowing before you commit a workload:

The core — messages, streaming, tools, caching, thinking — is everywhere, so portability is real for the vast majority of apps. The gaps are in the newer, peripheral surfaces (Batches, Files, some server-side tools). Check availability for the specific features your workload needs before you assume a provider is a drop-in swap.

10 · Tech-lead — the provider-agnostic wrapper tech-lead

A lead's job is to make provider choice a configuration decision, not a code decision. The pattern: one factory that turns a config value into the right client, so business logic calls messages.create and never learns which door it went through. Here is the shape — the client construction is real SDK; treat it as the template you'd wire into a real app.

make_client.py# needs: pip install "anthropic[bedrock,vertex]"
# Anthropic: ANTHROPIC_API_KEY | Bedrock: AWS creds + model access | Vertex: gcloud ADC
import os
from anthropic import Anthropic, AnthropicBedrock, AnthropicVertex

def make_client(provider):
    """Return the right client for the configured provider. The ONLY provider-aware
    code in the app — everything downstream calls client.messages.create unchanged."""
    if provider == "api":
        return Anthropic()                                    # ANTHROPIC_API_KEY
    if provider == "bedrock":
        return AnthropicBedrock(aws_region=os.environ["AWS_REGION"])
    if provider == "vertex":
        return AnthropicVertex(project_id=os.environ["GCP_PROJECT"],
                               region=os.environ["GCP_REGION"])
    raise ValueError(f"unknown provider: {provider}")

# ONE config value decides the provider; the model-id comes from the offline mapper.
provider = os.environ.get("LLM_PROVIDER", "api")
client = make_client(provider)
model_id = pick_provider(provider, "opus")["model_id"]   # from section 7

resp = client.messages.create(              # <-- identical on every provider
    model=model_id,
    max_tokens=300,
    system="You are a concise SRE assistant.",
    messages=[{"role": "user", "content": "In one sentence, what is an SLO?"}],
)
print(resp.content[0].text)

Notice how the provider-aware surface has shrunk to two functions: make_client (which client) and pick_provider (which model-ID). The messages.create call is provider-blind. To move a workload from the direct API to Bedrock for a compliance review, you change one environment variable — LLM_PROVIDER=bedrock — and ship. No business logic changes, no prompt changes, no rewrite.

Tech-lead checklist for a portable Claude integration

1. One factory, one config value. All provider selection lives in make_client(provider), driven by a single env var / config key. No other module imports AnthropicBedrock or AnthropicVertex.
2. Centralize model-IDs. Never hard-code anthropic.claude-… at a call site — go through the mapper so the prefix rule and alias choices live in one place.
3. Feature-gate on availability. If a code path uses Batches or Files, it isn't portable to Bedrock/Vertex — guard it and fail loudly rather than 404 at runtime.
4. Auth per environment, not in code. Direct = key from env; Bedrock = IAM role on the compute; Vertex = ADC / service account. Keep secrets out of the codebase on every door.
5. Test the swap. Run your smoke test against each provider you support in CI (or a scheduled job) so a provider-specific regression is caught before a customer hits it.

import anthropic

client = anthropic.Anthropic()          # reads ANTHROPIC_API_KEY
resp = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=256,
    messages=[{"role": "user", "content": "Say hello in one short sentence."}],
)
print(resp.content[0].text)

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")   # uses IAM creds
resp = client.messages.create(
    model="anthropic.claude-sonnet-4-6",            # note the anthropic. prefix
    max_tokens=256,
    messages=[{"role": "user", "content": "Say hello in one short sentence."}],
)
print(resp.content[0].text)

def pick_provider(provider, logical_model):
    table = {
        "direct":  ("Anthropic",        logical_model),
        "bedrock": ("AnthropicBedrock", f"anthropic.{logical_model}"),
        "vertex":  ("AnthropicVertex", logical_model),
    }
    if provider not in table:
        raise ValueError(f"unknown provider: {provider}")
    return table[provider]

for p in ("direct", "bedrock", "vertex"):
    print(p, pick_provider(p, "claude-sonnet-4-6"))
# bedrock -> ('AnthropicBedrock', 'anthropic.claude-sonnet-4-6')

def make_client(provider, **kw):
    import anthropic
    if provider == "direct":
        return anthropic.Anthropic(**kw)
    if provider == "bedrock":
        return anthropic.AnthropicBedrock(**kw)
    if provider == "vertex":
        return anthropic.AnthropicVertex(**kw)
    raise ValueError(provider)

def model_id(provider, logical):
    return f"anthropic.{logical}" if provider == "bedrock" else logical

# offline sanity check of the routing (no SDK needed):
assert model_id("bedrock", "claude-sonnet-4-6") == "anthropic.claude-sonnet-4-6"
assert model_id("direct",  "claude-sonnet-4-6") == "claude-sonnet-4-6"
print("routing ok")

import os

PROVIDER = os.environ.get("LLM_PROVIDER", "direct")
LOGICAL  = "claude-sonnet-4-6"

def model_id(provider, logical):
    return f"anthropic.{logical}" if provider == "bedrock" else logical

def ask(client, prompt):                       # provider-blind
    return client.messages.create(
        model=model_id(PROVIDER, LOGICAL),
        max_tokens=256,
        messages=[{"role": "user", "content": prompt}],
    )

for env in ("direct", "bedrock", "vertex"):    # simulate the flag flip
    print(env, "->", model_id(env, LOGICAL))

FEATURES = {                       # feature -> providers that support it
    "messages": {"direct", "bedrock", "vertex"},
    "streaming": {"direct", "bedrock", "vertex"},
    "tools": {"direct", "bedrock", "vertex"},
    "batches": {"direct"},          # not on Bedrock/Vertex
    "files":   {"direct"},
}

def preflight(target, needed):
    blockers = [f for f in needed if target not in FEATURES.get(f, set())]
    return {"can_move": not blockers, "target": target, "blockers": blockers}

job = ["messages", "streaming", "batches"]
r = preflight("bedrock", job)
print(r)   # can_move False, blockers ['batches']
if not r["can_move"]:
    print("Refactor these off before cutover:", r["blockers"])

Knowledge check check yourself