Migrate from OpenAI to Claude with one base_url change

Say you have an OpenAI integration running in production and want to know what it costs to move to Claude. The honest answer: less than you think. For most teams the migration is one new line for base_url and one new line for the model name. The rest is evaluation, not engineering.

This is the playbook we use when we help teams move from gpt-4o or gpt-4.1 deployments to Claude Sonnet 5 through the OpenAI-compatible gateway at codexkey. It covers why teams switch, what changes in the code, where the subtle prompt differences hide, and how to run a safe A/B before the final cutover.

Why switch at all

Three reasons come up in nearly every production migration:

1. Long-context economics. Claude's prompt caching and its price on long inputs tend to win for agent loops, RAG over large documents, and code assistants that resend the same system prompt on every step. Once your average context passes ~20K tokens with plenty of reuse, Sonnet with caching is hard to beat on cost per useful answer. (See our pricing breakdown for the per-token math.)
2. Coding and tool-use quality. On real coding tasks and long multi-step tool use, Sonnet 5 has stayed consistently strong. If your product is a code agent, a structured-extraction pipeline or anything that chains tool calls, the gap shows up as fewer retries and fewer handoffs to a human.
3. Prompt caching ROI. This is the biggest cost lever, and most teams find it only after the move. A stable system prompt plus a stable tool schema, cached, can cut 80-90% of input cost on hot paths. OpenAI has its own caching, but Claude's explicit cache markers are easier to understand and tune.

None of this means OpenAI is a bad choice. Claude has simply become a sensible default for a large share of workloads, and the move is cheap enough that the right call is usually "try both, pick the winner per workload."

The near-zero-change path

codexkey exposes an OpenAI-compatible endpoint at https://api.codexkey.online/v1. If your code already uses the OpenAI SDK, you only touch configuration:

• Set base_url to https://api.codexkey.online/v1.
• Replace OPENAI_API_KEY with your codexkey key.
• Change the model name from gpt-4o (or whatever you run) to claude-sonnet-5.

That is all. Streaming, function calling, JSON mode, vision and the chat-completions request shape work. About 90% of OpenAI SDK features pass through unchanged. The other 10% is the reason to read on.

Python diff

 from openai import OpenAI

 client = OpenAI(
-    api_key=os.environ["OPENAI_API_KEY"],
+    api_key=os.environ["CODEXKEY_API_KEY"],
+    base_url="https://api.codexkey.online/v1",
 )

 response = client.chat.completions.create(
-    model="gpt-4o",
+    model="claude-sonnet-5",
     messages=[
         {"role": "system", "content": SYSTEM_PROMPT},
         {"role": "user", "content": user_input},
     ],
     max_tokens=1024,
 )

TypeScript diff

 import OpenAI from "openai";

 const client = new OpenAI({
-  apiKey: process.env.OPENAI_API_KEY,
+  apiKey: process.env.CODEXKEY_API_KEY,
+  baseURL: "https://api.codexkey.online/v1",
 });

 const response = await client.chat.completions.create({
-  model: "gpt-4o",
+  model: "claude-sonnet-5",
   messages: [
     { role: "system", content: SYSTEM_PROMPT },
     { role: "user", content: userInput },
   ],
   max_tokens: 1024,
 });

That is every code change. Build, deploy, run your evals.

What actually changes underneath

The wire format looks identical, but the model on the other end is not GPT. A few behaviours shift, and ignoring them is the usual reason a "drop-in" migration looks worse than it should on day one.

Prompt style: Claude rewards structure

GPT models put up well with loose, conversational system prompts. Claude pays you back for structure. If your system prompt is a wall of imperative sentences, wrap the sections in XML-style tags and quality usually rises by 5-15%:

<role>You are a senior backend engineer reviewing pull requests.</role>
<rules>
- Reject any change without tests.
- Flag missing error handling.
</rules>
<output_format>
Return JSON with fields: verdict, reasons[], suggested_fixes[].
</output_format>

Claude reads these tags as a soft schema and follows them more reliably than free-form headings. It is optional, but if you are comparing quality against GPT, do it before you draw any conclusions.

System messages

Both APIs accept a system role message. In the OpenAI-compatible mode, codexkey maps it to Claude's top-level system parameter correctly, so there is nothing to refactor. One subtle difference: Claude is stricter about ignoring instructions that contradict the system message. That is usually what you want. If your app lets the user override the system persona mid-chat, test that flow on its own.

Structured outputs: response_format and JSON

response_format={"type": "json_object"} works, and so does response_format={"type": "json_schema", "json_schema": {...}}. The gateway implements the second one by forcing a tool_use turn against a synthetic tool whose input schema matches your JSON schema, then unwrapping the result. The guarantees match OpenAI's structured outputs, with one nuance: validation errors arrive as a tool-use mismatch instead of a refusal, which is usually easier to debug.

Function calling

OpenAI's tools array with function entries maps cleanly onto Claude's tool_use blocks. Both directions work: the model calls a tool, and you send back a tool role message with the result. No code changes. If function calling already runs on OpenAI for you, expect a zero diff here.

Streaming

Server-sent events with choices[].delta.content chunks arrive in the same form. A frontend that renders OpenAI streams will render Claude streams. Nothing to change.

Token counts and max_tokens

Claude uses a different tokenizer, so a prompt of 1 200 OpenAI tokens may come to 1 350 Claude tokens, or the other way round. Do not hard-code a character-to-token ratio. If you have a context-window guard, recount on the new model before you raise any alerts.

Evaluate before you flip

Do not migrate in a single deploy. This pattern works:

1. Mirror traffic for a week. Send every production request to both providers and log the responses. Keep Claude's output away from users for now.
2. Score offline. Run your eval suite (golden tasks, LLM-as-judge, human spot checks) over the paired outputs. Track wins, ties, regressions and cost per request.
3. Shadow, then canary. Once Claude wins or ties on your metrics, route 5% of live traffic to it, then 25%, then 100%. Keep the OpenAI path warm for at least two more weeks after the full cutover.

Most teams find at least one workload where GPT is still better, for example an extraction prompt tuned for months against GPT-4o. That is fine. Route per workload, not per company.

A fallback for failures

Even after you commit to Claude, keep a way back. A safe pattern:

def chat(messages):
    try:
        return claude_client.chat.completions.create(
            model="claude-sonnet-5",
            messages=messages,
            timeout=20,
        )
    except (TimeoutError, APIError):
        return openai_client.chat.completions.create(
            model="gpt-4o",
            messages=messages,
        )

In steady state the fallback rarely fires. It still keeps you honest about single-provider risk and gives ops one switch to flip if something misbehaves.

Bottom line

The code change takes five minutes: one base_url, one model name, one API key. The week of work goes to evals, prompt polish and turning on prompt caching. Do the migration on a Friday afternoon if you like, but run the evaluation on company time.