How we run a crew of AI agents on one subscription without ever hitting the wall

A pace line for a flat-rate AI plan: launch while you're under it, wait when you're over, and never let the five-hour window stop work mid-task. The rule our crew runs on every launch, how it was tuned on real incidents, and the free tool that applies it.

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

Every agent asks before it launches. Under the pace line the gate says LAUNCH; over it, WAIT until the line catches up. The levels are illustrative.
Contents

Every morning a crew of named AI agents starts work on this machine: a lead, writers, builders, reviewers, researchers. They share one flat-rate Claude plan. Before any of them starts another agent, it asks one question and gets one word back: LAUNCH or WAIT.

A terminal showing a real gate reading: LAUNCH; week 62% used against a pace line of 65.3%, 73% of the week gone; the five-hour window at 4% of a 70% cap; burn 0.67% per hour against a sustainable 0.61%. A real reading from our crew's gate at 12:50 on 2026-10-18. paceline is its public version.

A flat plan has two limits, and they fail in opposite ways. Hit the five-hour window and every agent stops mid-task. Leave the week underused and the hours you paid for vanish at the reset. The gate holds both at once. How do you pace a week you can't see ahead? Why does the obvious rule break every Monday? And how many agents can one plan really carry?

The pace line

Picture a line that starts at zero when the weekly allowance resets and climbs evenly to 90% by the next reset. Over the line, the gate says WAIT until the line catches up. Under it, the plan is going unused, so it says LAUNCH.

The five-hour window gets a hard cap at 70%. An agent that hits the real limit stops in the middle of its work, so the gate stops launching well before that.

The gate also measures the crew's burn rate over the last few hours and turns it into a capacity figure: how many agents the week can afford to run continuously. In the reading above, the crew was burning slightly faster than the week could sustain, and the gate still said LAUNCH, because the week was under its line.

The pace line is pulled by the clock, not by usage, and reaches 90% at the next reset. The end is our real reading from 12:50 today. The lumps along the way are illustrative.

Tuned on real incidents

At 12:12 one Saturday morning, an agent started a batch of 943 requests. It used 45 points of the five-hour window in one burst, from 3% to 48%, and put the week 7 points over its pace line, at 53% against 46%. The gate told every agent on the machine to wait until 1:56 that afternoon. The lesson went straight into the design: a loop that fans out calls runs the gate between batches, not only before it starts.

The real incident, left: the loop asked once and the 943 requests ate the five-hour window. The fix, right: ask between batches, so the gate can stop the loop partway. The right panel's levels are illustrative.

The first-day rule took two tries. Right after a reset the line sits near zero, so a few percent of use reads as "over" and the gate would hold everyone back for no reason. Mackenzie's first call:

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,

We set the exception to five hours. That afternoon an agent hit WAIT with four hours to go, and its cache only lasts an hour, so reloading its context would have cost more than the wait saved.

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,

So for the first 24 hours after a reset, the gate follows only the five-hour cap.

Mackenzie's two calls, a few hours apart on 2026-10-13. A 5 hour exception left an agent waiting 4 hours on a 1 hour cache; 24 hours holds.

What this says about how we work

We run our own operations on agents every day, and we treat their costs as an engineering problem, not a bill to worry about. When a rule earns its place, we measure it on real incidents, tune it until it holds, and then publish it as a tool anyone can install. The same discipline goes into anything we build for someone else.

How we work: run the rule against real incidents, tune one thing at a time until every lamp holds, then give it away.

Take it

paceline is free and MIT-licensed. It reads the usage figures Claude Code already passes to its status line, so setup is two steps:

cargo install --git https://github.com/mackenziebowes/paceline
{ "statusLine": { "type": "command", "command": "paceline statusline" } }

Then give your lead agent one line: "Before you launch an agent, run paceline gate. On WAIT, don't launch." Exit codes make it easy to script (0 LAUNCH, 1 WAIT, 2 no fresh reading), and every default is a flag: the weekly target, the five-hour cap and the first-day window.

Install it, then give your lead one line: ask paceline gate before every launch. The exit codes are 0 for LAUNCH, 1 for WAIT and 2 when there is no fresh reading.

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.