Резервные провайдеры

VibeOS имеет три уровня отказоустойчивости, которые поддерживают работу ваших сессий при возникновении проблем у провайдеров:

Пулы учётных данных — ротация между несколькими API-ключами для одного и того же провайдера (проверяется в первую очередь)
Резервирование основной модели — автоматическое переключение на другого провайдера:модель, когда ваша основная модель недоступна
Резервирование вспомогательных задач — независимое разрешение провайдера для побочных задач, таких как анализ изображений, сжатие и извлечение веб-контента

Пулы учётных данных обрабатывают ротацию в рамках одного провайдера (например, несколько ключей OpenRouter). Эта страница описывает переключение между разными провайдерами. Обе функции опциональны и работают независимо.

Резервирование основной модели

Когда ваш основной LLM-провайдер сталкивается с ошибками — ограничениями скорости, перегрузкой сервера, сбоями аутентификации, обрывами соединения — VibeOS может автоматически переключиться на резервную пару провайдер:модель в середине сессии без потери истории разговора.

Конфигурация

Самый простой путь — интерактивный менеджер:

vibeos fallback

vibeos fallback повторно использует выбор провайдера из vibeos model — тот же список провайдеров, те же запросы учётных данных, та же валидация. Используйте подкоманды add, list (псевдоним ls), remove (псевдоним rm) и clear для управления цепочкой. Изменения сохраняются в списке верхнего уровня fallback_providers: в config.yaml.

Если вы предпочитаете редактировать YAML напрямую, добавьте список fallback_providers верхнего уровня в ~/.vibeos/config.yaml:

fallback_providers:
  - provider: openrouter
    model: anthropic/claude-sonnet-4

Каждая запись требует указания как provider, так и model. Записи, в которых отсутствует хотя бы одно из полей, игнорируются.

fallback_model против fallback_providers

fallback_providers (множественное число, список) — это текущая форма конфигурации, поддерживающая несколько резервных вариантов, перебираемых по порядку. fallback_model (единственное число) — это устаревший ключ для одного резервного варианта. VibeOS всё ещё поддерживает его для обратной совместимости, но vibeos fallback записывает текущий ключ fallback_providers и переносит устаревшую конфигурацию при записи. Если установлены оба, приоритет имеет fallback_providers.

Поддерживаемые провайдеры

Провайдер	Значение	Требования
OpenRouter	`openrouter`	`OPENROUTER_API_KEY`
Nous Portal	`nous`	`vibeos setup --portal` (новый) или `vibeos auth add nous` (OAuth)
OpenAI Codex	`openai-codex`	`vibeos model` (ChatGPT OAuth)
GitHub Copilot	`copilot`	`COPILOT_GITHUB_TOKEN`, `GH_TOKEN` или `GITHUB_TOKEN`
GitHub Copilot ACP	`copilot-acp`	Внешний процесс (интеграция с редактором)
Anthropic	`anthropic`	`ANTHROPIC_API_KEY` или учётные данные Claude Code
z.ai / GLM	`zai`	`GLM_API_KEY`
Kimi / Moonshot	`kimi-coding`	`KIMI_API_KEY`
MiniMax	`minimax`	`MINIMAX_API_KEY`
MiniMax (Китай)	`minimax-cn`	`MINIMAX_CN_API_KEY`
DeepSeek	`deepseek`	`DEEPSEEK_API_KEY`
NVIDIA NIM	`nvidia`	`NVIDIA_API_KEY` (опционально: `NVIDIA_BASE_URL`)
GMI Cloud	`gmi`	`GMI_API_KEY` (опционально: `GMI_BASE_URL`)
StepFun	`stepfun`	`STEPFUN_API_KEY` (опционально: `STEPFUN_BASE_URL`)
Ollama Cloud	`ollama-cloud`	`OLLAMA_API_KEY`
Google AI Studio	`gemini`	`GOOGLE_API_KEY` (псевдоним: `GEMINI_API_KEY`)
xAI (Grok)	`xai` (псевдоним `grok`)	`XAI_API_KEY` (опционально: `XAI_BASE_URL`)
xAI Grok OAuth (SuperGrok)	`xai-oauth` (псевдоним `grok-oauth`)	`vibeos model` → xAI Grok OAuth (вход через браузер; подписка SuperGrok)
AWS Bedrock	`bedrock`	Стандартная аутентификация boto3 (`AWS_REGION` + `AWS_PROFILE` или `AWS_ACCESS_KEY_ID`)
Qwen Portal (OAuth)	`qwen-oauth`	`vibeos model` (Qwen Portal OAuth; опционально: `VIBEOS_QWEN_BASE_URL`)
MiniMax (OAuth)	`minimax-oauth`	`vibeos model` (MiniMax portal OAuth)
OpenCode Zen	`opencode-zen`	`OPENCODE_ZEN_API_KEY`
OpenCode Go	`opencode-go`	`OPENCODE_GO_API_KEY`
Kilo Code	`kilocode`	`KILOCODE_API_KEY`
Xiaomi MiMo	`xiaomi`	`XIAOMI_API_KEY`
Arcee AI	`arcee`	`ARCEEAI_API_KEY`
GMI Cloud	`gmi`	`GMI_API_KEY`
Alibaba / DashScope	`alibaba`	`DASHSCOPE_API_KEY`
Alibaba Coding Plan	`alibaba-coding-plan`	`ALIBABA_CODING_PLAN_API_KEY` (возврат к `DASHSCOPE_API_KEY`)
Kimi / Moonshot (Китай)	`kimi-coding-cn`	`KIMI_CN_API_KEY`
StepFun	`stepfun`	`STEPFUN_API_KEY`
Tencent TokenHub	`tencent-tokenhub`	`TOKENHUB_API_KEY`
Microsoft Foundry	`azure-foundry`	`AZURE_FOUNDRY_API_KEY` + `AZURE_FOUNDRY_BASE_URL`
LM Studio (локальный)	`lmstudio`	`LM_API_KEY` (или ничего для локального) + `LM_BASE_URL`
Hugging Face	`huggingface`	`HF_TOKEN`
Пользовательская конечная точка	`custom`	`base_url` + `key_env` (см. ниже)

