Calling Claude, GPT and Gemini Through OpenAI-Compatible Endpoints

Both Anthropic and Google now offer OpenAI-compatible endpoints, so pointing existing OpenAI SDK code at Claude or Gemini is a matter of changing a few lines instead of rewriting an integration. The hard part is not the first request; it is knowing which features each compatibility layer quietly ignores, and what it costs to maintain several of them side by side. Below you will find the exact client setup for each provider, the documented gaps that matter for production agents, and the trade-offs of collapsing all three behind a single base URL and key.

What "OpenAI-compatible" actually promises

An OpenAI-compatible API is any endpoint that accepts the request format the OpenAI SDK sends: a messages array, the same streaming flags and the same tool-calling schema. Because that format became the de facto standard years ago, most model vendors now expose some version of it, so teams can try a different model without replacing their client code.

Compatible does not mean identical, though. The request shape on the wire matches, but the semantics behind individual parameters can differ, and unsupported options are often accepted and then ignored rather than rejected. That second behavior is what makes these layers risky: nothing fails loudly, so a missing feature surfaces as degraded output instead of an error.

Anthropic's compatibility layer

Anthropic's OpenAI SDK compatibility documentation positions the layer as a way to test and compare model capabilities, not as the recommended production path. It also lists concrete limitations:

• The strict flag for function calling is ignored, so tool-call JSON is not guaranteed to conform to the schema you supplied.
• Prompt caching is not available through the compatibility layer, even though the native Anthropic API supports it.
• All system and developer messages are merged into one system message at the start of the conversation, because Claude accepts only a single initial system prompt.

None of these will trip up a quick experiment. Each of them can break a production agent that depends on tool arguments matching a schema, on caching to keep latency and cost under control, or on system instructions injected mid-conversation.

Google's compatibility layer

Google's side is more complete out of the box. According to its Gemini documentation on OpenAI compatibility, standard chat completions, streaming and function calling all work. Google is equally clear, however, that not every provider-specific option translates between the two APIs, and it recommends switching to the native Gemini API as soon as you need a Gemini-specific capability.

The cost of running all of them

On its own, each layer is a sensible stopgap for evaluating one model. Put all three providers into one application and the overhead multiplies: three base URLs, three API keys, three billing dashboards, three sets of rate limits and three different lists of parameters that are silently dropped, all to support code that looks the same for every provider.

Pointing the OpenAI SDK at Claude

Switching an OpenAI SDK integration to Claude takes three changes: the base URL, an Anthropic API key instead of an OpenAI key, and a Claude model name. That makes it the quickest way to evaluate Claude before committing to Anthropic's native SDK. The imports stay the same:

import os
from openai import OpenAI

The client is constructed with Anthropic's endpoint and a key read from the environment, and the call itself is a standard chat completion. Note that the snippet as printed is missing a line break between the closing parenthesis of the client and response =; split them into two statements when you copy it:

