Hogar

Skill

Productividad y flujo de trabajo

stay-within-limits

BuilderIO/skills

Mantenga el trabajo de los agentes de larga duración dentro de los límites de uso quincenal y semanal verificando el consumo entre oleadas, pausando cerca del límite y reanudando solo cuando la ventana esté despejada.

...Expandir todo

Tiempo actualizado 6 de septiembre de 2026

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

Mantenerse dentro de los límites

Mantenga el trabajo prolongado del agente dentro de las ventanas de uso actuales de 5 horas y semanales. Verifique el uso antes de iniciar trabajos sustanciales y entre oleadas de subagentes en paralelo. Si un límite de 5 horas o semanal activo está en o por encima del 95%, pause el nuevo trabajo hasta que la ventana esté lo suficientemente despejada para continuar de forma segura.

Bucle principal

Ejecute una oleada de trabajo acotada. Utilice por defecto como máximo 3 subagentes en paralelo, a menos que el usuario o el anfitrión establezcan un control de velocidad diferente.
Espere a que termine la oleada. No interrumpa los subagentes en curso solo para ahorrar presupuesto; eso suele provocar la pérdida de trabajo.
Verifique el uso actual de 5 horas y semanal con la herramienta de uso/presupuesto del anfitrión.
Si alguna ventana está en o por encima del 95%, deje de lanzar trabajo y programe una reanudación autocontenida cuando la ventana relevante deba despejarse.
Al reanudar, vuelva a verificar la ventana real o el bloqueo antes de continuar. No confíe únicamente en el tiempo transcurrido en el reloj de pared.

Señales de uso

Prefiera una herramienta de uso del anfitrión de primera parte cuando esté disponible. En Claude Code, utilice:

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

Utilice el JSON para identificar el inicio del bloqueo activo, el costo actual o el porcentaje, y el tiempo restante. Al despertar, compare la marca de tiempo del inicio del bloqueo activo con la anterior; una nueva marca de tiempo es una evidencia más sólida que "ha pasado suficiente tiempo".

Si la herramienta informa el costo en lugar de un porcentaje directo, conviértalo a través del límite actual de la cuenta cuando sea conocido. Para los bloques de 5 horas al estilo Claude Max, algunos usuarios prefieren un umbral de precaución anterior alrededor de $500-550; trate eso como una barrera de protección configurada por el usuario, no como una regla universal. La regla de parada predeterminada sigue siendo el 95% del límite activo de 5 horas o semanal.

Pausa y reanudación

Cuando esté disponible una herramienta de despertar/reanudación, programe un despertar para:

min(3600, segundosHastaQueSeDespejeLaVentana)

Si el tiempo de ejecución limita los retrasos de despertar a 60-3600 segundos, encadene despertares para esperas más largas. Cada despertar debe volver a verificar el uso, reprogramar si aún está por encima del presupuesto y continuar solo cuando la ventana esté por debajo de forma segura del umbral.

Haga que las instrucciones de despertar sean autocontenidas. Incluya:

El plan restante.
La regla de verificar y luego reprogramar.
El umbral del 95% y el control de velocidad de la oleada.
El comando de uso exacto o la herramienta de uso del anfitrión a ejecutar.
El identificador del bloque/ventana anterior cuando esté disponible.
Los siguientes pasos de verificación.
Los paquetes de entrega de la siguiente oleada, incluyendo alcance, comandos de verificación y condiciones de parada, si la delegación se reanudará.

Elección del mecanismo de espera

Utilice una herramienta de despertar/reanudación cuando el agente necesite instrucciones adjuntas a la reanudación futura.
Utilice una suspensión en segundo plano o un observador para temporizadores fijos y cosas que un proceso pueda observar directamente.
Utilice cron o horarios recurrentes solo para trabajo de sesión nueva recurrente.

Evite la sondeación de intervalos cortos para cosas de las que el anfitrión le notificará, como la finalización de tareas en segundo plano o de subagentes. Para las pausas presupuestarias, una falta de coincidencia en la cacheta de instrucciones después de una larga suspensión es aceptable; preservar el límite es más importante.

Informes

Si hace una pausa, informe al usuario qué ventana está por encima del umbral, el uso observado, cuándo programó o espera la próxima verificación y qué trabajo queda. Mantenga suficiente estado en la instrucción de despertar para que el siguiente turno pueda reanudar sin depender del impulso de la conversación.

Ver en 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.