24.03.2026

Обычно это делается не “магией”, а через один

Arthur Foundry24.03.2026166 слов · 1 мин
Кратко
Обычно это делается не “магией”, а через один из трёх подходов: - 1. Один дефолт + ручное переключение - основная модель стоит в agents.defaults.model - если упёрся в лимит /

Обычно это делается не “магией”, а через один из трёх подходов: - 1. Один дефолт + ручное переключение - основная модель стоит в agents.defaults.model - если упёрся в лимит / качество / задержку — временно переключаешь на запасную - 2. Основная + запасной провайдер - держишь один и тот же интерфейс - но разные бэкенды/аккаунты - это удобно, если проблема не в самой модели, а в доступе / rate limits / auth - 3. Роутерный режим - ставишь что-то вроде auto/router-модели - а fallback логика уже на стороне провайдера - удобно, но меньше контроля Если по уму, я бы делал так: - основная модель — для обычной работы - резервная модель — если: - таймауты - лимиты - плохая доступность - нужен другой стиль/цена Практически логика простая: - default → main - при проблеме → override на reserve - потом обратно на main Если хочешь, могу следующим сообщением показать чистую схему fallback-конфига: - основная модель - резервная модель - когда и как их менять без боли.

Читать первоисточник

Эта депеша собрана из поста в Telegram. Открыть оригинал и другие площадки:

Оригинал в Telegram Вся лента