Резервирование пользовательской конечной точки

Для пользовательской конечной точки, совместимой с OpenAI, добавьте base_url и опционально key_env:

fallback_providers:
  - provider: custom
    model: my-local-model
    base_url: http://localhost:8000/v1
    key_env: MY_LOCAL_KEY            # имя переменной окружения, содержащей API-ключ

Когда срабатывает резервирование

Резервирование активируется автоматически, когда основная модель выдаёт ошибку:

Ограничения скорости (HTTP 429) — после исчерпания попыток повторения
Ошибки сервера (HTTP 500, 502, 503) — после исчерпания попыток повторения
Сбои аутентификации (HTTP 401, 403) — немедленно (повторять бессмысленно)
Не найдено (HTTP 404) — немедленно
Некорректные ответы — когда API неоднократно возвращает повреждённые или пустые ответы

При срабатывании VibeOS:

Разрешает учётные данные для резервного провайдера
Создаёт новый API-клиент
Заменяет модель, провайдера и клиент на месте
Сбрасывает счётчик повторных попыток и продолжает разговор

Переключение происходит незаметно — история вашего разговора, вызовы инструментов и контекст сохраняются. Агент продолжает ровно с того места, где остановился, просто используя другую модель.

Пошагово, а не по сессиям

Резервирование действует в рамках одного шага: каждое новое сообщение пользователя начинается с восстановления основной модели. Если основная модель выходит из строя во время шага, резервирование активируется только для этого шага. При следующем сообщении VibeOS снова пытается использовать основную модель. В рамках одного шага резервирование срабатывает не более одного раза — если резервный вариант также выходит из строя, вступает в силу обычная обработка ошибок (повторные попытки, затем сообщение об ошибке). Это предотвращает каскадные циклы переключения в рамках одного шага, давая основной модели новый шанс на каждом шаге.

Примеры

OpenRouter как резервный для Anthropic native:

model:
  provider: anthropic
  default: claude-sonnet-4-6

fallback_providers:
  - provider: openrouter
    model: anthropic/claude-sonnet-4

Nous Portal как резервный для OpenRouter:

model:
  provider: openrouter
  default: anthropic/claude-opus-4

fallback_providers:
  - provider: nous
    model: nous-vibeos-3

Локальная модель как резервная для облачной:

fallback_providers:
  - provider: custom
    model: llama-3.1-70b
    base_url: http://localhost:8000/v1
    key_env: LOCAL_API_KEY

OpenAI ChatGPT как резервный:

fallback_providers:
  - provider: chatgpt-oauth
    model: gpt-5.3-codex

Где работает резервирование

