Claude и GPT легли в один день. Теперь я держу клиентов на мультимодельке, вот как это выглядит

13 апреля, вторник, 17:52 мск. Жопа.

У меня в телеге одновременно горит три чата с клиентами. В одном CRM-помощник перестал отвечать менеджерам на звонки. В другом воронка квалификации лидов в WhatsApp висит 502-ми. В третьем человек пишет "ваш агент опять тупит, уже два часа" и скидывает скрин белого экрана.

Я сначала думал: ну, кривой деплой, щас откачу. Нет. status.anthropic.com светит красным, Claude Sonnet возвращает 529. Открываю status.openai.com, а там тоже веселуха, GPT-5 лежит не то чтобы насмерть, но 40% запросов с ошибками. Сбой в сбое.

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

Посмотрел я статус-страницы за апрель. Разложил по датам:

Это только Claude, только за три недели. GPT в это же время словил свой 15-е апреля и ещё два локальных сбоя помельче. Gemini падал 11-го. Всё по расписанию.

У Anthropic в SLA API написано 99.5% аптайма. В месяц это 3 часа 39 минут легального простоя, за которые они ничего не должны. Для внутреннего тула, которым пользуются десять разрабов, это нормально. Для бота, который отвечает клиентам в рабочее время, это катастрофа - потому что простой случается именно когда нагрузка пиковая, это закон.

Первое что тебе скажет любой чувак в любом чате - обернуть запрос в try/except и вызывать GPT, если Claude упал. Три строки кода, готово, едем дальше. Я так и хотел в первый раз.

Не работает. Я наступил на четыре грабли подряд, расскажу зачем.

Первая. Claude не возвращает "я упал" честным исключением. Он возвращает 529 overloaded, 500, 502, или просто таймаут в 45 секунд. Клиент у тебя в вотсапе не будет ждать 45 секунд, он пишет "алё?" на 12-й.

Вторая. Системный промпт. У Claude он отдельным полем, у OpenAI это первое сообщение с ролью system, у Gemini вообще отдельный systemInstruction в запросе. Если ты тупо перекинул промпт без переформатирования, модель начнёт отвечать от первого лица про то, что ей сказали в инструкции. Я видел как агент после переключения на GPT написал клиенту "как системный промпт говорит, я должен выяснить бюджет". Занавес.

Третья. Токенайзеры разные. Claude считает токены по своему, GPT по tiktoken, Gemini вообще считает символами. Если у тебя контекст под завязку на Claude, на GPT-4 он не влезет. Либо обрезай историю заранее, либо резерв должен быть моделью с бОльшим контекстом.

Четвёртая. Стиль. Claude Sonnet отвечает осторожнее, добавляет оговорки, структурирует списком. GPT любит эмодзи и "конечно". Если клиент привык к одному тону, он сразу чувствует подмену. В B2B это не критично, в личке нейро-ассистента это фу.

Я выкинул идею "главная модель плюс резерв" и перешёл на три роли: primary, secondary, last resort.

Primary это то, что даёт лучший ответ на эту задачу. Обычно Claude Sonnet 4.6 для разговорного с клиентом, GPT-5 для жёсткой логики и парсинга, Gemini 2.5 Pro для мультимодалки.

Secondary это другой вендор с соседним качеством. Не обязательно топовая модель, главное - другой хостинг, другая облачная инфраструктура. Claude → GPT-5, GPT-5 → Claude Sonnet 4.6, Gemini → GPT-5 mini. Смысл не в том, чтобы качество было идентичным, а в том, чтобы другой провайдер не валялся одновременно с первым.

Last resort это что-то, что в принципе живёт в РФ или на независимой инфре. У меня это YandexGPT 4 Pro или Kimi K2.6 через свой прокси. Качество заметно хуже, но когда клиент два часа не получает ответа - любой ответ лучше тишины. Агент на ласт-ресорте переходит в режим "я вас понял, менеджер ответит в течение 15 минут", и передаёт диалог человеку.

Ключевое тут слово - другой провайдер. Не "Opus если упал Sonnet", потому что они оба лежат в одном инфра-стеке Anthropic и падают вместе. Я это узнал 13 апреля в 17:52.

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

Звучит просто. Дьявол в трёх местах, про которые обычно не пишут.

Таймаут должен быть короче чем у провайдера. У SDK Anthropic дефолтный таймаут 600 секунд. На проде это смерть. Я режу на 15-18 секунд. Если модель не уложилась, клиент скорее получит ответ от GPT, чем будет ждать Claude ещё сорок секунд и потом ещё столько же до handoff.

Системный промпт адаптируется под формат каждого провайдера на лету. Храню его в одном месте с плейсхолдерами, а перед запросом рендерю в нужную форму: у Claude это отдельное поле в запросе, у OpenAI первое сообщение в истории, у Gemini вообще отдельная инструкция на уровне запроса. История тоже нормализуется: Claude не любит два юзерских сообщения подряд, OpenAI пофиг, Gemini требует своих ролей user/model вместо user/assistant. Если эту нормализацию не делать, вторичный провайдер либо отвергнет запрос, либо ответит дичью.