client = OpenAI(
    api_key=os.environ.get("ANTHROPIC_API_KEY"),
    base_url="https://api.anthropic.com/v1/",
)response = client.chat.completions.create(
    model="claude-opus-5",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

For a basic chat completion, that is the entire migration. Anything that relies on the gaps listed above needs more care. If your application depends on strict tool schemas, on prompt caching, or on the full extended thinking output, use Anthropic's native API to get the complete feature rather than its OpenAI-shaped approximation. Model names such as the one shown change frequently, so confirm the current identifier in the provider's model list.

Pointing the OpenAI SDK at Gemini

The Gemini version of the same swap targets Google's endpoint. You need a Gemini API key, which you can create in Google AI Studio. Again, only the standard OpenAI import is required:

from openai import OpenAI

The client takes the Gemini key and Google's OpenAI-compatible base URL; the request body is unchanged. The same missing line break appears here, and the hard-coded key placeholder is better replaced by an environment variable, as in the Claude example:

client = OpenAI(
    api_key="YOUR_GEMINI_API_KEY",
    base_url="https://generativelanguage.googleapis.com/v1beta/openai/",
)response = client.chat.completions.create(
    model="gemini-3.7-flash",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

Streaming and function calling both work through this endpoint. Gemini's reasoning controls are exposed through OpenAI's reasoning_effort parameter, but the mapping is not always an exact equivalent and depends on which Gemini model you call. If you want a new Gemini-only feature as soon as it ships, the native SDK remains the faster route.

What about GPT itself?

OpenAI's own API needs no compatibility layer, because it defines the format everyone else imitates. That does not solve the multi-provider problem, it just moves it. Code written against OpenAI's format makes it easier to add Anthropic's and Google's layers later, but you still end up holding separate keys, separate rate limits and separate quirks for each provider.

Routing every model through one gateway

None of the providers' own layers addresses the multi-provider case, since each only routes to its own models. An LLM gateway fills that gap: a single OpenAI-compatible endpoint that forwards requests to Claude, GPT or Gemini depending on the model you name, so your code no longer needs to track which quirks belong to which provider.

The migration looks exactly like the previous two. The example below uses one commercial gateway's endpoint; the same pattern applies to any OpenAI-compatible gateway. The import is unchanged:

from openai import OpenAI

The client now points at the gateway's base URL with a gateway key, and the model name selects the upstream provider. As before, add a line break before response =:

client = OpenAI(
    api_key="YOUR_SAYGM_API_KEY",
    base_url="https://api.saygm.com/v1",
)response = client.chat.completions.create(
    model="claude-opus-5",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

Changing model to gpt-5.6-luna or gemini-3.7-flash is the only edit needed to switch providers; everything else stays as it is. Treat these model names as examples valid at the time of writing, and check the gateway's model catalog for current identifiers. The same single configuration works in developer tools that already read OpenAI-compatible settings, such as Cursor, Cline, Claude Code and the Vercel AI SDK: one base URL and one key expose every model the gateway offers rather than a single provider's lineup. Each tool has its own field names for the base URL and key, so consult the gateway's integration docs for the exact settings.

What a gateway does not change

Routing through a gateway does not lift the limits of the underlying provider's compatibility behavior. Sending Claude requests in OpenAI format through a gateway still does not give you prompt caching or enforced strict schemas; every limitation documented above continues to apply.

Gateways also become part of your trust boundary, because every prompt and response passes through them. Some vendors advertise confidentiality measures, for example running request handling inside hardware-attested trusted execution environments so the gateway operator cannot read traffic. Such guarantees concern the gateway only; the model provider still receives and processes your request under its own terms. Evaluate both layers separately, and verify any attestation claims against the vendor's technical documentation rather than its marketing.

Common migration questions

Do Claude- or Gemini-specific features survive an OpenAI-compatible layer?

Only the features that layer maps. Whether you call a provider's own compatibility endpoint or route through a gateway, anything it does not translate is lost. On Claude that includes prompt caching, PDF processing and the complete extended thinking output; on Gemini it includes model-specific reasoning parameters. If you depend on those, call the native API for those code paths.

What does it cost to switch?

With a gateway you typically pay per token, much as you would when calling a provider directly, but rates vary by model and by vendor, and some gateways add a margin. Check the current published pricing for the specific model before moving production traffic.

What happens when a provider has an outage?

This is the strongest argument for a single endpoint. A gateway built for failover can reroute to a fallback model without any change in application code, whereas three direct integrations each need their own retry and fallback logic. Keep in mind that a fallback model is a different model: prompts tuned for Claude may behave differently on Gemini, and tool-calling reliability varies. Test your critical prompts against every model in the fallback chain before relying on automatic failover.

Choosing a migration path

• Evaluating one extra provider: use that provider's own OpenAI-compatible endpoint. That is exactly what it is designed for, and the setup is a three-line change.
• Running two or three providers in production: consider a gateway, because it removes the duplicated keys, dashboards and rate-limit handling, and centralizes failover.
• Depending on provider-specific features: keep native SDK calls for those paths, whichever option you choose for everything else.

Whichever route you take, keep the base URL, key and model name in configuration rather than code, and add integration tests for the behaviors your application relies on, such as tool-call schema adherence. That way a silent parameter drop shows up as a failing test instead of a production incident.

Key takeaways

• OpenAI-compatible endpoints match the request shape, not every behavior; unsupported parameters are often ignored without an error.
• Anthropic's layer ignores strict tool schemas, lacks prompt caching and merges system messages, and is documented as a testing path.
• Gemini's layer covers chat, streaming and function calling well, but provider-specific options still need the native API.
• A single gateway simplifies keys, billing and failover across providers, but it inherits every compatibility limit and adds a party to your trust boundary.