Контекст	Резервирование поддерживается
CLI-сессии	✔
Шлюз обмена сообщениями (Telegram, Discord и т.д.)	✔
Делегирование субагентам	✔ (субагенты наследуют цепочку резервирования родителя)
Cron-задачи	✔ (cron-агенты наследуют настроенные резервные провайдеры)
Вспомогательные задачи с `provider: auto`	✔ (сначала пробуется резервирование для конкретной задачи, затем основная цепочка резервирования перед встроенным обнаружением вспомогательных провайдеров)

подсказка

Для основной цепочки резервирования не существует переменных окружения — настраивайте её исключительно через config.yaml или vibeos fallback. Это сделано намеренно: конфигурация резервирования — это осознанный выбор, а не то, что может переопределить устаревший экспорт оболочки.

Резервирование вспомогательных задач

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

Задачи с независимым разрешением провайдера

Задача	Что делает	Ключ конфигурации
Vision	Анализ изображений, скриншоты браузера	`auxiliary.vision`
Web Extract	Суммаризация веб-страниц	`auxiliary.web_extract`
Compression	Суммаризация для сжатия контекста	`auxiliary.compression`
Skills Hub	Поиск и обнаружение навыков	`auxiliary.skills_hub`
MCP	Вспомогательные операции MCP	`auxiliary.mcp`
Approval	Классификация для умного подтверждения команд	`auxiliary.approval`
Title Generation	Суммаризация заголовков сессий	`auxiliary.title_generation`
Triage Specifier	`vibeos kanban specify` / кнопка ✨ в панели — превращает однострочную задачу триажа в полноценную спецификацию	`auxiliary.triage_specifier`

Цепочка автообнаружения

Когда для провайдера задачи установлено значение "auto" (по умолчанию), VibeOS сначала пытается использовать основного провайдера + основную модель для этой вспомогательной задачи. Если этот маршрут недоступен или впоследствии выходит из строя с ошибкой типа «недостаточно ёмкости», VibeOS теперь учитывает настроенную пользователем политику резервирования перед использованием встроенной цепочки обнаружения:

Основной провайдер + основная модель → auxiliary.<task>.fallback_chain →
fallback_providers / fallback_model → встроенная цепочка обнаружения вспомогательных провайдеров

Цепочка для конкретной задачи является наиболее точной и имеет приоритет при её наличии. Цепочка fallback_providers верхнего уровня — это та же политика, которую использует основной агент, поэтому правила резервирования только для бесплатных или для того же провайдера применяются и к вспомогательным задачам в режиме auto.

Встроенная цепочка обнаружения для текста (сжатие, извлечение веб-контента, генерация заголовков и т.д.):

OpenRouter → Nous Portal → Пользовательская конечная точка → OpenAI ChatGPT →
Провайдеры с API-ключами (z.ai, Kimi, MiniMax, Xiaomi MiMo, Hugging Face, Anthropic) → отказ

Встроенная цепочка обнаружения для Vision:

Основной провайдер (если поддерживает vision) → OpenRouter → Nous Portal →
OpenAI ChatGPT → Anthropic → Пользовательская конечная точка → отказ

Эти встроенные цепочки являются удобным резервным вариантом для пользователей, которые не объявили политику резервирования для конкретной задачи или основную политику.

Настройка вспомогательных провайдеров

Каждая задача может быть настроена независимо в config.yaml:

auxiliary:
  vision:
    provider: "auto"              # auto | openrouter | nous | codex | main | anthropic
    model: ""                     # например "openai/gpt-4o"
    base_url: ""                  # прямая конечная точка (имеет приоритет над provider)
    api_key: ""                   # API-ключ для base_url

  web_extract:
    provider: "auto"
    model: ""

  compression:
    provider: "auto"
    model: ""
    fallback_chain:              # опционально, политика резервирования для конкретной задачи
      - provider: openrouter
        model: inclusionai/ring-2.6-1t:free

  skills_hub:
    provider: "auto"
    model: ""

  mcp:
    provider: "auto"
    model: ""

Каждая задача выше следует тому же шаблону provider / model / base_url. Каждая задача также может объявить свою собственную fallback_chain; если она опущена, provider: auto использует цепочку fallback_providers верхнего уровня перед встроенной цепочкой обнаружения вспомогательных провайдеров VibeOS.

Сжатие контекста настраивается в разделе auxiliary.compression:

auxiliary:
  compression:
    provider: main                                    # Те же опции провайдера, что и для других вспомогательных задач
    model: google/gemini-3-flash-preview
    base_url: null                                    # Пользовательская конечная точка, совместимая с OpenAI

А основная цепочка резервирования использует:

