---
name: avtero_llm_chain_incident
description: avtero LLM-чейн — 8-й рецидив мёртвых моделей в чейне (413/400/timeout) + omnibus-round-cap баг + повторная смерть gc/grok-composer (model_cooldown) — ВСЁ ЗАКРЫТО, финальный чейн omnibus+codex (2 записи), живьём подтверждён 88.4с; смоук-тест probe_chain_candidate.py; nvidia/cebersresearch проверены и признаны непригодны как 3-й резерв
metadata: 
  node_type: memory
  type: project
  originSessionId: 4eea915e-3b47-4cd5-8a0e-bfa29b78a87c
  modified: 2026-08-13T23:21:46.094Z
---

**2026-08-14 — ЭТА АВАРИЯ ПОВТОРИЛАСЬ В 8-Й РАЗ, и в этот раз нашёл ВТОРОЙ, отдельный корень
(не только «мёртвый чейн»).** Жалоба юзера «краши/не отвечает на сайте». Живой замер latency
прямым вызовом `chat_request` с РЕАЛЬНЫМ system-промптом (39КБ) + tools (не игрушечный
8-токенный пинг, каким его видит `llm_head_monitor.py`!) на боевом чейне
`cerebras/gpt-oss-120b, omnibus/zai-glm-4.5-flash, groq/llama-3.3-70b-versatile,
gc/grok-composer-2.5-fast, codex/gpt-5.4-low, cerebras/zai-glm-4.7` показал: **4 из 6 моделей
гарантированно не работают на реальном payload** — `cerebras/gpt-oss-120b` (первая в чейне!)
зависает 50с+ без чистой ошибки; `groq/llama-3.3-70b-versatile` — 413, TPM-лимит free-tier
12000 vs нужно 18330 (никогда не пройдёт, это НЕ временное); `cerebras/zai-glm-4.7` — 400
context_length_exceeded 16300 vs лимит 8192 (тот же баг, что и в июне-июле, просто вернулся);
`codex` — 429 квота (временное). Живыми оказались ТОЛЬКО `omnibus/zai-glm-4.5-flash` (4-6с) и
`gc/grok-composer-2.5-fast` (13-17с). Т.к. дохлая модель стоит ПЕРВОЙ, она не быстро фейлится,
а зависает — и съедает весь `AVTERO_LLM_BUDGET_SEC` до того, как чейн доберётся до рабочих
моделей → ровно «сайт крашится/не отвечает», хотя формально это graceful no-result, не 500.

**ВТОРОЙ, самостоятельный баг (не в чейне, в коде):** даже после переключения на рабочую
`omnibus`-модель ответ всё равно занимал ~100с — `_eff_cap = GATEWAY_TOOL_ROUNDS if prov_name ==
'gateway' else max_tool_rounds` (orchestrator.py ~2254) капает раунды tool-loop ТОЛЬКО для
`prov_name=='gateway'`; `omnibus` под это не попадает и получает полный `MAX_TOOL_ROUNDS=14`.
Живой прогон показал `tool loop hit cap=14 for model=omnibus:zai/glm-4.5-flash` — 4× search_web
+ 3× search_reviews на ОДНУ деталь, каждый вызов быстрый (3-7с), но 14 раундов = ~100с суммарно.
Модель не тормозит, она просто не умеет вовремя остановиться — то же самое поведение, что уже
описано в комментарии кода для gateway-моделей (mistral и т.п.). **Фикс:** расширил условие на
`('gateway', 'omnibus')` — теперь omnibus тоже капается на 3 раунда.

**Фикс развёрнут (все 3 копии конфига + .env, синхронно — см. гочу ниже про дублирование):**
чейн сокращён до `omnibus:zai/glm-4.5-flash,gateway:gc/grok-composer-2.5-fast,
codex:codex/gpt-5.4-low` (3 записи, ВСЕ подтверждены прямым замером на реальном payload) в
`local.avtero.plist`, `local.avtero-bot.plist`, `local.avtero.llmmon.plist` и `.env` (bootout+
bootstrap для плистов, kickstart -k для кода orchestrator.py). **Живая проверка через
тестовую сессию** (см. [[kodoceh_cabinet_session_probe]], account_id=6): Kia Cerato,
«ТО: масло + фильтры» — **76с чистого результата** (был кэш-хит на первом VIN — пришлось взять
другой VIN, чтобы не смерить кэш вместо реального пути). suite 1151 passed. До фикса — 3.5-7+
минут с частым graceful no-result; после — стабильные ~76с с честным, детальным ответом.

