Привет, Хабр! На связи команда Рег.облака. С начала октября у российских пользователей Claude снова начали блокироваться аккаунты. Для тех, кто пользуется моделью время от времени через браузер, потеря доступа неприятна, но не катастрофична. Гораздо сложнее ситуация у команд, которые уже встроили Claude в рабочие процессы. Например, подключили через API к внутреннему боту, coding-agent, RAG или автоматической обработке документов.

В таком случае внезапно пропадает уже не просто доступ к чату. Перестает работать кусок системы, который мог месяцами спокойно жить в проде. И тут выясняется, насколько глубоко конкретная модель успела встроиться в код и есть ли вообще запасной вариант.

Мы решили посмотреть на эту историю именно с этой стороны: что происходит, когда один зарубежный сервис становится слишком важной частью рабочего процесса, и как заранее подготовить переход к работе через API, чтобы перенос настроек и контекста не превратился в отдельный проект на несколько недель. А заодно покажем, как мы решаем эту задачу в ИИ-платформе Рег.облака, где несколько моделей доступны через единый API.

Навигация по тексту:

• Где в продукте прячется зависимость от модели и программы для работы с ней

• Почему перейти с Claude на решение через API не всегда просто

• Как сделать модель заменяемой частью стека

• Один API вместо привязки к одному вендору

• Запасная модель должна быть проверенной

• Когда проще поднять свою модель

• Что проверить у себя уже сейчас

Где в продукте прячется зависимость от модели и программы для работы с ней

Самое очевидное место — SDK и endpoint Anthropic, но обычно этим дело не заканчивается. Если команда пользуется готовым помощником, например Claude Code, нужные данные лежат локально: агент загружает инструкции, подключает инструменты, управляет доступом к файлам и сохраняет сведения о работе. При переходе на другого агента эти настройки тоже нужно перенести.

Допустим, команда несколько месяцев делает внутреннего агента. За это время под Claude успели поправить системный промпт, создать свои тулы, добиться стабильных ответов и научиться обрабатывать типичные ошибки. Формально в коде по-прежнему происходит API-вызов к LLM. Фактически продукт уже знает довольно много о поведении именно этой модели.

Есть и менее очевидные места. Например, когда Claude используется в редакторе кода, через API во внутреннем сервисе или в сценариях n8n, которые кто-то собрал полгода назад и почти забыл. Это три разных способа подключения. Они могут зависеть от одного поставщика, но отказ одного способа доступа не обязательно отключит остальные.

Первое действие при вынужденной миграции — найти все места, где Claude вообще используется. Это не только production-код, но и CI/CD, внутренние скрипты, автоматизации, агенты, IDE, боты и сервисные аккаунты.

Отдельно стоит сохранить то, что понадобится при переезде: ваши промпты, готовые сценарии работы, описания инструментов и настройки подключений, набор тестовых запросов и ожидаемые форматы ответа. Если меняется сам агент, то понадобятся также история переписки, заметки и сведения о проектах. Часть сценариев можно перенести напрямую, если новая агентная платформа поддерживает такой же формат, остальные настройки нужно адаптировать. Если часть нужных сведений существует только внутри веб-интерфейса, миграция становится сложнее.

Почему перейти с Claude на решение через API не всегда просто

На уровне простого запроса все выглядит легко: была одна модель — указали другую — получили текст. Для части задач именно так и будет, если агент уже совместим с OpenAI API. Но при переходе с Claude или Claude Code в другую агентную платформу меняется и рабочая среда. Нужно адаптировать и перенести все настройки, инструкции, сценарии, подключения к инструментам и накопленные сведения о проектах. Скорее всего, историю переписки нельзя будет просто «подложить» новому агенту.

Еще трудности начинаются там, где от модели ждут не просто хорошего ответа человеку, а довольно конкретного поведения внутри программы. Представим, что агент получает заявку пользователя, решает, нужен ли поиск, вызывает один из внутренних инструментов и в конце должен вернуть JSON заданной структуры. Допустим, в вашей программе выбранная модель Claude с этим сценарием работала стабильно. Вы меняете модель или переносите сценарий в другую программу с доступом через API. Новая модель тоже хорошо понимает заявку, но при свободном выборе действий пытается ответить без инструмента, а в ином случае меняет порядок вызовов инструментов.