fallback_providers:
  - provider: openrouter
    model: anthropic/claude-sonnet-4
    # base_url: http://localhost:8000/v1             # Опциональная пользовательская конечная точка

Все три — вспомогательные, сжатие, резервирование — работают одинаково: установите provider, чтобы выбрать, кто обрабатывает запрос, model, чтобы выбрать модель, и base_url, чтобы указать пользовательскую конечную точку (переопределяет провайдера).

Опции провайдера для вспомогательных задач

Эти опции применяются только к записям auxiliary:, compression: и fallback_providers: — "main" не является допустимым значением для вашего model.provider верхнего уровня. Для пользовательских конечных точек используйте provider: custom в разделе model: (см. AI Провайдеры).

Провайдер	Описание	Требования
`"auto"`	Перебирать провайдеров по порядку, пока один не сработает (по умолчанию)	Настроен хотя бы один провайдер
`"openrouter"`	Принудительно использовать OpenRouter	`OPENROUTER_API_KEY`
`"nous"`	Принудительно использовать Nous Portal	`vibeos auth`
`"codex"`	Принудительно использовать маршрут OpenAI ChatGPT	`vibeos auth add chatgpt-oauth`
`"main"`	Использовать того же провайдера, что и основной агент (только для вспомогательных задач)	Активный основной провайдер настроен
`"anthropic"`	Принудительно использовать Anthropic native	`ANTHROPIC_API_KEY` или учётные данные Claude Code

Прямое переопределение конечной точки

Для любой вспомогательной задачи установка base_url обходит разрешение провайдера и отправляет запросы напрямую на эту конечную точку:

auxiliary:
  vision:
    base_url: "http://localhost:1234/v1"
    api_key: "local-key"
    model: "qwen2.5-vl"

base_url имеет приоритет над provider. VibeOS использует настроенный api_key для аутентификации, возвращаясь к OPENAI_API_KEY, если он не установлен. Он не использует повторно OPENROUTER_API_KEY для пользовательских конечных точек.

Резервирование при ошибках ёмкости вспомогательных задач

Когда вы устанавливаете явного вспомогательного провайдера (например, auxiliary.vision.provider: glm), VibeOS рассматривает его как ваш предпочтительный выбор. Но если провайдер буквально не может обслужить запрос из-за ошибки ёмкости (HTTP 402 требуется оплата, HTTP 429 дневная квота исчерпана, сбой соединения), VibeOS переключается на многоуровневую цепочку вместо того, чтобы молча завершиться ошибкой:

Основной вспомогательный провайдер — тот, который вы настроили (проверяется первым, всегда)
auxiliary.<task>.fallback_chain — ваш список переопределения для конкретной задачи, если вы его написали
Провайдер + модель основного агента — страховочная сетка в крайнем случае (всегда проверяется, даже если вы не написали цепочку)
Предупреждение + повторное возбуждение — если каждый уровень не удался, VibeOS записывает Auxiliary <task>: ... all fallbacks exhausted на уровне WARNING и повторно возбуждает исходную ошибку

Временные ограничения скорости HTTP 429 (Retry-After: ...) рассматриваются как ограничения запроса, а не проблемы с ёмкостью — они уважают ваш явный выбор провайдера и не запускают лестницу резервирования. Только исчерпание дневной/месячной квоты, ошибки оплаты и сбои соединения обходят шлюз явного провайдера.

Для пользователей с provider: auto (без явного вспомогательного провайдера) существующая цепочка автообнаружения запускается вместо шагов 2–3. Её первым шагом уже является модель основного агента, поэтому пользователи auto получают тот же результат с нулевой конфигурацией.

Опционально: цепочка резервирования для конкретной задачи

Если вы хотите другой порядок резервирования, отличный от «сначала модель основного агента», настройте fallback_chain явно. Каждая запись должна содержать как минимум provider; model, base_url и api_key опциональны.

auxiliary:
  vision:
    provider: glm
    model: glm-4v-flash
    fallback_chain:
      - provider: openrouter
        model: google/gemini-3-flash-preview
      - provider: nous
        model: anthropic/claude-sonnet-4

  compression:
    provider: openrouter
    fallback_chain:
      - provider: openai
        model: gpt-4o-mini

Вам не нужно настраивать fallback_chain, чтобы получить резервирование — страховочная сетка основного агента работает в любом случае. Используйте её только тогда, когда вам нужен другой порядок, отличный от стандартного.

Ошибки квоты провайдера, запускающие резервирование

VibeOS распознаёт следующие ошибки как эквивалентные исчерпанию кредитов 402 (а не временным ограничениям скорости):

