Дом

Skill

Производительность и рабочий процесс

stay-within-limits

BuilderIO/skills

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

...Расширить все

Обновлено время 6 сентября 2026 г.

# Claude Code # rate limiting # agent orchestration # budget management # ccusage # pause resume # usage limits

Соблюдать установленные лимиты

Выполняйте длительную работу агентов в рамках текущих 5-часовых и недельных окон использования. Проверяйте использование перед запуском значительной работы и между волнами параллельных подагентов. Если активный 5-часовой или недельный лимит достиг или превысил 95%, приостановите запуск новой работы до тех пор, пока окно не станет достаточно свободным для безопасного продолжения.

Основной цикл

Выполните ограниченную волну работы. По умолчанию используйте не более 3 параллельных подагентов, если только пользователь или хост не установят другое ограничение.
Дождитесь завершения волны. Не прерывайте выполняющиеся подагенты только ради экономии бюджета; это обычно приводит к потере работы.
Проверьте текущее 5-часовое и недельное использование с помощью инструмента использования/бюджета хоста.
Если какое-либо из окон достигло или превысило 95%, прекратите запуск работы и запланируйте автономное возобновление на момент, когда соответствующее окно должно освободиться.
При возобновлении повторно проверьте реальное окно или блок перед продолжением. Не полагайтесь только на прошедшее время по настенным часам.

Сигналы использования

Предпочитайте использовать официальный инструмент использования хоста, когда он доступен. В Claude Code используйте:

npx -y ccusage@latest blocks --active --json

Используйте JSON для определения времени начала активного блока, текущей стоимости или процента, а также оставшегося времени. При пробуждении сравните временную метку начала активного блока с предыдущей; новая временная метка является более надежным доказательством, чем «прошло достаточно времени».

Если инструмент сообщает о стоимости вместо прямого процента, преобразуйте значение через текущий лимит аккаунта, если он известен. Для 5-часовых блоков в стиле Claude Max некоторые пользователи предпочитают более ранний порог предупреждения около 500–550 долларов; относитесь к этому как к пользовательскому защитному механизму, а не как к универсальному правилу. Правило остановки по умолчанию остается на уровне 95% от активного 5-часового или недельного лимита.

Приостановка и возобновление

Когда доступен инструмент пробуждения/возобновления, запланируйте пробуждение на:

min(3600, secondsUntilWindowClears)

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

Сделайте промпты пробуждения самодостаточными. Включите:

Оставшийся план.
Правило проверки и переназначения.
Порог 95% и ограничение волны.
Точную команду использования или инструмент использования хоста для запуска.
Идентификатор предыдущего блока/окна, если он доступен.
Следующие шаги проверки.
Пакеты передачи следующей волны, включая область действия, команды проверки и условия остановки, если делегирование будет продолжено.

Выбор механизма ожидания

Используйте инструмент пробуждения/возобновления, когда агенту нужны инструкции, прикрепленные к будущему возобновлению.
Используйте фоновый сон или наблюдатель для фиксированных таймеров и вещей, которые процесс может наблюдать напрямую.
Используйте cron или повторяющиеся расписания только для повторяющейся работы в новых сессиях.

Избегайте опроса с короткими интервалами для вещей, о которых хост уведомит вас сам, таких как завершение фоновых задач или подагентов. Для пауз бюджета промах кэша промптов после длительного сна допустим; сохранение лимита имеет большее значение.

Отчетность

Если вы приостанавливаете работу, сообщите пользователю, какое окно превысило порог, наблюдаемое использование, когда вы запланировали или ожидаете следующую проверку и какая работа осталась. Сохраните достаточно состояния в промпте пробуждения, чтобы следующий ход мог возобновиться без reliance на импульс разговора.

Посмотреть на GitHub

---
name: stay-within-limits
description: Keep long-running agent work within 5-hour and weekly usage limits by checking usage between waves, pausing near the cap, and resuming only when the window is clear.
---

# Stay Within Limits

Keep long-running agent work inside the current 5-hour and weekly usage windows.
Check usage before launching substantial work and between waves of parallel
subagents. If an active 5-hour or weekly limit is at or above 95%, pause new
work until the window is clear enough to continue safely.

## Core Loop

1. Run a bounded wave of work. Default to at most 3 parallel subagents unless
   the user or host gives a different throttle.
2. Wait for the wave to finish. Do not interrupt in-flight subagents just to
   save budget; that usually loses work.
3. Check current 5-hour and weekly usage with the host's usage/budget tool.
4. If either window is at or above 95%, stop launching work and schedule a
   self-contained resume when the relevant window should clear.
5. On resume, re-check the real window or block before continuing. Do not trust
   elapsed wall-clock time alone.

## Usage Signals

Prefer a first-party host usage tool when available. In Claude Code, use:

```sh
npx -y ccusage@latest blocks --active --json
```

Use the JSON to identify the active block start, current cost or percentage, and
time remaining. On wake, compare the active block start timestamp with the
previous one; a new timestamp is stronger evidence than "enough time passed."

If the tool reports cost instead of a direct percentage, convert through the
current account limit when known. For Claude Max-style 5-hour blocks, some users
prefer an earlier caution threshold around $500-550; treat that as a
user-configured guardrail, not a universal rule. The default stop rule is still
95% of the active 5-hour or weekly limit.

## Pausing And Resuming

When a wake/resume tool is available, schedule a wakeup for:

```txt
min(3600, secondsUntilWindowClears)
```

If the runtime clamps wake delays to 60-3600 seconds, chain wakeups for longer
waits. Each wakeup should re-check usage, reschedule if still over budget, and
continue only when the window is safely below the threshold.

Make wake prompts self-contained. Include:

- The remaining plan.
- The check-then-reschedule rule.
- The 95% threshold and wave throttle.
- The exact usage command or host usage tool to run.
- The previous block/window identifier when available.
- The next verification steps.
- The next wave's handoff packets, including scope, verification commands, and
  stop conditions, if delegation will resume.

## Choosing The Wait Mechanism

- Use a wake/resume tool when the agent needs instructions attached to the
  future resume.
- Use a background sleep or watcher for fixed timers and things a process can
  observe directly.
- Use cron or recurring schedules only for recurring fresh-session work.

Avoid short-interval polling for things the host will notify you about, such as
background task or subagent completion. For budget pauses, a prompt-cache miss
after a long sleep is acceptable; preserving the limit matters more.

## Reporting

If you pause, tell the user which window is over threshold, the observed usage,
when you scheduled or expect the next check, and what work remains. Keep enough
state in the wake prompt that the next turn can resume without relying on
conversation momentum.