Как не сжечь лимиты в OpenClaw: полный гайд для мультиагентных команд

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

1) Почему лимиты заканчиваются быстрее, чем кажется

• Частые системные события в main-сессии (watchdog/cron) создают лишние LLM-turn’ы.
• Длинные system-промпты тратятся на каждый запуск агента/субагента.
• Повторные retry при 429/401 быстро выедают окно запросов.
• Чтение больших файлов целиком добавляет десятки тысяч токенов в контекст.

2) Главное разделение: контекст и лимиты — не одно и то же

Контекст — это размер текущей истории в окне модели (например, 1M).
Лимиты 5h/day — это квоты аккаунта/авторизации.
Поэтому +60k контекста не обязаны давать «минус 6%» лимита линейно.

3) Антипаттерны, которые сжигают бюджет

1. Watchdog каждые 5 минут через LLM.
2. Кроны в main-сессию вместо isolated/shell.
3. Субагенты на дорогих моделях для рутины.
4. Retry-loop без backoff.
5. Полные файлы в контекст без offset/limit.

4) Рабочая архитектура экономии (без потери сообразительности)

Уровень A — shell-first (почти ноль токенов)

Мониторинги и проверки процессов делаем bash-скриптами. В LLM отправляем только инциденты.

Уровень B — дешёвые модели для рутины

Классификация, парсинг, подготовка черновиков и фоновая обработка — на дешёвых моделях.

Уровень C — сильные модели для решений и качества

Стратегия, архитектура, финальные тексты, критичные коммуникации.

5) Мониторинг по провайдерам: что реально можно видеть

Codex / OAuth

• 5h usage left
• day usage left
• context usage

Anthropic OAT (auth-token)

• статус профиля: ok / rate_limited / auth_error
• last successful response
• частота 429/401 за 1ч и 24ч

Для OAT не всегда доступен прозрачный остаток «daily/weekly» в API-формате, поэтому делаем operational-мониторинг по факту состояния.

6) Fallback-логика при проблемах

• 429 на primary → переключение на secondary.
• повторный 429 → tertiary + увеличенный backoff.
• 401/403 → блок профиля, алерт, переключение на резерв.

7) План внедрения

За 24 часа

• Снизить частоту watchdog-контуров (например, 5/10/15 → 30 минут).
• Убрать лишние LLM-события в main.
• Включить логирование статусов провайдеров и ошибок.
• Настроить fallback при 429/401.

За 7 дней

• Оптимизировать system-промпты (ядро короткое, детали — в файлах).
• Разнести нагрузку по профилям и агентам команды.
• Сделать единый дашборд лимитов/рисков.
• Провести postmortem по инцидентам лимитов.

8) Быстрый чеклист команды (3+ человек)

• Утро: проверка статусов профилей и остатков.
• День: контроль 429/401 по тренду, а не по одному событию.
• Вечер: отчёт по расходу и перенос рутинных задач в shell/ночные батчи.

Итог

Стабильная мультиагентная система строится не «на одном сильном ключе», а на дисциплине архитектуры: меньше лишних turn’ов, прозрачное логирование, fallback-план и регулярный аудит расхода.