Перейти к содержимому
CLAUDEXIA
enru
МИГРАЦИЯ

Миграция с OpenAI на Claude в 2026: один base_url

Переключитесь с OpenAI на Claude Sonnet 4.5 в проде, поменяв один base_url и имя модели. Плейбук с дифами и подводными камнями.

Если у вас в продакшене работает интеграция с OpenAI и вы прикидываете, сколько труда стоит переезд на Claude, честный ответ: меньше, чем кажется. Для большинства команд миграция — это одна строка изменения base_url и одна строка изменения имени модели. Всё остальное — оценка качества, а не инженерия.

Этот пост — плейбук, по которому мы помогаем командам переезжать с gpt-4o или gpt-4.1 на Claude Sonnet 4.5 через OpenAI-совместимый шлюз Claudexia. Здесь — зачем вообще мигрировать, что реально меняется в коде, где живут тонкие отличия в промптах и как безопасно прогнать A/B перед финальным переключением.

Зачем мигрировать

Три причины повторяются в большинстве реальных миграций:

  1. Экономика длинного контекста. Кэширование промптов в Claude плюс цена за длинный вход обычно выигрывают для агентских циклов, RAG по большим документам и code-ассистентов, которые на каждом шаге шлют один и тот же системный промпт. Как только средний контекст пересекает ~20K токенов с заметным повтором, Sonnet с кэшем сложно обыграть по цене за полезный ответ. (Подробный расчёт — в нашем разборе цен.)
  2. Качество кода и tool use. На реальных задачах по коду и в длинных многошаговых вызовах инструментов Sonnet 4.5 стабильно силён. Если ваш продукт — code-агент, пайплайн извлечения данных или что-то с цепочкой tool calls, разница видна как меньшее число ретраев и меньше эскалаций к человеку.
  3. ROI кэширования промптов. Это самый большой рычаг по стоимости, который команды находят уже после миграции. Стабильный системный промпт плюс стабильная схема инструментов, закэшированные, режут до 80–90% от input-стоимости на горячих путях. У OpenAI есть свой кэш, но явные маркеры кэша у Claude проще понимать и тюнить.

Это не означает, что OpenAI — плохо. Это означает, что Claude теперь адекватный дефолт для большой части нагрузок, а стоимость миграции достаточно мала, чтобы правильное решение чаще всего звучало так: «попробуй обоих, выбери победителя по каждой задаче».

Путь без усилий

Claudexia отдаёт OpenAI-совместимый эндпоинт на https://api.claudexia.tech/v1. Если ваш код уже говорит на OpenAI SDK, трогать ничего, кроме конфигурации, не нужно:

  • Указываете base_url на https://api.claudexia.tech/v1.
  • Меняете OPENAI_API_KEY на ключ Claudexia.
  • Меняете имя модели с gpt-4o (или что у вас) на claude-sonnet-4.5.

Всё. Стриминг, function calling, JSON mode, vision и форма запроса chat completions — работают. Примерно 90% возможностей OpenAI SDK проходят насквозь без изменений. Оставшиеся 10% — то, ради чего стоит дочитать.

Diff на Python

 from openai import OpenAI

 client = OpenAI(
-    api_key=os.environ["OPENAI_API_KEY"],
+    api_key=os.environ["CLAUDEXIA_API_KEY"],
+    base_url="https://api.claudexia.tech/v1",
 )

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

Diff на TypeScript

 import OpenAI from "openai";

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

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

Это весь код-чейндж. Билд, деплой, прогон evals.

Что реально меняется под капотом

Формат на проводе выглядит одинаково, но модель на другой стороне — не GPT. Несколько поведений сдвигаются, и игнорирование этих сдвигов — самая частая причина, почему «drop-in миграция» выглядит хуже, чем должна, в первый день.

Стиль промпта: Claude любит структуру