**Почему это ВОСЬМОЙ раз (2026-06-30, 07-02, 07-04×5, 08-03, 08-14) — системная причина
рецидива:** ничто не проверяет чейн ПЕРЕД тем, как модель туда попадёт — ни code review, ни
тест, ни monitoring не гоняют реальный system-промпт+tools через кандидата перед добавлением в
`PROVIDER_CHAT_FALLBACK`. `llm_head_monitor.py` пингует 8 токенами — этого достаточно чтобы
пройти 413/400/зависание НЕ обнаружив их (см. [[avtero_harness_cosmetic_brackets_and_omniroute_uuid]] —
ровно так пропустили prefix-коллизию mistral в прошлый раз). **СДЕЛАНО (2026-08-14, тот же день): `~/Services/avtero/scripts/probe_chain_candidate.py`.**
Two-режимный смоук: (1) `compat` — один вызов с РЕАЛЬНЫМ system-промптом+tools, ловит 413/400/
зависание за секунды; (2) `--full-loop` — реальный `_run_tool_loop` с тем же капом раундов, что
провайдер получит в проде (`_prod_round_cap`, зеркалит `_eff_cap` из orchestrator.py — держать в
синхроне при правке одного из них), ловит «модель не умеет остановиться». Живой прогон: две
живые модели чейна прошли ОБА чека (omnibus 4-12с compat / 3-11с loop; `cerebras/zai-glm-4.7`
корректно упал с тем же телом ошибки, что и в проде — confirms discriminating power). Попутно
вскрыл: `gc/grok-composer-2.5-fast` (второй в чейне) НЕСТАБИЛЕН под full-loop — один прогон упал
ReadTimeout на 71с, повтор прошёл, но за 145.6с (близко к 150с потолку) — рабочий, но слабый
резерв, не кандидат в головные. Usage: `cd ~/Services/avtero && python3
scripts/probe_chain_candidate.py provider:model [...] [--full-loop]`, exit 0/1.

**СРАЗУ ЖЕ окупилось (2026-08-14, тот же день): `gc/grok-composer-2.5-fast` умер ПОВТОРНО, за
часы после того как его же проверка признала рабочим.** Юзер заметил «вроде он больше не
работает» — прогнал `--full-loop` вручную на 4 разных VIN (чтобы не словить кэш-хит на
повторяющемся input, см. грабли ниже): 3 из 4 зависли на полные 150с (TimeoutError), 4-я сразу
получила `429 {"code":"model_cooldown","message":"All credentials for model grok-composer-2.5-fast
are cooling down"}`. Это НЕ флуктуация — весь пул credentials в OmniRoute для этой модели ушёл в
кулдаун (ресурс шины, не баг avtero). **Убрал `gc/grok-composer-2.5-fast` из чейна полностью** (все
4 копии конфига). Текущий чейн: `omnibus:zai/glm-4.5-flash,codex:codex/gpt-5.4-low` (2 записи —
тоньше, чем хотелось бы, но обе честно рабочие/временно-квотированные, не мёртвые).
**Грабля при повторном тестировании одного и того же провайдера:** если гонять
`probe_chain_candidate.py` несколько раз подряд С ОДИНАКОВЫМ input (тот же VIN/work_text), можно
поймать upstream-кэш гейтвея/бота — прогон вернётся за ~0.2с, что физически невозможно для
реального tool-loop с обращением к exist.ru/emex.ru. Для честного повторного замера — **менять
VIN/user-сообщение на каждый прогон**, иначе результат врёт (первый живой замер `gc` на 145.6с был
правдой, но следующие «0.2с успехи» в той же сессии оказались кэш-артефактом, не реальным ответом).
**Открытый вопрос ЗАКРЫТ (тот же день, 2026-08-14): третьего резерва не нашлось.** Проверил
`nvidia:meta/llama-3.3-70b-instruct`, `nvidia:openai/gpt-oss-120b`, `cebersresearch:research/
deepseek-chat` тем же `probe_chain_candidate.py --full-loop`. Все три непригодны, разными
способами: `nvidia:meta/llama-3.3-70b-instruct` — compat проходит (20-32с, медленно), но
full-loop падает ReadTimeout на 85с — не тянет реальный многораундовый tool-calling.
`nvidia:openai/gpt-oss-120b` — падает уже на одиночном вызове (ReadTimeout 60с) через xray-прокси
на mac mini. `cebersresearch:research/deepseek-chat` — самый интересный случай: compat
«проходит» подозрительно быстро (1.2-1.3с для 39КБ промпта!), но full-loop показывает
**0 из 14 раундов, результата нет** — модель/прокси CebersResearch **вообще не использует
параметр `tools`** (в его собственном каталоге `/v1/models` нет флага `tool_calling`, только
`web_search/reasoning/vision` — это research/чат-шлюз, не заточен под function-calling агентов).
Структурная несовместимость, не вопрос скорости или квоты. **Вывод: чейн остаётся
`omnibus:zai/glm-4.5-flash,codex:codex/gpt-5.4-low` (2 записи) — осознанный компромисс, третий
резерв потребует НОВОГО источника (платный ключ / другой провайдер в OmniRoute), не того, что уже
сконфигурировано.**

