⚠️ Rate limited — switching to fallback provider... 🔄 Primary model failed — switching to fallback: sg claude opus 4.7 via custom — чому це повторюється

Чому попередження повторюється знову і знову

Секрет у тому, що механізм fallback у Hermes працює per-turn — тобто окремо для кожного повідомлення в діалозі. Щоразу, коли ви надсилаєте новий запит, агент спочатку намагається звернутися до основної моделі. Якщо вона все ще повертає помилку — спрацьовує fallback, і з'являється те саме попередження.

Іншими словами: якщо ваш основний провайдер протягом тривалого часу лишається недоступним через rate limit, ви бачитимете це повідомлення на кожному кроці діалогу. Це не означає, що fallback не працює — навпаки, він щоразу рятує вашу сесію.

Чому саме «sg claude opus 4.7 via custom»

Позначка

via custom

hermes model

Тут криється потенційна проблема: якщо ваш основний провайдер і резервний кастомний ендпоінт (sg-*) фактично використовують один і той самий gateway, один і той самий набір API-ключів або один і той самий пул ресурсів із вичерпаною квотою, то обидва будуть недоступні одночасно. Ви побачите перемикання, але якість відповіді не покращиться, бо резервна модель стикається з тими самими обмеженнями.

Наразі недостатньо даних, щоб із певністю стверджувати, що обидва шляхи ділять спільний пул, але це найімовірніший сценарій, який варто перевірити у вашій конфігурації.

Практичний план діагностики

Щоб позбутися набридливого попередження, потрібно усунути першопричину — проблему з основним провайдером. Ось що варто зробити:

1. Перевірте поточну конфігурацію основних і резервних моделей

   Зазирніть у ~/.hermes/config.yaml. Знайдіть, який провайдер і модель вказано як primary, та який ланцюжок прописано у fallback_providers. Зверніть увагу, чи не вказують primary і резервний sg-* на один і той самий gateway або одну групу ключів.

2. Пробийте стан gateway

   Якщо використовуєте OpenClaw gateway, виконайте:

   bash

   openclaw gateway probe

   Ця команда покаже, чи доступний gateway (

   Reachable: yes

   ), та чи є проблеми з автентифікацією (наприклад,

   missing scope: operator.read

   — це не помилка з'єднання, а зниження рівня доступу).

3. Визначте справжню помилку

   Уважно перечитайте текст помилки. Якщо бачите

   HTTP 429

   , rate_limit_error, згадку

   Extra usage is required for long context requests

   — це прямий сигнал, що upstream-провайдер відхиляє запити через перевищення квоти. Зокрема, для моделей Anthropic помилка 429 може виникати саме через завеликий контекст запиту, що вимагає додаткових ресурсів.

4. Переконайтеся, що API-ключі коректно зчитані

   Якщо gateway працює під systemd/launchd, ключі варто зберігати у ~/.openclaw/.env, після чого перезапустити демон. Переконайтеся, що ключі фізично присутні на хості, де запущено gateway — помилка «ключ не знайдено» може маскуватися під rate limit.

5. Перевірте, чи немає застарілих клієнтських процесів

   Виконайте

   openclaw gateway status --deep

   — якщо виявите «завислий» процес клієнта, зупиніть його та перезапустіть оболонки чи застосунки, що використовують OpenClaw.

6. Зменшіть обсяг контексту

   Якщо помилка стабільно виникає на довгих діалогах, спробуйте скоротити розмір контексту — наприклад, розбити задачу на менші частини або очистити історію розмови. Це особливо актуально, якщо у тексті помилки фігурує «Extra usage is required for long context requests».

Як це виправити остаточно

Варіанти вирішення залежать від того, що саме спричиняє rate limit:

• Вичерпано квоту основного провайдера — дочекайтеся відновлення ліміту або оновіть тарифний план.
• Основний і резервний провайдери ділять спільний пул ключів — налаштуйте резервну модель на іншому, незалежному провайдері або окремому API-ключі.
• Завеликий контекст — зменшіть розмір запитів або використовуйте моделі з більшим контекстним вікном.
• Помилка автентифікації маскується під rate limit — перевірте валідність ключів і перезапустіть gateway після оновлення .env.
• Хибне спрацювання cooldown-механізму OpenClaw — відомий баг, коли всі моделі позначаються як «rate limited», хоча API працюють нормально. У такому випадку допомагає перезапуск gateway.

Висновок

Попередження «Rate limited — switching to fallback» повторюється кожного туру не тому, що fallback не працює, а тому, що основний провайдер досі недоступний, а Hermes щоразу сумлінно пробує до нього звернутися перед перемиканням. Це коректна, передбачувана поведінка системи.

Щоб позбутися попередження остаточно, потрібно вирішити проблему на боці основного провайдера або переконатися, що резервний шлях використовує дійсно незалежний пул ресурсів.

Хочете, щоб я допоміг перевірити ваш конкретний config.yaml прямо зараз? Я можу проаналізувати, який primary використовується, куди веде резервний sg-*, і чому система постійно повертається до основної моделі щотурну.