GPT-модели хорошо переносят рыхлые разговорные системные промпты. Claude вознаграждает структуру. Если ваш системный промпт — это стена из императивных предложений, вы обычно поднимаете качество на 5–15%, заворачивая секции в XML-теги:

<role>Ты старший backend-инженер, ревьюишь pull request.</role>
<rules>
- Отклоняй любые изменения без тестов.
- Отмечай отсутствие обработки ошибок.
</rules>
<output_format>
Верни JSON с полями: verdict, reasons[], suggested_fixes[].
</output_format>

Claude трактует эти теги как мягкую схему и следует им надёжнее, чем свободным заголовкам. Можете не делать — но если сравниваете качество с GPT, сделайте до того, как делать выводы.

Системные сообщения

Оба API принимают сообщение с ролью system. В режиме OpenAI-совместимости Claudexia корректно маппит его в верхнеуровневый параметр system Claude — рефакторить ничего не нужно. Тонкое отличие: Claude строже игнорирует инструкции, противоречащие системному сообщению. Обычно это то, что нужно, но если ваше приложение полагается на возможность пользователя переопределять системную персону посреди диалога, явно проверьте этот сценарий.

Структурированный вывод: response_format и JSON

response_format={"type": "json_object"} работает. И response_format={"type": "json_schema", "json_schema": {...}} — тоже. Под капотом шлюз реализует второе, форсируя ход tool_use против синтетического инструмента, чья input-схема совпадает с вашей JSON-схемой, а потом разворачивает результат. Гарантии те же, что у structured outputs OpenAI, с одним нюансом: ошибки валидации прилетают как несоответствие tool use, а не как отказ модели — это обычно проще дебажить.

Function calling

Массив tools с function-записями у OpenAI чисто маппится в блоки tool_use Claude. Оба направления (модель вызывает инструмент, вы возвращаете сообщение с ролью tool и результатом) работают без правок кода. Если у вас уже отгружен function calling на OpenAI, ждите нулевой diff.

Стриминг

Server-sent events с чанками choices[].delta.content приходят идентично. Если фронт уже рендерит стримы OpenAI — отрендерит и Claude. Без изменений.

Подсчёт токенов и max_tokens

Токенизатор Claude другой, поэтому промпт на 1 200 OpenAI-токенов может быть 1 350 Claude-токенов, или наоборот. Не хардкодьте соотношение «символы → токены». Если у вас есть охранник окна контекста, пересчитайте на новой модели, прежде чем поднимать алерты.

Оцените до того, как переключитесь

Не мигрируйте одним деплоем. Рабочий паттерн:

  1. Зеркальте трафик неделю. Шлите каждый прод-запрос обоим провайдерам. Логируйте ответы. Пользователю Claude пока не показывайте.
  2. Сравните офлайн. Прогоните evals (золотые задачи, LLM-as-judge, точечная человеческая проверка) по парам ответов. Считайте win rate, ничьи, регрессии и стоимость за запрос.
  3. Shadow → canary. Когда Claude выигрывает или сравнивается на ваших метриках — направьте 5% живого трафика, потом 25%, потом 100%. Держите путь на OpenAI прогретым ещё минимум две недели после полного перехода.

Большинство команд находят хотя бы одну задачу, где GPT всё ещё лучше — например, конкретный промпт извлечения, который месяцами тюнили под GPT-4o. Это нормально. Маршрутизируйте по задачам, а не по компании.

Паттерн фолбэка

Даже после полного перехода на Claude держите фолбэк. Безопасный шаблон:

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

В стационарном режиме фолбэк почти не срабатывает, но он держит вас честными насчёт риска одного провайдера и даёт ops единый рубильник, если что-то пойдёт не так.

Итог

Реальное изменение в коде — пять минут: один base_url, одно имя модели, один API-ключ. Неделя работы — это evals, шлифовка промптов и включение кэширования. Сам переезд можно делать в пятницу днём; оценку качества — в рабочее время.

← Ко всем записям