История сжимается перед перекидыванием на другую модель. Если в диалоге 15 сообщений и я на 16-м решил уйти с Claude на GPT, я не тащу все 15 как есть. Сжимаю в короткое саммари через ту же primary (если она ещё дышит) или через дешёвую модель типа Gemini Flash, и подаю во вторичку как "вот что было раньше в двух абзацах, продолжи разговор". Экономит токены, сохраняет связность, не даёт клиенту почувствовать резкую смену тона.

И пара вещей сверху. Параллельные запросы в двух провайдеров сразу - заманчиво, но бьёт по бюджету вдвое. Использую только для VIP-клиентов или критичных операций (оформление заявки через агента, например). Второе: ретраи в рамках одного провайдера не имеют смысла, если он отдаёт 529 overloaded. Он не "на секунду замешкался", у него очередь на минуты. Сразу идём к следующему.

Меряю по одному клиенту, у которого голосовой AI-помощник висит на обработке входящих звонков. Март месяц, только на Claude Sonnet:

Формат "было на одном Claude → стало с роутером":

Перцентиль упал потому что роутер срезает хвост: если Claude дал таймаут на 15 секундах, я не жду ещё 30, я уже на GPT. Эскалация на человека упала потому что раньше при 5хх мы сразу скидывали на менеджера, а теперь пробуем другую модель, и в 8 случаях из 10 она отвечает нормально.

99.84 это не красивая цифра ради поста. Недостающие 0.16% это по большей части истории, где все три провайдера одновременно медленно отвечали и мы упёрлись в финальный handoff.

Цены в рублях за миллион токенов (вход / выход), на 20 апреля 2026, через легальные российские прокси типа OpenRouter Russia, ProxyAPI, GPTunnel:

Главное наблюдение: роутер стоит дороже, но не в разы. У моего клиента был счёт в марте 38 400₽ на Claude. В апреле стал 41 200₽ суммарно по всем трём. Разница 2800₽ при том что аптайм в два раза лучше и эскалация втрое меньше. Один сорванный заказ на 120к окупает роутер на полгода.

Экономить можно иначе: дешёвым моделям отдавать классификацию, маршрутизацию и "что клиент спросил". А дорогой Claude дёргать только когда реально нужен длинный связный ответ. Но это уже не про отказоустойчивость, это про оптимизацию, отдельная тема.

Не все задачи требуют мультимодельки. Я бы не стал её пихать в:

Роутер нужен там, где у тебя живой клиент в реал-тайме и любая минута простоя это потерянные деньги или репутация. Входящие звонки, чаты в мессенджерах на сайте, голосовые боты. Всё остальное - по вкусу.

Сейчас модно рекомендовать Bifrost, Requesty, OpenRouter как "просто подключи и всё". Я их тыкал. Тезисно:

OpenRouter удобен чтобы быстро прикинуть, какая модель вообще лучше справится с твоей задачей. Для прод-роутинга я бы на него не опирался - это ещё один прокси, который тоже может упасть, и который делает биллинг не в рублях.

Bifrost умный, но требует деплоя и конфига. Если у тебя и так есть команда которая держит инфру, норм. Если ты соло или в мини-команде, проще написать 300 строк роутера и контролировать его самому.

Requesty платный и с их SLA поверх чужих SLA. То есть ты теперь зависишь ещё от одного слоя. Для энтерпрайза с SSO и аудитом может быть оправдано, для SMB - оверкилл.

Мой роутер - это один файл на Python, в нём функция generate, таймаутинг, логирование, адаптеры форматов. Всё помещается в голове. Когда в 18:07 клиент кричит "у меня бот не отвечает", я знаю куда смотреть. Когда этот же клиент кричит "у меня в Bifrost что-то в routing-policy.yaml", я не знаю.

Первое, про которое вспоминают последним. Логируй какая модель ответила. В БД, рядом с каждым сообщением, пиши provider_used. Через месяц ты увидишь, кто реально тянет нагрузку, где прячутся регрессии по качеству, и сможешь понять "у клиента жалоба на тупой ответ 14-го апреля в 13:22 - это GPT отвечал потому что Claude подвисал". Без этого ты будешь гадать.

Второе. Тесты. Обычные unit-тесты тут не годятся, потому что ответы LLM недетерминированы. Я делаю так: золотой набор из 40 типовых запросов от клиента, прогоняю раз в неделю через все три модели, оцениваю через Claude-as-judge (тот же набор, но задача - поставить 1-5 за соответствие эталону). Если где-то качество просело больше чем на 0.3 балла - алерт в телегу. Без этого ты заметишь проблему только когда клиент напишет.

13 апреля был последний раз когда я потерял клиенту деньги из-за простоя LLM. Не потому что провайдеры перестали падать, они падают как падали. А потому что теперь оно пофигу. Один лёг, второй отвечает, человек ничего не заметил.

Роутер это не какая-то космическая штука. Это 300 строк кода, которые надо один раз написать и потом поддерживать. По соотношению "вложенные часы / сохранённая выручка клиента" это самая выгодная вещь, которую я за последние полгода прикрутил к своим системам.

Единственный совет на который готов подписаться: не жди следующего 13 апреля. Садись и пиши.