**ФИНАЛЬНАЯ живая проверка (тот же день, после удаления gc):** тестовая сессия (account_id=6),
свежий VIN `KNAFW411BD5000001` (Kia Cerato 2013, не использовался в этой сессии — без риска
кэш-хита), «ТО: масло + фильтры» → **88.4с, чистый честный результат**: масляный/воздушный
фильтры с корректными пометками «номер не подтверждён — подтвердите», 7-8 проверенных аналогов на
деталь, шайба сливной пробки, спецификация масла. Ноль console/page errors, error boundary не
понадобился. Итог сессии: 8-й рецидив мёртвого чейна закрыт, omnibus-round-cap баг закрыт,
gc-рецидив закрыт, третий резерв изучен и признан невозможным на текущих ресурсах, весь путь
живьём подтверждён на реальном сайте под реальной сессией.

---

**2026-07-04 — codex докопан ДО КОНЦА + встроен last-resort (2 корня, оба вне avtero).** Юзер настоял довести codex до рабочего. Замерами доказал ДВА корня (оба НЕ баги avtero): **(1) медленная генерация выхода** — codex/gpt-5.4-low 40с, 5.5-low 49с, 5.4-mini 195с на полный синтез (вход ни при чём: 180КБ→6.6с); при `LLM_TIMEOUT_SEC=45`/раунд обрезалось → ReadTimeout/битый JSON. **(2) пул codex в OmniRoute rate-лимитит СЕРИЮ вызовов** — полный анализ avtero = 10+ LLM-вызовов за ~40с, пул отбивает 403 в середине. Доказано методом исключения: КАЖДЫЙ отдельный вызов = 200 (68КБ+9 tools=200, tool-история round2=200, 5 параллельных=200, большой вывод=200) — падает только кумулятивная серия. Ровно юзерская заметка «codex жгут квоту пула». **Фиксы в `app/llm.py` (бэкапы bak-codextimeout/bak-codexretry):** поле `Provider.timeout` (+make_client уважает), провайдер `codex`→:20129 `timeout=210` (устранил корень 1), `Provider.retry_403` (codex=1, env CODEX_RETRY_403) — ретраи с бэкоффом на 403. ГРАБЛИ: `retry_403=3` + codex-first = запрос так долго идёт (ретраи×медленно×10 вызовов), что SSE-стрим рвётся (RemoteProtocolError) → откатил на 1. ГРАБЛИ2: обернул forced-final timeout в httpx.Timeout → сломал `test_forced_final_timeout` (ждёт сырой float) → вернул сырой float+max. **Итог: чейн `...cerebras,glm,groq,cerebras-glm,codex:gpt-5.4-low` (codex ПОСЛЕДНИМ)** — нормальный путь 53с depth 0 не задет; codex срабатывает только когда всё легло. codex как ПЕРВИЧНЫЙ/быстрый невозможен: пул 403 на серии + генерация медленная. **Чтобы codex реально работал первичным — поднять квоту/rate пула codex в OmniRoute (сторона юзера), ЛИБО рефактор avtero на single-shot синтез (как CryptoPilot `nim_client.chat_text`, :20127, без tool-loop).** suite 1056 passed (+2 пред-существующих флейка test_e2e_dialog).