Bedrock / LiteLLM: Too many tokens per day, daily limit, tokens per day
Vertex AI / GCP: quota exceeded, resource exhausted, RESOURCE_EXHAUSTED
Общие: daily quota, quota_exceeded

Если ваш провайдер возвращает другую фразу для исчерпания дневной квоты и VibeOS не запускает резервирование, это ошибка — откройте issue с точной строкой ошибки.

Резервирование сжатия контекста

Сжатие контекста использует блок конфигурации auxiliary.compression для управления тем, какая модель и провайдер обрабатывают суммаризацию:

auxiliary:
  compression:
    provider: "auto"                              # auto | openrouter | nous | main
    model: "google/gemini-3-flash-preview"

Миграция устаревших настроек

Старые конфигурации с compression.summary_model / compression.summary_provider / compression.summary_base_url автоматически переносятся в auxiliary.compression.* при первой загрузке (версия конфига 17).

Если для сжатия недоступен ни один провайдер, VibeOS отбрасывает промежуточные витки разговора без создания суммаризации, а не завершает сессию ошибкой.

Переопределение провайдера делегирования

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

delegation:
  provider: "openrouter"                      # переопределение провайдера для всех субагентов
  model: "google/gemini-3-flash-preview"      # переопределение модели
  # base_url: "http://localhost:1234/v1"      # или используйте прямую конечную точку
  # api_key: "local-key"

См. Делегирование субагентам для получения полной информации о конфигурации.

Провайдеры Cron-задач

Cron-задачи наследуют настроенную цепочку fallback_providers (или устаревшую fallback_model) при создании агента. Чтобы использовать другого основного провайдера для cron-задачи, настройте переопределения provider и model в самой cron-задаче:

cronjob(
    action="create",
    schedule="every 2h",
    prompt="Check server status",
    provider="openrouter",
    model="google/gemini-3-flash-preview"
)

См. Запланированные задачи (Cron) для получения полной информации о конфигурации.

Сводка

Функция	Механизм резервирования	Расположение конфигурации
Модель основного агента	`fallback_providers` в config.yaml — пошаговое переключение при ошибках (основная модель восстанавливается на каждом шаге)	`fallback_providers:` (список верхнего уровня)
Вспомогательные задачи (любые) — пользователи `auto`	Полная цепочка автообнаружения (сначала модель основного агента, затем цепочка провайдеров) при ошибках ёмкости	`auxiliary.<task>.provider: auto`
Вспомогательные задачи (любые) — явный провайдер	`fallback_chain` (если задана) → модель основного агента → предупреждение + возбуждение, только при ошибках ёмкости	`auxiliary.<task>.fallback_chain`
Vision	Многоуровневая (см. выше) + внутренняя повторная попытка OpenRouter	`auxiliary.vision`
Извлечение веб-контента	Многоуровневая (см. выше) + внутренняя повторная попытка OpenRouter	`auxiliary.web_extract`
Сжатие контекста	Многоуровневая (см. выше); деградирует до отсутствия суммаризации, если все уровни недоступны	`auxiliary.compression`
Skills hub	Многоуровневая (см. выше)	`auxiliary.skills_hub`
MCP-помощники	Многоуровневая (см. выше)	`auxiliary.mcp`
Классификация подтверждений	Многоуровневая (см. выше)	`auxiliary.approval`
Генерация заголовков	Многоуровневая (см. выше)	`auxiliary.title_generation`
Спецификатор триажа	Многоуровневая (см. выше)	`auxiliary.triage_specifier`
Делегирование	Только переопределение провайдера (без автоматического резервирования)	`delegation.provider` / `delegation.model`
Cron-задачи	Только переопределение провайдера для каждой задачи (без автоматического резервирования)	`provider` / `model` для каждой задачи

Резервирование основной модели​

Конфигурация​

Поддерживаемые провайдеры​

Резервирование пользовательской конечной точки​

Когда срабатывает резервирование​

Примеры​

Где работает резервирование​

Резервирование вспомогательных задач​

Задачи с независимым разрешением провайдера​

Цепочка автообнаружения​

Настройка вспомогательных провайдеров​

Опции провайдера для вспомогательных задач​

Прямое переопределение конечной точки​

Резервирование при ошибках ёмкости вспомогательных задач​

Опционально: цепочка резервирования для конкретной задачи​

Ошибки квоты провайдера, запускающие резервирование​

Резервирование сжатия контекста​

Переопределение провайдера делегирования​

Провайдеры Cron-задач​

Сводка​