Основная модель · упорядоченный fallback · 429 · консоль в графической сессии
Когда один идентификатор модели перестаёт покрывать весь рабочий день, команды переводят OpenClaw на многомодельную схему: отдельная основная модель для типовых задач и упорядоченный fallback на случай деградации качества, таймаутов или исчерпания квот. Здесь — как описать политику в конфигурации и логах, как не разориться на стоимости, что делать с ответами 429, какие метрики Gateway собирать до эскалации, и чеклист консоли браузера в сессии VNC на арендованном Mac, где графика совпадает с пользователем процесса. Связка с многоканальным Gateway и памятью и контекстом помогает отделить проблему маршрутизации от раздувания индекса.
Одна модель на все сценарии экономит время на согласовании, но плохо переносит пики: дорогой запрос на рутину сжигает бюджет, а дешёвая модель на сложный инструментарий даёт каскад исправлений. Маршрутизация в терминах OpenClaw — это не только «подставить другой идентификатор», а явное правило выбора с учётом канала, роли агента, лимитов провайдера и наблюдаемости. Политику фиксируют в репозитории: кто может менять список моделей, как версионируется конфигурация, какой порядок fallback считается эталонным для продакшена.
Практический минимум — три уровня осознанности. Первый: основная модель отвечает за типовой поток и должна иметь стабильные задержки в вашем регионе. Второй: резервные модели перечислены в строгом порядке; при сбое шлюз переходит к следующей только после исчерпания критериев отказа (ошибка сети, пустой ответ, превышение токенов, явный отказ провайдера). Третий: аудит — в логах видно, какая модель реально отработала раунд, иначе разбор инцидента превращается в спор о «качестве промпта».
Каналы и шлюз: при нескольких входах согласуйте политику с материалом про многоканальный Gateway, чтобы один канал не обходил лимиты другого.
Стабильность после обновлений: после смены ветки прогоните openclaw doctor по чеклисту из заметки про v2026.4.5 — иначе маршрутизация «работает вчера».
Тишина и зависания: если ответа нет, сначала отделите сеть и heartbeat от выбора модели по гайду «нет ответа».
Когда память и retrieval уже нагружены, смешивание тяжёлых моделей с большим контекстом усугубляет задержку до первого байта; держите под рукой материал о контексте и Palace, чтобы не принять узкое место индекса за нехватку «мощности» основной модели.
Основная модель — это не «самая дорогая», а та, на которую вы готовы подписать соглашение об уровне сервиса внутри команды: известная задержка, предсказуемая цена за миллион токенов на вашем типичном корпусе промптов, понятные ограничения по инструментам. Fallback — упорядоченный список запасных вариантов; порядок важнее длины списка: пять моделей без приоритета хуже двух с явной лестницей.
Типичный антипаттерн — «перебор до успеха» без записи причины переключения: в логах видно только финальный ответ, а поддержка не может восстановить, на каком шаге цепочки отвалился провайдер. Второй антипаттерн — одинаковые лимиты на все ступени: если резерв так же агрессивно бьёт по квоте, каскад 429 за минуту превращается в шум. Третий — смешение ролей: дорогая модель на фоновые задачи и дешевая на критический путь без явного разделения по каналам.
| Ситуация | Рекомендация | Избегать |
|---|---|---|
| Таймаут основной модели | Один измеримый таймаут, затем переход к первой резервной с записью кода | Мгновенный параллельный залп во все резервы |
| Деградация качества | Отдельный критерий (оценка инструмента, повтор с узким промптом) | Бесконечный ручной перебор в интерфейсе без политики |
| Инструменты и exit code | Сначала разбор прав и логов по гайду об ошибке инструмента | Смена модели при каждом ненулевом коде без классификации |
Fallback без порядка — это не отказоустойчивость, а лотерея по стоимости и качеству.
Документируйте для онбординга: какая модель считается «источником истины» для регрессионных промптов, как часто пересматривается лестница, кто утверждает изменение в пятницу вечером. На удалённом Mac это особенно заметно: разные учётные записи и пути к конфигурации легко дают расхождение между тем, что правит администратор по SSH, и тем, что видит оператор в графической сессии.
Стоимость в облачных моделях складывается из входных и выходных токенов, частоты вызовов инструментов и доли запросов, ушедших в fallback на более дорогой тариф. Когда внезапно растёт счёт, первые подозреваемые — не «плохая нейросеть», а удвоенные ретраи, параллельные каналы и раздутый контекст, который заставляет каждую ступень лестницы платить полный вход заново.
Ответ 429 означает, что запрос отклонён по ограничению скорости или квоте; интерпретация зависит от провайдера и заголовков. В тикете укажите временное окно, число параллельных сессий, был ли каскад по fallback, и не превратился ли клиент в петлю ретраев без экспоненциальной задержки. Политика backoff должна быть согласована с Gateway: агрессивный повтор на все модели списка за секунды усугубляет лимит для соседних сервисов.
Заметка: если после снижения частоты запросов 429 исчез, а качество упало, возможно, вы уперлись в более дешёвую ступень fallback — проверьте поле выбранной модели в метриках шлюза.
Без метрик шлюз остаётся «чёрным ящиком»: виден только итоговый ответ ассистента. Минимальный промышленный набор — время до первого байта, полная длительность, идентификатор выбранной модели, факт срабатывания fallback, коды ответа апстрима и суммарные токены по раунду. Дополните счётчиками ошибок инструментов и длительностью фазы «thinking», если ваш стек это отдаёт: иначе путают задержку модели с ожиданием сети.
Стройте дашборд так, чтобы по одному идентификатору запроса можно было пройти цепочку: вход канала → выбор модели → возможные повторы → вызовы инструментов → финальный поток токенов. Это сокращает время согласования с безопасностью: не нужно снимать полные дампы, достаточно агрегатов и корреляции с heartbeat и логами. При многоканальной схеме добавьте измерение очереди между каналом и единым пулом моделей — очередь часто объясняет рост задержки при плоской загрузке процессора на Mac.
{
"gateway_metrics": ["ttfb_ms", "total_ms", "model_id", "fallback_step"],
"provider_signals": ["http_status", "retry_after_sec"],
"channel_tags": ["web", "internal", "cron"]
}
Сохраняйте срезы до и после изменения списка моделей хотя бы на неделю; иначе невозможно доказать, что новая основная модель не ухудшила конверсию инструментов или не подняла средний чек на миллион токенов.
SSH удобен для правок файлов и перезапуска служб, но консоль разработчика в браузере, сертификаты и привязка к интерактивному пользователю macOS отражаются в той среде, где открыто окно. Для проверки маршрутизации и ошибок шлюза откройте ту же графическую сессию, в которой крутится ваш сценарий приёмки: иначе легко поймать «у меня работает» на локальной машине и «в проде падает» на узле аренды.
| Пункт | Действие в VNC | Критерий готовности |
|---|---|---|
| Сеть | Вкладка «Сеть»: фильтр по домену API и по пути Gateway. | Видны статусы 200 и осмысленные 429 с заголовками, нет бесконечных повторов одного запроса. |
| Консоль | Очистить лог, воспроизвести один сценарий с переключением модели. | Ошибки мапятся на конфигурацию или права, а не на «неизвестный сбой». |
| Время и локаль | Сверить часы в строке меню с метками в логах Gateway. | События в тикете сопоставимы с трассой без сдвига на часы. |
| Память и диск | Мониторинг системы при длинном стриме ответа. | Нет давления на подкачку из‑за параллельных тяжёлых вкладок. |
| Согласованность пользователя | Убедиться, что браузер и демоны смотрят в один домашний каталог. | Пути к конфигурации совпадают с теми, что проверяет doctor. |
Если после обновления что‑то ломается на уровне инструмента, пройдите чеклист exit code и прав в той же сессии, где воспроизводится ошибка; смешение пользователей часто маскируется под «нестабильность модели». После правок перезапустите затронутые процессы и повторите измерение метрик из раздела 04.
Внимание: не публикуйте в скриншотах консоли ключи и полные токены; для тикета достаточно обезличенных идентификаторов запроса и ступени fallback.
Темы ниже закрывают соседние слои стека: каналы шлюза, обновления и стабильность, сеть и инструменты. Сохраняйте при переносе на другие локали заголовок, разделитель и сетку карточек.
Проверяемая память, импорт инсайтов и разбор раздувания до смены модели.
Читать →Согласование каналов с единой политикой моделей и лимитов.
Читать →Breaking-изменения и чеклист после апгрейда на удалённом Mac.
Читать →Heartbeat, thinking и логи до обвинения маршрутизации.
Читать →Коды выхода, права и логи в графической сессии.
Читать →Без явного порядка страдают предсказуемость, стоимость и воспроизводимость. Зафиксируйте лестницу и условия перехода; см. разделы 01–02.
Часто это скорость или квота; проверьте параллельные каналы, backoff и заголовки провайдера — раздел 03.
Минимум: первая задержка, полная длительность, модель, ступень fallback, статусы — раздел 04.
Графическая сессия совпадает с браузером и пользователем macOS для приёмки; см. раздел 05.
Многомодельная маршрутизация в OpenClaw окупается, когда политика основной модели и упорядоченного fallback записана, измерима и согласована с каналами шлюза. Стоимость и ответы 429 перестают быть загадкой, если заранее разделить бюджеты, ввести дисциплину ретраев и держать метрики Gateway на уровне одного идентификатора запроса. На арендованном Mac проверяйте сеть и консоль в той же интерактивной сессии, где работает ваш сценарий, иначе диагностика уедет в сторону воображаемых проблем модели.
Железо и электричество на столе стоят дороже в долгом горизонте, чем предсказуемый облачный узел с графикой. VNCMac даёт удалённый Mac под такие приёмки: основная кнопка ведёт на страницу покупки, обзор тарифов — на главной.