**2026-07-04 ФИНАЛ — codex РАБОТАЕТ; корень всей 403-саги = ПРЕФИКС МОДЕЛИ.** Тело 403 (добавил лог `r.text[:300]` в llm.py при 403/429 — оставлен) вскрыло всё: чейн-запись `codex:gpt-5.4-low` слала в OmniRoute модель `gpt-5.4-low` БЕЗ префикса `codex/` → OmniRoute роутил её в ДРУГОЙ коннект с той же моделью — **AIHubMix Free с пустым балансом** («Your account balance is insufficient») → 403. Мои изолированные тесты слали `codex/gpt-5.4-low` С префиксом → шли в настоящий codex → 200. Поэтому «изоляция работает, пайплайн падает» — они звали РАЗНЫЕ бэкенды. **Фикс = `codex:codex/gpt-5.4-low` в чейне (полное имя модели с префиксом).** Вторичный слип: codex-финал чуть мимо схемы (`name` вместо `work_name`, `quality_tier:"m"`) → добавлен `_coerce_schema_slips` в orchestrator (детерминированная нормализация перед pydantic: name→work_name, enum по префиксу; unit-тест прошёл). **Результат: codex-first полный пайплайн 80с depth 0, детали эталонные, все оговорки целы — БЫСТРЕЕ cerebras.** Боевой чейн: `cerebras → codex:codex/gpt-5.4-low → glm-4.5-flash → groq → cerebras-glm` (cerebras первым — бережём codex-квоту, её жжёт и CryptoPilot). Живое подтверждение фолбэка: cerebras упал → codex подхватил depth 1, полный отчёт. suite 1056. У юзера теперь 3 codex-аккаунта × 2 воркспейса = 6 connections (лимиты по-воркспейсно). Дашборд-ручки на будущее: `rateLimitProtection`/`quotaWindowThresholds`/`maxConcurrent` per-connection (PATCH /api/providers/[id]), глобальный `stickyRoundRobinLimit=3` (PATCH /api/settings — трогал, вернул). Урок: ВСЕГДА логируй тело 4xx от шины — неделя диагностики свелась к одной строке.

**2026-07-04 доп. — глубокая отладка нагрузки, 403 НЕ побеждён (УСТАРЕЛО — см. ФИНАЛ выше: корень был префикс модели).** Добавил ещё 2 avtero-фикса в `app/llm.py`: `Provider.max_concurrency` (codex=1, семафор `_provider_sem` сериализует) + `Provider.retry_403` (codex, ретрай с бэкоффом). НЕ помогло. **Замеры:** один анализ = ~2-5 codex-вызовов (счётчик на chat_request через `orchestrator.run`), пути: tool-loop + gap-oem + validation-retry + forced-final. **OmniRoute-дашборд** (:20129/login, POST `/api/auth/login` {password}, cookie auth_token; данные `/api/settings`, `/api/providers` — список connections): codex = **2 аккаунта × 2 воркспейса = 4 connections**, лимиты по-воркспейсно (4 бакета); `stickyRoundRobinLimit=3` (глобальный). Гипотеза: sticky=3 кучкует серию в 1-2 воркспейса → 403. **Тест: выставил sticky=1 (PATCH /api/settings) — codex ВСЁ РАВНО 403 в пайплайне** (потом cerebras Timeout → catalog_fallback). sticky вернул на 3 (общий бас Delor/CebersPost/CryptoPilot). **403 в ИЗОЛЯЦИИ не воспроизводится НИЧЕМ** (одиночный/20-послед/5-парал/3-парал-крупных/sys+9tools/tool-история round2/sticky1-8послед = всё 200 или столл, 0×403); только живой пайплайн 403 стабильно — специфичный burst-паттерн не реплицируется руками. **Вывод: codex остаётся last-resort; для первичного нужны РЕАЛЬНО отдельные аккаунты (не воркспейсы) в пуле codex — 2 текущих аккаунта маргинальны — ЛИБО single-shot рефактор.** Все avtero-фиксы (timeout/семафор/retry) в коде, полезны, suite чист.

