--- read_when: - Діагностика ротації профілів автентифікації, періодів очікування або поведінки резервного переходу моделі - Оновлення правил аварійного перемикання для профілів автентифікації або моделей - Розуміння того, як перевизначення моделі сеансу взаємодіють із повторними спробами переходу на резервний варіант sidebarTitle: Model failover summary: Як OpenClaw перемикає профілі автентифікації та виконує резервний перехід між моделями title: Аварійне перемикання моделей x-i18n: generated_at: "2026-07-04T15:34:47Z" model: gpt-5.5 postprocess_version: locale-links-v1 provider: openai source_hash: 1521e27c53029ead305f29b7a29b627b519adbd28ed30688c01f32542625855f source_path: concepts/model-failover.md workflow: 16 --- OpenClaw обробляє збої у два етапи: 1. **Ротація профілю автентифікації** в межах поточного провайдера. 2. **Перехід на резервну модель** до наступної моделі в `agents.defaults.model.fallbacks`. У цьому документі пояснено правила виконання та дані, на яких вони базуються. ## Потік виконання Для звичайного текстового запуску OpenClaw оцінює кандидатів у такому порядку: Визначити активну модель сесії та бажаний профіль автентифікації. Побудувати ланцюжок кандидатів моделей з поточного вибору моделі та політики резервного переходу для джерела цього вибору. Налаштовані типові значення, основні моделі cron-завдань і автоматично вибрані резервні моделі можуть використовувати налаштовані резервні варіанти; явні вибори користувача в сесії є суворими. Спробувати поточного провайдера з правилами ротації/періоду очікування профілів автентифікації. Якщо цей провайдер вичерпано з помилкою, придатною для failover, перейти до наступного кандидата моделі. Зберегти вибране резервне перевизначення до початку повторної спроби, щоб інші читачі сесії бачили того самого провайдера/модель, які runner збирається використати. Збережене перевизначення моделі позначається як `modelOverrideSource: "auto"`. Якщо резервний кандидат зазнає збою, відкотити лише поля перевизначення сесії, що належать резервному механізму, коли вони все ще відповідають цьому невдалому кандидату. Якщо всі кандидати зазнають збою, викинути `FallbackSummaryError` з деталями кожної спроби та найближчим завершенням періоду очікування, якщо воно відоме. Це навмисно вужче, ніж «зберегти та відновити всю сесію». Runner відповіді зберігає лише поля вибору моделі, якими він володіє для резервного переходу: - `providerOverride` - `modelOverride` - `modelOverrideSource` - `authProfileOverride` - `authProfileOverrideSource` - `authProfileOverrideCompactionCount` Це запобігає тому, щоб невдала повторна спроба з резервною моделлю перезаписала новіші непов’язані мутації сесії, як-от ручні зміни `/model` або оновлення ротації сесії, що сталися під час виконання спроби. ## Політика джерела вибору OpenClaw відокремлює вибраного провайдера/модель від причини вибору. Це джерело визначає, чи дозволено ланцюжок резервного переходу: - **Налаштоване типове значення**: `agents.defaults.model.primary` використовує `agents.defaults.model.fallbacks`. - **Основна модель агента**: `agents.list[].model` є суворою, якщо об’єкт моделі цього агента не містить власних `fallbacks`. Використайте `fallbacks: []`, щоб зробити сувору поведінку явною, або надайте непорожній список, щоб увімкнути для цього агента перехід на резервну модель. - **Автоматичне резервне перевизначення**: резервний перехід під час виконання записує `providerOverride`, `modelOverride`, `modelOverrideSource: "auto"` і вибрану вихідну модель перед повторною спробою. Це автоматичне перевизначення може продовжувати рухатися налаштованим ланцюжком резервних моделей без перевірки основної моделі для кожного повідомлення, але OpenClaw періодично знову перевіряє налаштоване джерело й очищає автоматичне перевизначення після його відновлення. `/new`, `/reset` і `sessions.reset` також очищають перевизначення з автоматичним джерелом. Запуски Heartbeat без явного `heartbeat.model` очищають прямі автоматичні перевизначення, коли їхнє джерело більше не відповідає поточному налаштованому типовому значенню. - **Користувацьке перевизначення сесії**: `/model`, засіб вибору моделі, `session_status(model=...)` і `sessions.patch` записують `modelOverrideSource: "user"`. Це точний вибір сесії. Якщо вибраний провайдер/модель зазнає збою до створення відповіді, OpenClaw повідомляє про збій замість відповіді від непов’язаної налаштованої резервної моделі. - **Застаріле перевизначення сесії**: старіші записи сесій можуть мати `modelOverride` без `modelOverrideSource`. OpenClaw розглядає їх як користувацькі перевизначення, щоб явний старий вибір не був непомітно перетворений на поведінку резервного переходу. - **Модель у payload Cron**: `payload.model` / `--model` cron-завдання є основною моделлю завдання, а не користувацьким перевизначенням сесії. Вона використовує налаштовані резервні варіанти, якщо завдання не надає `payload.fallbacks`; `payload.fallbacks: []` робить cron-запуск суворим. Інтервал автоматичної перевірки основної моделі для резервного переходу становить п’ять хвилин і не налаштовується. OpenClaw запам’ятовує останні перевірки для кожної сесії та основної моделі, щоб основна модель, яка зазнає збою, не перевірялася на кожному ході. OpenClaw надсилає видиме сповіщення, коли сесія переходить на резервну модель, і ще одне сповіщення, коли повертається до вибраної основної моделі; він не повторює сповіщення на кожному ході з фіксованою резервною моделлю. ## Кеш пропуску збоїв автентифікації За замовчуванням кожен новий хід зберігає наявну поведінку повторних спроб резервного переходу: OpenClaw знову спробує кожного налаштованого резервного кандидата, включно з неосновними кандидатами, які нещодавно зазнали збою з `auth` або `auth_permanent`. Оператори, які хочуть приглушити такі повторні збої автентифікації, можуть увімкнути це за допомогою: ```bash OPENCLAW_FALLBACK_SKIP_TTL_MS=60000 ``` Коли це ввімкнено, OpenClaw записує в пам’яті, в межах сесії, маркер пропуску для неосновного резервного кандидата після збою класу автентифікації. Маркер ключується за ідентифікатором сесії, провайдером і моделлю. Основні кандидати ніколи не пропускаються, тож явний користувацький вибір моделі все одно показує реальну помилку автентифікації. Кеш є локальним для процесу й очищається після перезапуску Gateway. Значення є TTL у мілісекундах. `0` або невстановлене значення вимикає кеш. Додатні значення обмежуються діапазоном від 1 секунди до 10 хвилин. ## Видимі для користувача сповіщення про резервний перехід Коли сесія переходить на автоматично вибрану резервну модель, OpenClaw надсилає сповіщення про стан у тій самій поверхні відповіді: ```text ↪️ Model Fallback: (selected ; ) ``` Коли пізніша перевірка успішна й сесія повертається до вибраної основної моделі, OpenClaw надсилає: ```text ↪️ Model Fallback cleared: (was ) ``` Ці сповіщення є операційними повідомленнями, а не вмістом асистента. Вони доставляються один раз для кожної зміни стану, зокрема для ходів лише з побічними ефектами, коли це можливо, але ходи з фіксованою резервною моделлю не повторюють їх. Доставка обходить звичайне приглушення відповіді джерелу, сповіщення не займає перший слот відповіді асистента для каналів із тредами, і воно виключається з text-to-speech та витягання commitment. ## Сховище автентифікації (ключі + OAuth) OpenClaw використовує **профілі автентифікації** і для API-ключів, і для токенів OAuth. - Секрети та стан маршрутизації автентифікації під час виконання зберігаються в `~/.openclaw/agents//agent/openclaw-agent.sqlite`. - Конфігурація `auth.profiles` / `auth.order` є **лише метаданими + маршрутизацією** (без секретів). - Застарілий файл OAuth лише для імпорту: `~/.openclaw/credentials/oauth.json` (імпортується в сховище автентифікації окремого агента під час першого використання). - Застарілі файли `auth-profiles.json`, `auth-state.json` і `auth.json` окремих агентів імпортуються командою `openclaw doctor --fix`. Докладніше: [OAuth](/uk/concepts/oauth) Типи облікових даних: - `type: "api_key"` → `{ provider, key }` - `type: "oauth"` → `{ provider, access, refresh, expires, email? }` (+ `projectId`/`enterpriseUrl` для деяких провайдерів) ## Ідентифікатори профілів Входи OAuth створюють окремі профілі, щоб кілька облікових записів могли співіснувати. - Типово: `provider:default`, коли email недоступний. - OAuth з email: `provider:` (наприклад, `google-antigravity:user@gmail.com`). Профілі зберігаються в сховищі профілів автентифікації `openclaw-agent.sqlite` окремого агента. ## Порядок ротації Коли провайдер має кілька профілів, OpenClaw вибирає порядок так: `auth.order[provider]` (якщо задано). `auth.profiles`, відфільтровані за провайдером. Записи профілів автентифікації SQLite окремого агента для провайдера. Якщо явний порядок не налаштовано, OpenClaw використовує порядок round-robin: - **Основний ключ:** тип профілю (**OAuth перед API-ключами**). - **Вторинний ключ:** `usageStats.lastUsed` (найстаріші спочатку, в межах кожного типу). - **Профілі в періоді очікування/вимкнені профілі** переміщуються в кінець, упорядковані за найближчим завершенням періоду. ### Фіксація сесії (дружня до кешу) OpenClaw **закріплює вибраний профіль автентифікації за сесією**, щоб кеші провайдера залишалися прогрітими. Він **не** ротатує профіль для кожного запиту. Закріплений профіль повторно використовується, доки: - сесію не скинуто (`/new` / `/reset`) - не завершиться Compaction (лічильник Compaction збільшується) - профіль перебуває в періоді очікування/вимкнений Ручний вибір через `/model …@` встановлює **користувацьке перевизначення** для цієї сесії та не ротатується автоматично до початку нової сесії. Автоматично закріплені профілі (вибрані маршрутизатором сесії) розглядаються як **перевага**: їх пробують першими, але OpenClaw може перейти до іншого профілю в разі rate limit або timeout. Коли початковий профіль знову стає доступним, нові запуски можуть знову віддати йому перевагу без зміни вибраної моделі чи runtime. Закріплені користувачем профілі залишаються прив’язаними до цього профілю; якщо він зазнає збою і налаштовано резервні моделі, OpenClaw переходить до наступної моделі замість перемикання профілів. ### Підписка OpenAI Codex плюс резервний API-ключ Для агентних моделей OpenAI автентифікація та runtime є окремими. `openai/gpt-*` залишається на Codex harness, тоді як автентифікація може ротуватися між профілем підписки Codex і резервним API-ключем OpenAI. Використовуйте `auth.order.openai` для порядку, видимого користувачу: ```json5 { auth: { order: { openai: ["openai:user@example.com", "openai:api-key-backup"], }, }, } ``` Використовуйте `openai:*` і для профілів OAuth ChatGPT/Codex, і для профілів API-ключів OpenAI. Коли підписка досягає ліміту використання Codex, OpenClaw записує точний час скидання, якщо Codex його надає, пробує наступний упорядкований профіль автентифікації та залишає запуск усередині Codex harness. Після проходження часу скидання профіль підписки знову придатний, і наступний автоматичний вибір може повернутися до нього. Використовуйте закріплений користувачем профіль лише тоді, коли потрібно примусово використовувати один обліковий запис/ключ для цієї сесії. Закріплені користувачем профілі навмисно суворі й не перемикаються непомітно на інший профіль. ## Періоди очікування Коли профіль зазнає збою через помилки автентифікації/rate-limit (або timeout, схожий на rate limiting), OpenClaw позначає його як такий, що перебуває в періоді очікування, і переходить до наступного профілю. Цей кошик rate-limit ширший за звичайний `429`: він також охоплює повідомлення провайдерів, як-от `Too many concurrent requests`, `ThrottlingException`, `concurrency limit reached`, `workers_ai ... quota limit exceeded`, `throttled`, `resource exhausted`, і періодичні ліміти вікна використання, як-от `weekly/monthly limit reached`. Помилки формату/некоректного запиту зазвичай є термінальними, бо повторення того самого payload зазнало б збою так само, тому OpenClaw показує їх замість ротації профілів автентифікації. Відомі шляхи повторної спроби з виправленням можуть явно ввімкнутися: наприклад, помилки перевірки ID виклику інструмента Cloud Code Assist очищаються й повторюються один раз через політику `allowFormatRetry`. OpenAI-сумісні помилки stop-reason, як-от `Unhandled stop reason: error`, `stop reason: error` і `reason: error`, класифікуються як сигнали timeout/failover. Загальний серверний текст також може потрапити до цього кошика timeout, коли джерело відповідає відомому тимчасовому шаблону. Наприклад, просте повідомлення обгортки потоку runtime моделі `An unknown error occurred` вважається придатним для failover для кожного провайдера, бо спільний runtime моделі видає його, коли потоки провайдера завершуються з `stopReason: "aborted"` або `stopReason: "error"` без конкретних деталей. JSON-payload `api_error` з тимчасовим серверним текстом, як-от `internal server error`, `unknown error, 520`, `upstream error` або `backend error`, також вважаються timeout, придатними для failover. Загальний upstream-текст, специфічний для OpenRouter, як-от просте `Provider returned error`, вважається timeout лише тоді, коли контекст провайдера справді є OpenRouter. Загальний внутрішній текст резервного переходу, як-от `LLM request failed with an unknown error.`, залишається консервативним і сам по собі не запускає failover. Деякі SDK провайдерів інакше можуть очікувати протягом довгого вікна `Retry-After`, перш ніж повернути керування OpenClaw. Для SDK на основі Stainless, таких як Anthropic і OpenAI, OpenClaw за замовчуванням обмежує внутрішні очікування SDK `retry-after-ms` / `retry-after` 60 секундами й одразу показує довші повторювані відповіді, щоб цей шлях резервного перемикання міг виконатися. Налаштуйте або вимкніть це обмеження за допомогою `OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS`; див. [Поведінка повторних спроб](/uk/concepts/retry). Періоди охолодження для обмеження частоти також можуть бути прив’язані до моделі: - OpenClaw записує `cooldownModel` для збоїв через обмеження частоти, коли відомий ідентифікатор моделі, що зазнала збою. - Споріднену модель у того самого провайдера все ще можна спробувати, коли період охолодження прив’язаний до іншої моделі. - Вікна білінгу/вимкнення все ще блокують увесь профіль для всіх моделей. Періоди охолодження використовують експоненційне відкладення: - 1 хвилина - 5 хвилин - 25 хвилин - 1 година (обмеження) Стан зберігається в SQLite-стані автентифікації окремого агента в `usageStats`: ```json { "usageStats": { "provider:profile": { "lastUsed": 1736160000000, "cooldownUntil": 1736160600000, "errorCount": 2 } } } ``` ## Вимкнення через білінг Збої білінгу/кредитів (наприклад, "insufficient credits" / "credit balance too low") вважаються придатними для резервного перемикання, але зазвичай вони не є тимчасовими. Замість короткого періоду охолодження OpenClaw позначає профіль як **вимкнений** (із довшим відкладенням) і переходить до наступного профілю/провайдера. Не кожна відповідь, схожа на білінгову, є `402`, і не кожен HTTP `402` потрапляє сюди. OpenClaw зберігає явний білінговий текст у білінговій гілці навіть тоді, коли провайдер натомість повертає `401` або `403`, але специфічні для провайдера зіставлення залишаються обмеженими тим провайдером, якому вони належать (наприклад, OpenRouter `403 Key limit exceeded`). Водночас тимчасові помилки `402`, пов’язані з вікном використання та лімітами витрат організації/робочого простору, класифікуються як `rate_limit`, коли повідомлення виглядає придатним для повторної спроби (наприклад, `weekly usage limit exhausted`, `daily limit reached, resets tomorrow` або `organization spending limit exceeded`). Вони залишаються на короткому шляху охолодження/резервного перемикання замість довгого шляху вимкнення через білінг. Стан зберігається в SQLite-стані автентифікації окремого агента: ```json { "usageStats": { "provider:profile": { "disabledUntil": 1736178000000, "disabledReason": "billing" } } } ``` Типові значення: - Відкладення через білінг починається з **5 годин**, подвоюється після кожного білінгового збою та обмежується **24 годинами**. - Лічильники відкладення скидаються, якщо профіль не зазнавав збою протягом **24 годин** (налаштовується). - Повторні спроби через перевантаження дозволяють **1 ротацію профілю того самого провайдера** перед резервним переходом моделі. - Повторні спроби через перевантаження за замовчуванням використовують **відкладення 0 мс**. ## Резервний перехід моделі Якщо всі профілі для провайдера зазнають збою, OpenClaw переходить до наступної моделі в `agents.defaults.model.fallbacks`. Це застосовується до збоїв автентифікації, обмежень частоти та тайм-аутів, які вичерпали ротацію профілів (інші помилки не просувають резервний перехід). Помилки провайдера, які не надають достатньо деталей, усе одно точно позначаються в стані резервного переходу: `empty_response` означає, що провайдер не повернув придатного повідомлення або статусу, `no_error_details` означає, що провайдер явно повернув `Unknown error (no error details in response)`, а `unclassified` означає, що OpenClaw зберіг сирий попередній перегляд, але жоден класифікатор ще не збігся з ним. Помилки перевантаження та обмеження частоти обробляються агресивніше, ніж періоди охолодження білінгу. За замовчуванням OpenClaw дозволяє одну повторну спробу профілю автентифікації того самого провайдера, а потім без очікування перемикається на наступну налаштовану резервну модель. Сигнали зайнятості провайдера, такі як `ModelNotReadyException`, потрапляють у цей кошик перевантаження. Налаштуйте це за допомогою `auth.cooldowns.overloadedProfileRotations`, `auth.cooldowns.overloadedBackoffMs` і `auth.cooldowns.rateLimitedProfileRotations`. Коли запуск починається з налаштованої основної моделі за замовчуванням, основної моделі Cron-завдання, основної моделі агента з явними резервними варіантами або автоматично вибраного перевизначення резервного варіанта, OpenClaw може пройти відповідний налаштований ланцюжок резервних варіантів. Основні моделі агентів без явних резервних варіантів і явні вибори користувача (наприклад, `/model ollama/qwen3.5:27b`, вибір моделі, `sessions.patch` або одноразові перевизначення провайдера/моделі CLI) є строгими: якщо цей провайдер/модель недоступні або зазнають збою до створення відповіді, OpenClaw повідомляє про збій замість того, щоб відповідати з непов’язаного резервного варіанта. ### Правила ланцюжка кандидатів OpenClaw будує список кандидатів із поточного запитаного `provider/model` плюс налаштованих резервних варіантів. - Запитана модель завжди перша. - Явно налаштовані резервні варіанти дедуплікуються, але не фільтруються за списком дозволених моделей. Вони вважаються явним наміром оператора. - Якщо поточний запуск уже використовує налаштований резервний варіант у тій самій родині провайдерів, OpenClaw продовжує використовувати повний налаштований ланцюжок. - Коли явне перевизначення резервного варіанта не надано, налаштовані резервні варіанти пробуються перед налаштованою основною моделлю, навіть якщо запитана модель використовує іншого провайдера. - Коли явне перевизначення резервного варіанта не надано runner резервного переходу, налаштована основна модель додається в кінець, щоб ланцюжок міг повернутися до нормального типового значення після вичерпання попередніх кандидатів. - Коли викликач надає `fallbacksOverride`, runner використовує рівно запитану модель плюс цей список перевизначення. Порожній список вимикає резервний перехід моделі й не дає додати налаштовану основну модель як приховану ціль повторної спроби. ### Які помилки просувають резервний перехід - збоїв автентифікації - обмежень частоти та вичерпання періоду охолодження - помилок перевантаження/зайнятості провайдера - помилок резервного перемикання у формі тайм-ауту - вимкнень через білінг - `LiveSessionModelSwitchError`, яка нормалізується в шлях резервного перемикання, щоб застаріла збережена модель не створювала зовнішній цикл повторних спроб - інших нерозпізнаних помилок, коли ще залишаються кандидати - явних переривань, які не мають форми тайм-ауту/резервного перемикання - помилок переповнення контексту, які мають залишатися всередині логіки Compaction/повторної спроби (наприклад, `request_too_large`, `INVALID_ARGUMENT: input exceeds the maximum number of tokens`, `input token count exceeds the maximum number of input tokens`, `The input is too long for the model` або `ollama error: context length exceeded`) - фінальної невідомої помилки, коли кандидатів більше немає - відмов безпеки Claude Fable 5; прямі запити з API-ключем натомість обробляють їх на рівні провайдера через серверний резервний перехід Anthropic до `claude-opus-4-8` (див. [Anthropic](/uk/providers/anthropic#safety-refusal-fallback-claude-fable-5)) ### Пропуск періоду охолодження і поведінка перевірки Коли кожен профіль автентифікації для провайдера вже перебуває в періоді охолодження, OpenClaw не пропускає цього провайдера автоматично назавжди. Він ухвалює рішення для кожного кандидата: - Стійкі збої автентифікації негайно пропускають увесь провайдер. - Вимкнення через білінг зазвичай пропускаються, але основного кандидата все ще можна перевіряти з обмеженням частоти, щоб відновлення було можливим без перезапуску. - Основного кандидата можна перевіряти ближче до завершення періоду охолодження, з обмеженням частоти для кожного провайдера. - Споріднені резервні варіанти того самого провайдера можна спробувати попри період охолодження, коли збій виглядає тимчасовим (`rate_limit`, `overloaded` або невідомий). Це особливо важливо, коли обмеження частоти прив’язане до моделі, а споріднена модель може відновитися негайно. - Тимчасові перевірки періоду охолодження обмежені однією на провайдера для кожного запуску резервного переходу, щоб один провайдер не затримував резервний перехід між провайдерами. ## Перевизначення сесії та живе перемикання моделі Зміни моделі сесії є спільним станом. Активний runner, команда `/model`, оновлення Compaction/сесії та узгодження живої сесії читають або записують частини одного й того самого запису сесії. Це означає, що повторні спроби резервного переходу мають координуватися з живим перемиканням моделі: - Лише явні зміни моделі, ініційовані користувачем, позначають очікуване живе перемикання. Це включає `/model`, `session_status(model=...)` і `sessions.patch`. - Системні зміни моделі, такі як ротація резервних варіантів, перевизначення Heartbeat або Compaction, самі по собі ніколи не позначають очікуване живе перемикання. - Перевизначення моделі, ініційовані користувачем, вважаються точними виборами для політики резервного переходу, тому недоступний вибраний провайдер показується як збій, а не маскується `agents.defaults.model.fallbacks`. - Перед початком повторної спроби резервного переходу runner відповіді зберігає вибрані поля перевизначення резервного варіанта в записі сесії. - Автоматичні перевизначення резервного варіанта залишаються вибраними в наступних ходах, щоб OpenClaw не перевіряв відому несправну основну модель у кожному повідомленні. OpenClaw періодично знову перевіряє налаштоване джерело та очищає автоматичне перевизначення, коли воно відновлюється; `/new`, `/reset` і `sessions.reset` негайно очищають перевизначення з автоматичного джерела. - Відповіді користувачу оголошують переходи до резервного варіанта та відновлення після очищення резервного варіанта один раз на зміну стану. Ходи з липким резервним варіантом не повторюють сповіщення. - `/status` показує вибрану модель і, коли стан резервного переходу відрізняється, активну резервну модель і причину. - Узгодження живої сесії надає перевагу збереженим перевизначенням сесії над застарілими полями моделі runtime. - Якщо помилка живого перемикання вказує на пізнішого кандидата в активному ланцюжку резервних варіантів, OpenClaw переходить безпосередньо до цієї вибраної моделі замість того, щоб спершу проходити непов’язаних кандидатів. - Якщо спроба резервного переходу зазнає збою, runner відкочує лише ті поля перевизначення, які він записав, і лише якщо вони все ще відповідають цьому невдалому кандидату. Це запобігає класичній гонці: Вибрана основна модель зазнає збою. Кандидата резервного варіанта вибрано в пам’яті. Сховище сесії все ще відображає стару основну модель. Узгодження живої сесії читає застарілий стан сесії. Повторну спробу повертає до старої моделі до початку спроби резервного переходу. Збережене перевизначення резервного варіанта закриває це вікно, а вузький відкат зберігає новіші ручні або runtime-зміни сесії недоторканими. ## Спостережуваність і підсумки збоїв `runWithModelFallback(...)` записує деталі кожної спроби, які живлять журнали та користувацькі повідомлення про період охолодження: - спробуваний провайдер/модель - причина (`rate_limit`, `overloaded`, `billing`, `auth`, `model_not_found` і подібні причини резервного перемикання) - необов’язковий статус/код - зрозумілий людині підсумок помилки Структуровані журнали `model_fallback_decision` також містять плоскі поля `fallbackStep*`, коли кандидат зазнає збою, пропускається або пізніший резервний варіант успішний. Ці поля роблять спробу переходу явною (`fallbackStepFromModel`, `fallbackStepToModel`, `fallbackStepFromFailureReason`, `fallbackStepFromFailureDetail`, `fallbackStepFinalOutcome`), щоб експортери журналів і діагностики могли відтворити збій основної моделі навіть тоді, коли кінцевий резервний варіант також зазнає збою. Коли всі кандидати зазнають збою, OpenClaw викидає `FallbackSummaryError`. Зовнішній runner відповіді може використати це, щоб побудувати конкретніше повідомлення, наприклад "all models are temporarily rate-limited", і включити найближче завершення періоду охолодження, коли воно відоме. Цей підсумок періоду охолодження враховує модель: - непов’язані обмеження частоти на рівні моделі ігноруються для спробуваного ланцюжка провайдер/модель - якщо залишкове блокування є відповідним обмеженням частоти на рівні моделі, OpenClaw повідомляє останній відповідний час завершення, який усе ще блокує цю модель ## Пов’язана конфігурація Див. [Конфігурація Gateway](/uk/gateway/configuration) для: - `auth.profiles` / `auth.order` - `auth.cooldowns.billingBackoffHours` / `auth.cooldowns.billingBackoffHoursByProvider` - `auth.cooldowns.billingMaxHours` / `auth.cooldowns.failureWindowHours` - `auth.cooldowns.overloadedProfileRotations` / `auth.cooldowns.overloadedBackoffMs` - `auth.cooldowns.rateLimitedProfileRotations` - `agents.defaults.model.primary` / `agents.defaults.model.fallbacks` - маршрутизація `agents.defaults.imageModel` Див. [Моделі](/uk/concepts/models), щоб отримати ширший огляд вибору моделі та резервних варіантів.