If your code is written against the OpenAI SDK, switching providers is usually one line. Here is what changes and what does not.
What changes
Only the base and the key:
from openai import OpenAI
client = OpenAI(
base_url="https://api.claudexia.tech/v1",
api_key="sk_cdx_your_key",
)
Everything else stays: methods, message structure, stream handling, response parsing.
What does not change
The role-based message format, parameters like temperature and max tokens, streaming over server-sent events, the response shape with its choices array. Libraries written against OpenAI keep working.
Where it usually breaks
Model names. Identifiers differ between providers. This is the most common failure on migration and it always produces a clear 400.
Parameters that do not exist. Some provider-specific fields are not universally supported. If you used something exotic, check it separately.
A hardcoded domain. Sometimes the base sits in the code rather than in config, in several places. Grep the project for api.openai.com before celebrating.
A two-minute check
The fastest way to confirm connectivity:
curl https://api.claudexia.tech/v1/chat/completions \
-H "Authorization: Bearer $KEY" \
-H "Content-Type: application/json" \
-d '{"model":"claude-sonnet-4.6","messages":[{"role":"user","content":"say ok"}]}'
If a response comes back, anything remaining will be model names or provider-specific parameters.
Why this matters when choosing a provider
Compatibility is not only about migrating to someone, it is about being able to leave. A provider that forces a rewrite into its own format binds you by switching cost rather than by quality.
We keep both formats on one endpoint, Anthropic Messages and OpenAI Chat Completions, for exactly that reason. Code written against us works elsewhere.
In short
Change the base and the key, then check model names. If the code used a standard SDK, migration takes minutes rather than a sprint.