Run more Claude Code agents without hitting your plan's limit

By Mackenzie Bowes · mackenzie@mackenziebowes.com · @_mackenziebowes on X

paceline is a small Rust CLI that tells a lead agent LAUNCH or WAIT before it starts another agent. It paces the weekly limit along a line to the reset and keeps the 5-hour window under a cap. Why we built it, the rule we changed twice, and the install.

Contents

At 00:12 on 2026-10-17 my writing agent started nine headless sessions to judge drafts: 943 Claude Opus calls. Nothing checked the plan between batches. The 5-hour window went from 3% to 48%, and the week stood at 53% against a pace of 46%. The gate told every agent on the machine to wait until 13:56 that afternoon. The lesson the lead wrote down: an agent that fans out calls needs the gate inside its loop, not only before it starts.

A Claude Code subscription has two limits, a 5-hour window and a weekly cap. Hit either one and your agents stop mid-task. Stay far under both and you've paid for work nobody did. paceline is the check we run between the two.

A portcullis stands on a road with four small agent blocks queued in front of it. A bar above shows the week's allowance, 53% filled, with a thin pace-line marker at 46%. The gate is down and labelled WAIT. The marker slides right past the end of the fill, the gate lifts and is labelled LAUNCH, and the four blocks pass through one by one.

paceline compares the week's use with an even pace line. Over the line the gate says WAIT; once the line passes, LAUNCH.

How it decides

Before a lead starts another agent, it runs paceline gate. This is an example of the output after a few hours of readings:

$ paceline gate
LAUNCH
week 58% used, pace line 62.3% (69% of the week gone, target 90%, resets Tue 11:00)
5h 1% (cap 70%, resets Sun 11:40)
burn 1.20 %/h over 2.5 h; sustainable 0.85 %/h; running agents 3
  per agent 0.400 %/h -> the week affords ~2.1 continuous agents

The weekly limit against a pace line. The line rises evenly from 0 at the reset to your target (90% by default) at the next reset. Over the line: WAIT until it catches up. Under it: the plan is going unused, so LAUNCH.
The 5-hour window against a cap (70% by default). An agent that hits the limit stops mid-task, so the gate stops launching first.
The burn line. It measures your spend per hour over the last few hours and says how many agents the week can afford to run without stopping.

Exit codes are 0 LAUNCH, 1 WAIT and 2 no fresh reading, so a script can branch on it.

Two bars with a marker each. The week bar fills to 58% with the pace line at 62.3%; the 5-hour bar fills to 1% with its cap at 70%. Both fills stop under their markers and the verdict under them reads: under both lines: LAUNCH.

The gate reads two bars: the week against its pace line, the 5-hour window against its cap.

The rule we changed twice

Right after a weekly reset the pace line is near zero, so a few percent of use puts you over it and the gate says WAIT. That is wrong, so I asked for a first-day exception.

Yea, I guess let's update the global CLAUDE.md that for the first day after a reset, we ignore the weekly pace and follow the first 5-hour window's pace.

Mackenzie, 2026-10-13 13:07

We first set the exception to five hours. That afternoon an agent hit WAIT with four hours to go. Its cache lasts an hour, and reloading all its context costs more than the wait saves.

thing is that 20:20 is like... 4 hours away. Your cache window is 1 hour. If I release you, there is so much context to load back in... so... can we revert that 5 hour rule to be 24 hours again <3

Mackenzie, 2026-10-13 16:32

So for the first 24 hours after a reset, paceline follows only the 5-hour cap (--first-day 24).

A week-long bar. A short red stretch at its start, 5 hours, is labelled: the agent waits, its cache goes cold. It stretches to a green first day, labelled: 24 hours: only the 5-hour cap decides.

For the first 24 hours after a reset the weekly pace is ignored and only the 5-hour cap decides.

What's hard

It only sees launches. My 943 calls came from one session that passed the gate once and then fanned out. A loop that fans out calls should run paceline gate between batches, not only before it starts.

It needs a fresh reading. The reading comes from the status line, so it goes stale 15 minutes after the last message in any session. Then the gate exits 2 rather than guess. Send one message and it has a reading again.

The burn line needs an hour. Until it has an hour of readings from the last three, it prints burn: calibrating (0 min of samples, need 60), and only the pace line and the cap decide.

Two lanes of small blocks moving right. In the first lane, one gate stands at the start and the blocks stream past it, labelled gate once, then fan out: 943 calls. In the second lane, gates stand between batches and each batch passes in turn, labelled gate between batches.

paceline only sees launches, so a loop that fans out should check between batches.

Try it yourself

Three boxes in a row: status line, paceline, lead agent. Small beads carry readings from the status line into paceline. Then a bead goes back from the lead agent to paceline and the answer, LAUNCH or WAIT, lights below.

Every message saves a reading; the lead asks paceline before it launches.

Install it:

cargo install --git https://github.com/mackenziebowes/paceline

Make it your status line in ~/.claude/settings.json. Claude Code passes its rate-limit reading to the status line, and paceline saves each one and prints 5h 12% · 7d 40% · Opus 5.5:
```
{ "statusLine": { "type": "command", "command": "paceline statusline" } }
```
If you already have a status line, call paceline statusline > /dev/null from your script with the same JSON on stdin.
Send one message in any session, then run paceline gate.
Put one line in your lead agent's instructions:

Before you launch an agent, run paceline gate. On WAIT, don't launch: do the work yourself or wait until the time it prints.

The defaults (90% of the week, a 70% cap on the 5-hour window, 24 hours for the first day) are flags, so set your own. The code is MIT on GitHub.

If you run a crew of agents on one plan, I'd like to hear what your burn line says. mackenzie@mackenziebowes.com or @_mackenziebowes.