Если формат задан только текстовой инструкцией, модель может добавить пояснение вокруг JSON. Когда API поддерживает строго заданную схему ответа, формат можно ограничить технически. Такую возможность нужно отдельно проверить у выбранной модели и поставщика. При этом заданный формат еще не гарантирует правильного ответа. Если порядок действий обязателен, его стоит описать как Skill-инструкцию. Это же касается и длинного контекста. Номинально две модели могут поддерживать одинаковое окно контекста, но это не означает, что модель не начнет забывать факты и инструкции на длинных запросах.

Важны еще скорость, лимиты, мультимодальность, цены, особенности reasoning и работа с русским языком. Поэтому одного рейтинга модели в сравнительных испытаниях недостаточно, чтобы оценить, сможет ли она заменить Claude именно в вашем сервисе. А если меняется и сама агентная обвязка, то нужно проверить весь рабочий процесс после переноса.

Как сделать модель заменяемой частью стека

Чтобы упростить смену модели, нужно собрать всё, что отвечает за подключение к ней, в отдельный слой. Основная логика приложения будет передавать задачу внутреннему клиенту, в котором уже прописаны endpoint, API key, model ID, timeout и другие настройки модели. Там же удобно держать retry и обработку ошибок. Это обычная абстракция над внешним сервисом, ничего специфически «ИИ-шного» в ней нет.

Промпты тоже не рекомендуется оставлять разбросанными по коду. Особенно если они уже стали важной частью поведения продукта. Их проще версионировать отдельно вместе со схемами ответа и инструментами. Тогда переключение модели хотя бы имеет понятные границы: видно, какую часть системы придется проверить. Но слово «проверить» здесь ключевое. Абстракция API избавляет от необходимости переписывания интеграции, а не от различий между моделями.

Один API вместо привязки к одному вендору

Если моделей несколько, можно самостоятельно поддерживать интеграцию с каждым поставщиком: отдельные ключи, SDK, форматы запросов, ограничения и обработку ошибок. Пока в стеке одна-две LLM — это терпимо. Когда команда начинает регулярно сравнивать модели или распределять между ними разные задачи, такой слой быстро обрастает своим кодом.

В ИИ-платформе Рег.облака этот слой уже собран. Через единый OpenAI-совместимый интерфейс доступны более 40 моделей. Для приложения точка входа остается одной, а конкретную LLM можно выбирать под задачу. Отдельно подключаться к каждому разработчику модели и заводить у него пользовательский аккаунт или API-доступ не нужно.

Это особенно удобно, когда нужно проверить альтернативу. Например, часть запросов сейчас обрабатывает одна модель. Команда берет тот же набор задач, прогоняет его на другой и сравнивает качество, скорость и стоимость. Если приложение уже использует этот API и новая модель поддерживает нужные функции, переключение обычно не требует заново собирать всю интеграцию. При первом переходе с API Anthropic на интерфейс в формате OpenAI нужно будет выполнить подготовительные работы, о которых рассказали выше.

При этом общий API не делает разные модели одинаковыми. Если приложение сильно зависит от tool calling, structured output или конкретного поведения на длинном контексте, новую LLM все равно придется прогнать на своих сценариях. Здесь единый интерфейс упрощает подключение следующей модели, но не гарантирует поддержку всех ее возможностей и не отменяет проверку рабочего процесса.

Но единый API сам по себе не снимает риск того, что доступ к отдельной модели или внешнему провайдеру когда-нибудь изменится. В этом случае можно запускать модели в контуре, который команда контролирует самостоятельно. Это уже отдельная инфраструктурная задача, для которой нужны GPU, runtime, мониторинг, обновления и команда, которая все это будет поддерживать. Поэтому для многих компаний удобнее не разворачивать свой стек с нуля, а использовать модели, которые уже работают внутри инфраструктуры доверенного провайдера.

