Files
knowledge-base/decisions/2026-06-20-german-hermes-out-of-usage.md

8.5 KiB
Raw Blame History

date, type, tags
date type tags
2026-06-20 decision
dttb
german
hermes
omniroute
cliproxy
max
out-of-usage
troubleshooting

German (Hermes LXC 141) — 400 out of extra usage на cc/* через OmniRoute

Handoff-документ. Проблема НЕ закрыта полностью на 2026-06-20. Сделаны два смягчающих фикса (привязка аккаунта + retry-патч), но остаточные пики out of usage остаются. Окончательное решение — за Олегом (Extra usage / разгрузка нагрузки). Ниже — всё, чтобы продолжить без повторного прохода по тупикам.

Симптом

German-бот (@german_dttb_bot, Hermes Agent v0.16.0, LXC 141) периодически отвечает ошибкой вместо ответа:

400 - You're out of extra usage. Add more at claude.ai/settings/usage and keep going.

Интермиттентно: ~7-12% запросов cc/* падают, остальные 200. Бот «то работает, то нет».

Что НЕ является причиной (проверено — НЕ тратить время заново)

  1. НЕ баг версии OmniRoute. Обновил 3.8.29 → 3.8.30 (npm install omniroute@latest в /root/.npm/_npx/cb5891f90ae65d14, ExecStart уже dist/server.js). Ошибка осталась. (В 2026-06-09 похожая ошибка реально была багом 3.8.7 — но не в этот раз.)
  2. НЕ реальный лимит подписки Олега. Скриншоты Claude Code Plan usage: 5h-limit 43→53%, Weekly 5-6%, Sonnet 0% — свободно. Олег прав: «лимитов нет».
  3. НЕ размер запроса. Тест: контекст 357K симв (~90K токенов) → 200 на opus-4-7/opus-4-8/sonnet. Размер ни при чём.

Архитектура (как cc/* доходит до Anthropic)

German (LXC 141) → OmniRoute (LXC 132, 10.0.0.179:20128) → cliproxy (/root/.cli-proxy-api:8319) → Anthropic Max OAuth
  • В OmniRoute provider_connections (БД /root/.omniroute/storage.sqlite) — два Claude-аккаунта:
    • e8a70f39-564d-4529-a911-4b5d0a47e512 — priority 1, перегружен: SwarmClaw (8 агентов) + code-server жгут через него ~13К opus-4-8/час → сыпет 400/429/502/529.
    • 883152e1-7160-4d5c-90eb-88822d50db31 = batlaew@gmail.com — рабочий аккаунт Олега (тот, что в скриншоте 53%), свободнее, почти всё 200.
  • Ключи German/openclaw в OmniRoute api_keys: claw и test-key (оба sk-225e902dc95ff… — это и есть OPENAI_API_KEY в /root/.hermes/.env German). SwarmClaw-нагрузка (13К) идёт БЕЗ api_key_name (мастер-путь), отдельно от этих ключей.

Главная диагностическая команда (с неё начинать в будущем)

# на LXC 132 (через pct exec 132 с Proxmox 10.0.0.250 root/1qaz!QAZ):
sqlite3 -column /root/.omniroute/storage.sqlite \
 "SELECT model, account, status, COUNT(*) n FROM call_logs WHERE model LIKE '%opus%' GROUP BY model,account,status ORDER BY n DESC LIMIT 20"

Поля account + status сразу показывают, какой аккаунт сыпет 400 и какой 200. Не гадать про версию/лимит — смотреть сюда.

Что СДЕЛАНО (два смягчающих фикса)

1. Привязка ключей German/openclaw к рабочему аккаунту

Ключи claw/test-key имели пустой allowed_connections → ротация кидала German на перегруженный e8a70f39. Привязал к batlaew:

# на LXC 132. Формат allowed_connections = JSON-массив id (JSON.parse, length>0 ограничивает)
sqlite3 /root/.omniroute/storage.sqlite \
 "UPDATE api_keys SET allowed_connections='[\"883152e1-7160-4d5c-90eb-88822d50db31\"]' WHERE name IN ('claw','test-key')"
systemctl restart omniroute   # сбросить кэш ключей
  • Бэкап БД: /root/.omniroute/storage.sqlite.bak-keybind.
  • Проверено: 10/10 запросов German-ключом → account=batlaew. SwarmClaw не затронут (другой путь).
  • Откат: UPDATE api_keys SET allowed_connections=NULL WHERE name IN ('claw','test-key').

2. Retry-патч Hermes (out-of-usage → retryable)

До патча Hermes считал 400 out of extra usage фатальной (Aborting). Сделал retryable:

  • Файл: /usr/local/lib/hermes-agent/agent/error_classifier.py — добавлен паттерн status_code==400 and "out of extra usage" in error_msg → FailoverReason.rate_limit, retryable=True (перед «── 2. HTTP status code classification»).
  • config.yaml: agent.api_max_retries 3 → 5.
  • Проверено вызовом classify_api_error: на этот текст RETRYABLE=True, обычные 400 остаются non-retryable.
  • Бэкап: error_classifier.py.bak-outofusage. Переналожатель: /root/hermes-patch-outofusage.py — запустить ПОСЛЕ обновления Hermes (патч в коде слетает).

Текущий статус (на 2026-06-20 ~16:00)

  • German отвечает, когда нет пика (проверено в логах: 14:16 inbound ? → ответ; и прямыми тестами все модели 200).
  • В длинные пики (>~50с, ретраи 5×40с не хватает) German всё ещё возвращает ошибку «model provider failed after retries».
  • Пульсация out of usage остаётся на ОБОИХ аккаунтах (e8a70f39 и batlaew) периодически — ДАЖЕ при свободном 5h (53%). Это похоже на burst/моментную механику Anthropic Max, из логов OmniRoute до конца НЕ объяснено.

Что осталось — варианты окончательного решения (ВЫБОР ОЛЕГА)

  1. Extra usage onclaude.ai/settings/usage, секция Extra usage (не Plan usage). Поднять spend limit → overflow в пик оплачивается, out of usage исчезает для ВСЕХ ботов. Самое прямое, платно, в биллинге Олега.
  2. Разгрузить главного пожирателя — SwarmClaw (8 агентов) + code-server с cc/claude-opus-4-8 (~13К/час) на Sonnet/меньше агентов → давление на Max-пул/burst падает.
  3. Восстановить не-Max тракт для German (вывести из Max-пула). На 2026-06-20 ВСЕ мертвы: Kiro (402/нет кредов), Codex (not supported/таймаут), gemini-cli (403 нет лицензии), GLM (429 баланс 0).
  4. Поднять retry-окно German ещё (api_max_retries + backoff) — пережидать и длинные пики, ценой задержки ответа на 1-2 мин (плохой UX).

Связанные факты

Урок (мне на будущее)

Я трижды выдал неверный диагноз (баг версии → реальный лимит → перегрузка пула), прежде чем дошёл до call_logs по account. При out of usage на cc/ — СНАЧАЛА call_logs GROUP BY account,status, потом гипотезы.* См. ../../.claude/projects/-Users-ai-knowledge-base/memory/feedback_root_cause_recurring.