**2026-07-04 (v0.7.38) — РЕШЕНИЕ надёжности: GLM CebersPost как keyed-резерв.** По наводке юзера взял GLM, что гоняет CebersPost: `zai/glm-4.5-flash` через **OmniRoute custom-bus :20129** (ключ `OMNIROUTE_API_KEY`=sk-d5…, уже в avtero-плисте; egress НЕ блочит IP как cerebras/groq). Проверено: tools=yes, большой payload 78-180КБ→200 (никакого 413!), JSON в ```-заборах (avtero `_extract_first_json` их снимает). Добавил провайдер `omnibus`→:20129 в `app/llm.py` (`llm.py.bak-omnibus-*`). **Финальный чейн (плист):** `gateway:cerebras/gpt-oss-120b, omnibus:zai/glm-4.5-flash, gateway:groq/llama-3.3-70b-versatile, gateway:cerebras/zai-glm-4.7` — cerebras основной (лучшее качество когда жив), **GLM keyed-резерв (не блочит IP → AI держится, когда cerebras под Cloudflare-403)**, groq последним. Проверено live: GLM форсом (glm-first) гонит полный пайплайн avtero — колодки 581011MA20 +9 аналогов, фильтр 2630035503 +8; финальный чейн — трос 597601M300+оговорка L/R, всё AI ОК. glm-4.6/glm-4.5 на шине таймаутят — только flash. Это закрывает «AI то падает». suite 1058.

**2026-07-04 (v0.7.37) — AI-надёжность = IP-БЛОК free-провайдеров, НЕ payload.** Замер порога groq: даже ОДИН системный промпт (58КБ→67КБ с tools) → **413**; порог groq <40КБ. Урезать промпт до 40КБ = терять модель-специфичное качество (таблицы масел, дизель+коды КПП по маркам — правила 4/16) → НЕ делал (юзер: «без потери качества»). Сделал БЕЗОПАСНЫЙ трим: per-tool cap результатов инструментов (OEM/analog-tools=5000, descriptive=2500; было 8000) — снижает латентность+даёт cerebras запас, OEM не режет. **ГРАБЛИ:** переиспользовал имя `_cap` — а это была переменная КАПА РАУНДОВ цикла → цикл крутился до 5000 (тест `test_tool_loop_forces_final_call_on_max_rounds` поймал: `5001==4`); переименовал в `_res_cap`. suite 1058. **ГЛАВНОЕ:** cerebras/gpt-oss-120b работал утром, к 10:47 → **403 Cloudflare** (IP мини заблокирован) + ReadTimeout; groq → 413/429. Оба free-провайдера **блокируют/лимитируют IP мини** интермиттентно — payload-трим это НЕ чинит. Реальный фикс НАДЁЖНОСТИ = инфра: (а) keyed-провайдер (Gemini/OpenAI-compat, свой ключ, не блочит IP) ЛИБО (б) egress чейна через xray (:2081, не-RU IP) — тогда cerebras/groq не видят RU-IP мини. Каталожные OEM всегда корректны/доступны (fallback) — интермиттит только AI-СЛОЙ (аналоги/заметки). `orchestrator.py.bak-trunc-*`, `.bak-capfix-*`.

**2026-07-04 (v0.7.36) — AI массово в catalog-fallback. РЕШЕНО.** НЕ мёртвые провайдеры — **размер payload**: `SYSTEM_PROMPT=58КБ` + tool-defs 8КБ + накопленный контекст tool-loop = реальное тело ~94КБ+. При таком размере: **cerebras/gpt-oss-120b → 200 ✓** (держит!), cerebras/zai-glm-4.7 → 400 «reduce length» (малый контекст), groq/* → **413 Request too large** (жёсткий лимит free-tier) + 429. На МАЛЕНЬКОМ запросе ВСЕ работают с tool-calling. **ГРАБЛИ диагностики:** шлюз :20128 по умолчанию СТРИМИТ (SSE `data:`) — probe через `r.json()` даёт ложный «не работает/JSONDecodeError»; тестировать с `"stream": false`. **Моя ошибка:** «почистил» чейн, убрав cerebras/gpt-oss-120b — единственную модель, что тянет большой payload → AI не возвращался. **Фикс:** чейн `gateway:cerebras/gpt-oss-120b,gateway:groq/llama-3.3-70b-versatile,gateway:cerebras/zai-glm-4.7,gateway:groq/qwen/qwen3-32b` (cerebras/gpt-oss-120b головной). Проверено live: полный 8-компонентный Cerato #674 → AI ОК, аналоги 8-10/деталь. Юзер был прав — cerebras работает (именно gpt-oss-120b). Долгосрочно: урезать SYSTEM_PROMPT/tool-result cap (8000) для запаса. Alert «All models failed» НЕ сработал (лог «LLM unavailable (RuntimeError)» не матчит греп — вторичный баг). Попутно v0.7.36: note_nf без «бесплатным каталогом»; трос L/R `_PAIRED_SIDE_CATS`. См. [[cerebras_groq_ru_ban]].

**2026-07-02 повтор той же аварии:** подбор снова падал в advisory-only (жидкости без деталей). Чейн в плистах опять указывал на мёртвые модели — `nvidia:*` все **429** (rate-limit ключа), `gateway:fmd/gpt-5.4`→**404** (стало `fmd/gpt-5.5`), `gateway:bynara/mimo-v2.5-pro-free`→**400** (провайдер удалён). Правил чейн в ОБОИХ: `local.avtero.plist` (API) и `local.avtero-bot.plist` (бот) — у них разные чейны, оба битые. Новый (проверял curl→200): `gateway:cerebras/gpt-oss-120b,gateway:cerebras/zai-glm-4.7,gateway:groq/openai/gpt-oss-120b,gateway:groq/llama-3.3-70b-versatile`. Правка через plistlib + bootout/bootstrap. **Проверено:** прямой `POST /api/ask` (cookie+captcha DISABLED) Kia Cerato → колодки OEM 58101-2FA01 (+9 аналогов), масляный фильтр 26300-35503 (+7), confidence=high, ~124с. Также попутно: TecDoc MariaDB на /Volumes/Ext засыпал (pmset disksleep=10 → первый запрос ловил timeout «DB UNREACHABLE») — поставил keepalive `local.avtero.tecdoc-keepalive` (лёгкий SELECT каждые 4 мин). Живые модели :20128 сверять `curl :20128/v1/models`.

**2026-06-30 регрессия: подбор и госномер «крутят 1-2 мин → ошибка».** Корень: `~/Library/LaunchAgents/local.avtero.plist` задаёт `PROVIDER_CHAT_FALLBACK` в `EnvironmentVariables` и **перебивает `.env`**. В плисте остался старый чейн на `gateway:mistral/*`, а OmniRoute (:20128) перестал отдавать mistral → 404 на всех звеньях → **502 `llm_failed`**. Госномер ломался вместе (плитка plate→resolve→подбор-LLM); сам `resolve_plate` (NSIS-капча) жив.

**Гочи деплоя (важно):**
- launchd-плист env **перебивает `.env`** — правь PROVIDER_CHAT_FALLBACK в плисте (или держи синхронно с `.env`).
- `launchctl kickstart -k` **НЕ перечитывает плист** — нужен `bootout gui/$UID/local.avtero` + `bootstrap gui/$UID <plist>`, иначе живой процесс держит старый env. Проверять `ps eww <pid> | grep PROVIDER_CHAT_FALLBACK`.
- Bot-API проверять можно изнутри: `from app import webauth; H={"X-Bot-Auth":webauth.internal_sig(),"X-Bot-User":"8688355181"}` → POST `/api/ask_async` → SSE `/api/jobs/{id}/events` до `event: complete`. Кэш ответа LLM 5 мин — уникаль запрос для холодного замера.

**Рабочий чейн (всё живо на :20128, проверено 200):** `gateway:cerebras/zai-glm-4.7 → gateway:mistral/mistral-medium-latest → gateway:cerebras/gpt-oss-120b → gateway:mistral/mistral-small-latest`, `LLM_GATEWAY_TOOL_ROUNDS=3`. **Выкинуты `nvidia:*` (прокси 2081 мёртв — ReadTimeout даже на тривиале) и `cebersresearch/deepseek` (:20130 → 401)** — они только жрали по 45-60с впустую.

**Латентность ~95-110с на холодный подбор — это норма для текущих free-моделей**, НЕ баг: каждый tool-раунд ~20-30с через гейт × ~3 раунда + per-part emex/catalog lookups + forced-final. cap=6 делало хуже (200с, 6 раундов); cap=3 = баланс. mistral-medium как primary = ещё хуже (~175с): новый mistral-ключ в OmniRoute **rate-limited** (429→503→30с кулдаун, free-tier воркспейса), поэтому он в фолбэке, не головным. Реальное ускорение = платный/быстрый провайдер. Фронт по SSE держит keepalive-пинги (не таймаутит) — 502 был единственной причиной «ошибки». См. [[avtero_api_hardening]] [[avtero_overview]].