В ИИ-платформе Рег.облака часть моделей уже работает внутри нашей GPU-инфраструктуры. Недавно часть собственного инференса мы перенесли на NVIDIA B300. Запросы к этим моделям не отправляются внешним AI-провайдерам и не уходят за пределы инфраструктуры. Поэтому здесь уже нет зависимости от пользовательского аккаунта зарубежного сервиса и его региональных ограничений.

Запасная модель должна быть проверенной

Выбрать «на всякий случай еще одну хорошую LLM» недостаточно. В момент, когда основная модель перестала отвечать, выяснять, умеет ли запасная нормально работать с вашими инструментами и поддерживает ли нужный способ задания формата ответа, уже поздно.

Проще заранее собрать небольшой набор задач: например, двадцать реальных запросов к агенту, несколько длинных документов, реальные tool calls и примеры ответов, где особенно важен формат. Это поможет выявить очевидные проблемы, но не гарантирует обнаружения большинства ошибок. Объем проверок зависит от разнообразия задач и требований к надежности.

Смотреть при этом стоит не только на качество текста. Для одного сервиса критично, чтобы модель всегда возвращала объект по схеме, для другого — правильно выбирала инструмент, для третьего — не проседала на большом контексте. Плюс остаются вполне базовые моменты: сколько времени занимает ответ и сколько такой запрос стоит.

После такого прогона у команды появляется понятный сценарий переключения. Если доступ к первой модели пропадет, начинать сравнение с нуля уже не придется. Единый API упрощает переход между моделями, но сохраняет зависимость от самой платформы.

Когда проще поднять свою модель

Некоторым проектам этого вполне достаточно, но не всем. Самостоятельный запуск имеет смысл, если данные не должны уходить из определенного контура, нужна фиксированная версия модели или от LLM зависит критичный внутренний процесс. Тогда работа уже развернутой модели не зависит от доступа к зарубежному сервису ее разработчика. Но остаются условия лицензии, доступность оборудования и зависимость от выбранной инфраструктуры, а также появляется десяток эксплуатационных задач.

Нужно выбрать GPU, разместить веса, настроить инференс, следить за памятью и latency, обновлять модель и думать о масштабировании. Поэтому self-hosting не является автоматически «более правильным» вариантом. Это просто другой подход, когда требуется больше контроля. В Рег.облаке оба варианта существуют рядом. Можно использовать готовые модели по токенам либо взять GPU-инфраструктуру и развернуть собственный инференс.

Что проверить у себя уже сейчас

Если Claude уже встроен в рабочий процесс, полезно хотя бы один раз пройтись по всей цепочке и понять, что именно произойдет при его недоступности. Не обязательно сразу переделывать архитектуру — для начала достаточно найти слабые места и понять, где замена модели потребует больше всего ручной работы.

Чек-лист с основными действиями:

• Понять, где используется Claude. Не только в основном продукте, но и во внутренних ботах, IDE, скриптах, автоматизациях, CI/CD и агентных сценариях.

• Проверить, где лежат инструкции, готовые сценарии, настройки инструментов и сведения о проектах. Что можно сохранить отдельно от внешнего сервиса и перенести в новую программу.

• Какая программа будет работать через новый API. Поддерживает ли она его формат и нужные функции? Можно ли перенести в нее доступную переписку и настройки прежнего помощника?

• Насколько код зависит от конкретной модели. Есть ли логика под ее tool calling, structured output, контекстное окно или особенности формата ответа.

• Есть ли запасная модель и, если нужен переезд, подготовленный помощник для работы через API. Проверен ли весь сценарий на реальных задачах.

• Что именно проверяли на замене. Формат ответа, вызов инструментов, длинный контекст, качество на русском, скорость и стоимость.

• Что произойдет при отказе. Сервис переключится на другую модель, отключит часть функций или просто начнет возвращать ошибки.

• Сколько времени займет переключение. Если ответ на этот вопрос сейчас неизвестен, это уже хороший повод отдельно проверить сценарий миграции.