diff --git a/projects/dttb/openclaw.md b/projects/dttb/openclaw.md
index 1763e4e..0e82dc5 100644
--- a/projects/dttb/openclaw.md
+++ b/projects/dttb/openclaw.md
@@ -312,6 +312,59 @@ systemctl --user restart openclaw-gateway.service
 
 **Реальная причина периодических "Something went wrong" — IPv6**, не провайдеры моделей. См. раздел выше про `NODE_OPTIONS=--dns-result-order=ipv4first`. FailoverError `kr/...` → `zai/kr/...` — это автофоллбек который работает, не трогай.
 
+### Проблема: "Something went wrong" после очистки каталога моделей (2026-04-18)
+
+Если в `openclaw.json → models.providers.zai.models` удалить какую-то модель (например `cx/gpt-5.4`), **существующие сессии** в `sessions.json` с захардкоженной удалённой моделью начинают падать:
+```
+FailoverError: Unknown model: cx/gpt-5.4 (model_not_found)
+All models failed: ... | Unknown model: cx/gpt-5.4
+```
+Бот возвращает "Something went wrong". Дефолт `agents.defaults.model` **не влияет на существующие сессии** — они хранят `model` внутри `sessions.json` при создании.
+
+**Лечение:** попросить пользователя в Максимке нажать `/new` — новая сессия возьмёт актуальную default модель. Sessions.json руками не править — это ломает бота (проверено 2026-04-17).
+
+### Проблема: Kiro массово возвращает 402 "You have reached the limit" (исчерпан месячный кредит AWS)
+
+**Симптомы:**
+- В `call_logs` дневная нагрузка сегодня меньше обычной, но внезапно 402
+- `provider_connections.test_status = credits_exhausted` на обеих Kiro-учётках одновременно
+- OmniRoute на `/v1/chat/completions` для `kr/*` возвращает `No credentials for provider: kiro` (после backoff)
+
+**Причина:** Kiro использует CodeWhisperer через AWS Free Tier с **месячным кредитным лимитом**, не суточным. За неделю обычно ~120M tok_in / 2 учётки = ~60M/учётку → за 3-4 недели квота выбирается.
+
+**Сброс:** месячный reset AWS — **1-е число месяца 00:00 UTC**. До этого дня учётка не работает.
+
+**Диагностика капасити через storage.sqlite:**
+```sql
+SELECT date(timestamp) AS day, COUNT(*) AS calls, SUM(tokens_in) AS tok
+FROM call_logs WHERE provider='kiro' AND status=200
+GROUP BY date(timestamp) ORDER BY day DESC LIMIT 14;
+```
+
+**Ручной сброс флага `credits_exhausted` НЕ помогает** — OmniRoute снимает его, делает первый запрос, получает 402 и сразу возвращает в backoff. Это не визуальный глюк, это реальный отказ от upstream Kiro.
+
+**Решение:** добавить новые Kiro OAuth-учётки через OmniRoute UI. Нужна свежая Google-учётка для каждой (Kiro логинится только через Google SSO); OR создаст новую запись в `provider_connections`, существующие gmail перезаписывает. Одна Kiro-учётка даёт ~250-300M токенов в месяц — этого хватает на ~277 вызовов/день текущей нагрузки бота почти в одиночку.
+
+### Проблема: cx/gpt-5.4 учётки быстро упираются в 429
+
+**Codex free plan** (`workspacePlanType":"free"` в `provider_specific_data`) — **rolling ~3-часовое окно** на учётку, ~10-15 успешных запросов за окно. Не ChatGPT Plus!
+
+7 учёток в ротации дают ~120 успехов/сутки суммарно при равномерной нагрузке (из исторических call_logs 2026-04-11..12). Этого не хватает чтобы нести основной трафик бота (~450 вызовов/день).
+
+**Вывод:** cx — только как резерв, primary оставлять на Kiro.
+
+### Как добавить новую Kiro/OpenClaw-учётку через OmniRoute UI
+
+1. OmniRoute **не проксирован через NPM** (проверено 2026-04-18) — только прямой доступ по `http://10.0.0.179:20128` из LAN/NetBird, или SSH-туннель:
+   ```bash
+   sshpass -p '1qaz!QAZ' ssh -L 20128:10.0.0.179:20128 root@10.0.0.250 -N
+   # открывать http://localhost:20128
+   ```
+   Для долгосрочного использования — добавить `or.dttb.ru` в NPM (WS support ON для OAuth device-code).
+2. В OR UI → Providers → Kiro → **+ Add connection**.
+3. Получить OAuth device-code, открыть ссылку в **приватной вкладке / отдельном Chrome-профиле** (чтобы Google не подставил основной аккаунт), залогиниться новой Google-учёткой, Allow.
+4. Проверка: `sqlite3 /root/.omniroute/storage.sqlite "SELECT COUNT(*) FROM provider_connections WHERE provider='kiro';"` — должен увеличиться.
+
 ### Проблема: CPU/load высокий
 В LXC 137 `/proc/loadavg` показывает **нагрузку хоста Proxmox**, не контейнера. Смотри реальную нагрузку через `top`/`ps aux --sort=-%cpu` внутри контейнера.