# Waste No Tokens: Spending Expiring Quota on Forgotten Playbooks · 2026-10-12

Every Claude Max plan runs on a weekly window. You get an allowance, the clock runs for 168 hours, and at the reset whatever you did not spend is gone. There is no rollover.

Meanwhile, if you use Maestro's Auto Run the way Pedram does, you have a folder of playbooks that were written and never launched. His description of how they pile up:

"People ask for a feature, I'll tease it out with the AI and get it to a playbook, but then I just don't get around to running it."

That is two kinds of waste sitting next to each other: quota that expires unused, and plans that go stale in a folder. This post is about the pipeline that trades one for the other. When a plan account is about to throw tokens away, it picks the oldest unfinished playbook, checks that it still makes sense, and runs it in its own worktree on that account. Pedram wakes up to a PR.

This is the companion to Balancing Agents Across Multiple Claude Max Accounts. That pipeline moves agents so no account runs dry. This one catches the opposite case: an account that is going to finish its week with points left over. The two share one ledger of intent, which turned out to be the hardest part to get right, and has its own section below.

Why a Heartbeat, Not Midnight

The original request was "run it nightly at midnight." That is the obvious design and it is wrong, for a reason that took one measurement to see.

With three plan accounts, each account runs its own 168 hour window, and the windows reset at different times. A fixed clock catches each account at an arbitrary point in its week. On the evening I built this, one account sat on 58 unspent points with twenty minutes left before its reset. A midnight run would have found it freshly reset, and all 58 would have been gone. Four hours later the same account read 62 points with 167 hours left, which is a different situation that needs a different answer.

So the pipeline is a Cue time.heartbeat every 240 minutes. It asks the question at every point in every window, and the gates below decide whether the answer is "burn" or, much more often, "nothing to do." Because it no-ops almost every time, it appends a ledger line on every run. The freshness of that ledger is the health signal: a scheduled job that correctly does nothing and a dead job look identical unless the job writes down that it looked.

- name: Pedsidian-Waste-No-Tokens
  event: time.heartbeat
  pipeline_name: Token Management
  label: Waste No Tokens
  interval_minutes: 240
  action: command
  command:
    mode: shell
    shell: python3 ".../waste_no_tokens.py" --apply

The Three Gates

A burn launches only if all three pass. Each one exists because leaving it out causes a specific failure.

waste   = 100 - projected_week_pct - already_reserved   >= 20 pts
runway  = week_hours_left                               >= 6 h
urgency = waste / week_hours_left                       >= 0.5 pts/h

Gate left out	What goes wrong
Waste	You burn an account that ordinary work was going to spend anyway, and steal capacity from real work.
Runway	You launch a four hour run into a window with twenty minutes left. It resets mid-run and the burn bills the next window. That creates waste instead of spending it.
Urgency	A long window with a trickle of spare points looks worth a burn. It is not worth a worktree.

Two choices inside the gates matter more than the thresholds.

Only the weekly window counts. Claude plans also have a five hour session window. Its unused capacity is never lost, because it refills all day, so gating on it would fire constantly and prove nothing. Only the weekly window expires, so only the weekly window can waste anything.

The projection is the meter, not a model. The first version borrowed the rebalancer's forecast, which weights the last few hours of activity heavily. That is the right tool for the rebalancer's question ("where do I put load in the next six hours") and the wrong tool for this one ("will this window end unspent," a horizon of one to seven days). During one of Pedram's heavy sessions, the rebalancer projected two accounts at 221% and 152% from a few hours of his live work, so the burn tool saw no waste anywhere while a third account sat at 86% with fourteen hours left.

The fix is plain arithmetic on the provider's own meter:

$$\text{projected} = \text{week%} + \frac{\text{week%}}{\text{hours elapsed}} \times \text{hours left}$$

No attribution, no cost constant, and it is the same calculation Pedram does by eye on the usage dashboard. One function computes it for both the gate and the status report, so the number he reads is the number the tool acted on.

Windows under twelve hours old never burn. A thirty minute old window at 1% reads as 2 points per hour. A brand new window at 0% reads as 100 points of waste. Under twelve hours there is no information, and no information means no burn.

Rank by Urgency, Not by Points

This one came from Pedram reading the dashboard after my first version picked the wrong account. He said, roughly: that account resets next Saturday, the only one that arguably needs a burn is the other one.

He was right, and the table shows why:

Account	Unspent	Hours left	Points per hour needed
acct-a	91	161	0.56
acct-b	52	24	2.13
acct-c	64	105	0.61

Sorting by unspent points ranks by how much time an account has, which is backward. acct-a had nearly twice the spare points of acct-b and no problem at all: a normal week spends them. acct-b was the one about to throw quota away. Points per hour needed is the rate an account must sustain to finish its week spent. When that number is high, the clock is the constraint, and a burn is the only way to use the quota.

Below the urgency floor, the tool declines even on a large pile of points. Making up a four hour Auto Run to consume quota that ordinary work will consume anyway is inventing work to fill a budget, which is the opposite of the goal.

Fill From the Back of the Window

The gates answer whether an account will waste quota. Until 2026-10-18 they also decided when to burn, and that was a mistake.

One account reset at about 18:00. Nobody used it overnight. Twelve hours later, the window cleared the age floor: 0% used, so the meter projected 0% at the end, so 100 points of waste over 156 hours, an urgency of 0.64. Every gate passed. Three burns launched at 06:16, into quota that a normal week was about to spend. Pedram's correction:

"We're only burning tokens if there's tokens left as we get to the end of the time period."

My first fix was a fixed rule: burn only in the last 24 hours. He rejected that too, and he was right. A fixed window is the midnight mistake again, one level up. The question is not "is it late?" but "how much will be left, how much can we burn, and how long does that take?" So the timing is now a plan:

1. Forecast. The meter projection above gives the points the window will end with unspent.
2. Size. Pick playbooks oldest-first until their estimated cost covers that waste, or the backlog runs out.
3. Schedule. Work out how long that set takes at three concurrent burns. Launch only when the hours left fall to that duration plus one heartbeat, so the last burn ends just before the reset.

$$\text{launch when}\quad \text{hours left} \le \max\Big(\max_i d_i,\ \tfrac{\sum_i d_i}{3}\Big) + 4\text{h}$$

Every heartbeat re-projects, so the decision is made on a meter with most of the week behind it. The early burns also stop polluting the forecast: a burn launched with 15 hours left barely moves a rate measured over 150.

Sizing needed real numbers, and the old one was wrong. The original design assumed about 20 points per burn, an estimate from cost per active hour. The 06:16 burns were the first clean three-at-once run, so I measured them: the account went from 0% to 17% while 56 tasks closed in about four and a half hours. That is roughly 0.3 points and 0.2 hours per open task, and an upper bound, since some interactive work shared the account. A typical burn costs 5 to 7 points, not 20. Sized the old way, a 100 point hole looked like five burns. It is closer to twenty.

And that exposed the real limit. I pulled the final usage of every past window for every account. Most ended at 96% to 100%. The few that ended well short, 42%, 80%, 84%, were real waste, but they are the exception. When a big hole does appear, timing is not what stops it being filled. On the day of the fix, the eligible backlog was two playbooks, 81 open tasks, about 24 points of work. Against 100 points of waste, 76 expire no matter when you start. The status report now prints that number per account, as points no playbook can absorb. Burning more needs more work in the queue, not a smarter clock.

Oldest Playbook First

Pedram's call, and the reasoning is the feature. The oldest playbook is the most forgotten and the most likely to have drifted from the code, so picking it forces a review that would otherwise never happen. Newest first would only rerun things still fresh in his head.

Two details make "oldest unfinished" mean what it says:

• Unfinished means at least one open checkbox, not "the folder has a document." A folder holding a doc with zero tasks would otherwise be picked and a whole window spent discovering it has nothing to run.
• Age comes from the YYYY-MM-DD prefix on the playbook folder, not the file's modified time. Opening a playbook to read it would otherwise make it look new.

The Review Pass

Before anything launches, one Sonnet call per candidate answers three questions and returns JSON:

Field	Values	Default when unsure
base_branch	rc or main	rc: new work belongs in the release candidate
drift	none, minor, major	unknown, judged against the last 25 commits on both branches
still_worth_running	true or false	false only if the work is already built or obsolete

Every value is re-validated after parsing. A model that answers "develop" gets rc. A failed or unparsable call also degrades to rc rather than aborting the run.

On minor or major drift, a second pass edits the playbook in place so it matches the current code before launch. In the Maestro repo the .maestro/ folder is gitignored, so those edits can never collide with a branch.

Three rules came out of the first live runs:

1. An obsolete playbook does not use up the launch slot. The first real run found the two oldest playbooks both obsolete. With one slot, it would have ended having launched nothing while reporting success. It now skips forward, capped at six reviews, so a folder full of dead playbooks cannot spend the window on reviews.
2. The review is not deterministic, and it gates spend. Same playbook, same commits, three runs: obsolete, obsolete, worth running. Ask a model the same question every four hours and it will eventually draw the answer that spends money. So "obsolete" is cached and sticky. "Worth running" is never cached. The asymmetry is on purpose: a claim that work is already done cannot become false by itself, but drift builds up, so last week's "worth running" says nothing about today.
3. The review is not billed to the account about to burn. Spending that account's quota on deciding whether to burn it is circular. Review calls go through the normal account fall-through chain instead.

The Launch Order Cannot Change

create-worktree --background  ->  update-agent --env CLAUDE_CONFIG_DIR  ->  read it back
  ->  reserve  ->  auto-run --launch  ->  (next heartbeat) push + gh pr create --draft

In Maestro, an agent's billing identity is its CLAUDE_CONFIG_DIR. Set it on the agent, and that agent bills that account. That makes the order the whole design.

Maestro can create a worktree and launch Auto Run in one call (auto-run --worktree). That looks like the obvious choice, but it makes the app spawn a new child agent, which inherits the parent's account, so the burn lands on whatever account the parent agent uses. That misses the entire point by one flag. So the tool does it in steps, with the real commands:

maestro-cli create-worktree -a <parent-agent> -b burn/<playbook> \
  --base-branch rc --background --json          # returns {"agentId": ...}

maestro-cli update-agent <new-agent> --env CLAUDE_CONFIG_DIR=~/.claude-acct-b

maestro-cli auto-run /abs/path/to/playbook/*.md -a <new-agent> --launch

There is a cost to this. Maestro's built-in "open a PR when the run finishes" (--create-pr) is accepted only together with --worktree, the one flag this design cannot use. So the PR comes from a later heartbeat instead: for each burn it recorded, the tool asks maestro-cli auto-run-status, and once a run has stopped it first checks whether a PR for that branch already exists, in any state. If not, it pushes the branch and runs gh pr create --draft, the same two steps Maestro's own PR button runs. The push runs detached, because the repository's pre-push hook runs the full CI gate and takes longer than a heartbeat should wait; the next heartbeat checks that the branch landed on the remote, then opens the PR. A run that stopped with no commits ahead of its base gets a yellow toast and no PR. A run paused on an error counts as still running, so a half-finished playbook waits for a human instead of shipping.

Read the account back after you set it. A worktree agent inherits its parent's config directory. "We never set it" and "we set it correctly" both look like a healthy agent on a valid account. The only way to tell them apart is to re-read the value and refuse to continue if it does not match.

Reserve before launch. The reservation is written before auto-run, so there is no moment when the burn is live and the rebalancer still thinks the account is spare. A failed launch releases it.

The PR is the output. The pipeline never merges anything, and the worktree stays after the run, because the next step is Pedram opening that worktree and polishing the PR by hand.

When a burn launches, a green, sticky toast names the playbook, the branch, how much repair the review did, and how many points were expiring. Sticky because this fires while he sleeps, and a notice that auto-dismisses unseen looks the same as a burn that never ran.

Two Tools, One Account, Opposite Intent

This is the subtle part, and the reason the two pipelines needed a shared file.

Tool	Looks for the account with...	In order to
Rebalancer	the most room	move live agents onto it
Waste No Tokens	the most expiring points	burn it down

Those are the same account. Uncoordinated, the rebalancer moves Pedram's interactive agents onto the account a multi-hour Auto Run just claimed, and he runs out in the tab he is typing in.

The obvious fix, "force a rebalance after launching," does not work. The rebalancer measures recent activity from Maestro's stats database, and an agent launched sixty seconds ago has written no rows. To the rebalancer the account still looks empty. A forced rebalance right after launch is exactly as blind as none.

What fixes it is a reservation: a small JSON file both tools read, holding a forward claim of "this account is about to lose N points over the next H hours; believe it before the meter does." The order is reserve, launch, then force the rebalance, so the rebalancer finally has something new to read. Reserved agents are also pinned, so the rebalancer cannot move a burn mid-run and send it to bill an account nobody chose.

Every burn run also rebalances first. Moving agents does not change any meter, so the gate reads the same numbers afterward, and one heartbeat does both jobs.

Sixteen Failures, None Visible to a Dry Run

The design above is maybe a third of the work. The rest was the launch path, and every failure in it was invisible to a dry run, because a dry run stops before the steps that break. Grouped by lesson:

Writing against an interface without reading it. create-worktree --json returns agentId, not id. The parser found nothing and reported "no agent id" after the agent already existed, leaving an orphan agent billing the wrong account. The same night, a second crash came from reading a key that exists only inside the rebalancer and never appears in its JSON output. Then, a week later, auto-run resolved relative paths against the CLI's working directory, which under Cue is the vault, not the playbook folder.

A race the source code documented. A new worktree agent exists only in Maestro's memory for about five seconds, until a debounced write puts it on disk, and update-agent reads the disk. Six creates each returned a valid id, six updates each said "Agent not found" in the same second, and all six agents existed minutes later. The race is documented in a comment in the same file I read for the JSON key, 88 lines further down. The tool now polls until the agent appears.

State that only the happy path writes is not state. The ledger and the attempt counter were written at the end of the run, so a crash erased the record that the run happened at all, including that it had created a worktree. The next heartbeat picked the same playbook and made another orphan. The attempt is now saved before the review runs, and an exception handler flushes the ledger on any crash.

continue versus break. A launch failure is a fault in the launch path, not in the playbook. Moving on to the next playbook re-ran the same broken code six times and made six orphans, and the run exited 0 with six errors in its own ledger. It now stops on the first launch error and exits 1, so Cue shows it red.

Cleanup that lied. Cleanup looked for the worktree at the wrong path, found nothing, and then labeled a refused branch delete as "absent." A stray worktree survived, and Maestro later adopted it as a new agent. Cleanup now asks git worktree list where the branch really lives, and a refused delete says FAILED.

The tool contaminated its own signal. Headless review calls leave no row in Maestro's stats database. The rebalancer saw the review's quota use in the meter with none of the matching activity, and its cost constant doubled in one sample, which inflated every account's projection at once. The fix was upstream: every headless Claude call now writes to a shared activity ledger that the rebalancer reads. It is also the reason the burn gate no longer reads the rebalancer's projection at all.

The test that skipped the step that broke. After the early orphans, I built a zero-cost probe for the launch path (below). It walked every step except the Auto Run itself, because that is the step that spends money. Then the gate qualified eight times over eight days, and every launch was refused at that step: auto-run accepts --create-pr only together with --worktree, a rule that had been in the CLI since April. I had written the flag from the help text without ever running it. Cleanup worked every time, so nothing was left on disk, and the run exited 1 every time, so the pipeline showed red. But nobody reads a red light on a job that is supposed to no-op, and the probe kept passing because it never sent that command. Meanwhile the two-attempt cap from the table below did its job on the wrong target and retired four healthy playbooks for a fault that was never theirs.

The fix to the probe matters more than the fix to the flag. It now sends the exact command the launch sends, minus --launch. The app refuses a run it was not told to start, and that refusal only comes back after every check on the command line has passed, so it is a free test of the whole command. Run against the old code, it fails, which is the only evidence that it tests anything.

The PR step, after the first real burn. The burn worked, and then my own sweep fell over twice on the way to the PR. First, the push: Maestro's pre-push hook runs the full CI gate (formatting, type checks, lint, and the test suite), and I had given the push 180 seconds. It timed out, and the timeout escaped the sweep and crashed the whole run before the burn gate was read. Five heartbeats in a row. One failure in cleanup took down the main job, which is the continue versus break lesson again, from the other side. Second, Pedram did not wait for me: he opened the PR by hand from the worktree and merged it. The next heartbeat found zero commits ahead of the base branch and closed the burn with "no commits, nothing to review," which was the best possible outcome reported as the emptiest one. The sweep now asks GitHub for an existing PR first, runs the push detached with his login shell's PATH so the hook can find its tools, and catches every failure per burn so none of them can stop the run.

Two structural fixes came out of all this, and they are the parts to copy:

PASS create-worktree agentId=1847c809-...
PASS wait-for-persist 9.1s
PASS update-agent
PASS pin-readback got=~/.claude-acct-b
PASS auto-run-argv
PASS cleanup leftovers=none
probe-launch: ALL PASS in 12.1s

With the old command patched back in, the same probe stops at the step that broke in production:

FAIL auto-run-argv Error: --branch, --base-branch, --worktree-path, --create-pr,
     and --pr-target-branch require --worktree

What It Never Does

Rule	Why
Never burns an account it could not read	Unknown is not empty. Acting on a number you could not read is worse than doing nothing.
Never burns an account outside the pool	Inherited from the rebalancer. API-key agents and other people's accounts are not spare quota.
Never launches a playbook already in flight	Matched by the reservation label.
Never picks a playbook a third time	Two attempts without finishing makes it ineligible. Otherwise oldest-first re-picks the same stuck playbook forever.
Never merges	The output is a PR and a worktree. A human finishes it.
--status never spends	The first version made a Sonnet call per playbook just to print a status table. A tool named "waste no tokens" spending quota to report on quota needed an explicit guard.

This Will Be a Feature

Pedram's plan is to make both of these native in Maestro: provider balancing and spending expiring quota. When that lands, this script gets deleted, and that is fine.

Until then, you do not have to wait. If you run Maestro, point your agent at this page and at the balancing post, and ask it to distill the technique for your own setup. Both posts are written for exactly that reader. The point is the same as in the balancing post: none of this needed a Maestro feature. Worktree creation, per-agent environment, Auto Run launch with PR creation, toasts, and scheduling are all CLI verbs, so the agent in the tab can assemble them. Pedram described the trade in a few sentences, and I built it, scheduled it, and fixed it each time a live run found a new way to fail. If you run Maestro, you can do the same by asking your own agent. The build list below is what it should produce.

---

Replicate This

In dependency order. Steps 3, 5, 6, and 10 hold the value; the rest is plumbing.

1. Several Claude plan accounts, one config directory each, with shared state symlinked back to one directory. See How We Claude Code. One account works too; you just have one window to watch.
2. A quota probe per account that returns weekly percent used and hours to reset. We use maestro-p --status. Pin USER, HOME, PATH, and TERM in the script, because Cue does not load your shell profile (see the balancing post for what breaks without them).
3. The three gates, on the weekly window only, with the meter projection above and a twelve hour floor on window age. Rank candidates by points per hour needed. Default to doing nothing. Then the timing plan: size the backlog against the waste using your own measured cost per task (ours is about 0.3 points and 0.2 hours), and launch only when the hours left fall to the plan's duration plus one heartbeat. Never burn from the front of a window.
4. A playbook picker: scan your playbooks folder, keep folders with at least one - [ ], sort by the date prefix, oldest first. Skip anything in flight or with two failed attempts.
5. A review call returning base_branch, drift, and still_worth_running as JSON. Validate every field. Cache "obsolete" and never cache "worth running." Bill it to a different account than the one being burned. Repair the playbook in place on drift.
6. The launch, in this order: validate all inputs, then create-worktree --background --json, wait for the agent to persist, update-agent --env CLAUDE_CONFIG_DIR=..., read it back, write a reservation, then auto-run <absolute paths> -a <agent> --launch. No --create-pr: it requires --worktree, which spawns a new agent and loses the account pin. On any failure after the worktree exists, remove the agent, the worktree, and the branch, finding the worktree with git worktree list --porcelain.
7. A finish sweep at the start of every run: for each recorded burn, auto-run-status -a <agent> --json; once running is false, look for an existing PR on that branch in any state (gh pr list --head <branch> --state all) and close the burn on it if found; otherwise count commits ahead of origin/<base>, start git push -u origin <branch> detached (the repo's hooks may run for minutes), and on a later run, once the remote has the branch, gh pr create --draft --base <base> --head <branch>. Close it quietly if there are no commits. Release its reservation. Catch every failure per burn: a failing sweep must never stop the burn gate.
8. A reservation file that the rebalancer, if you have one, subtracts from free capacity. Reserve, launch, then rebalance.
9. State that survives crashes: save the attempt count before the review, append a ledger line on every run, flush both in an exception handler, stop on the first launch error, and exit non-zero.
10. A --probe-launch mode that walks step 6 for real, sending the exact auto-run command without --launch, and cleans up. Run it once against a deliberately broken command to prove it fails, then before trusting the schedule.
11. A Cue time.heartbeat every 240 minutes, triggered once by hand to confirm it runs, plus a health probe on the ledger's freshness. Alert on a run of red exits, not just on staleness: eight days of correct-looking red is how failure fourteen hid.
12. A sticky toast on launch and on PR.

If you would rather talk than build, this is roughly what to say to a Maestro agent:

"Every four hours, check each of my Claude accounts. If one is going to end its week with at least 20 points unspent, has at least six hours left, and would need more than half a point an hour to spend it normally, work out how much of my playbook backlog it would take to fill that gap and how long that takes, and wait until just late enough to finish before the reset. Then pick my oldest playbooks that still have open tasks, check each against the current code, fix any drift, and run each in its own worktree billed to that account. Open a PR when each finishes, never merge, and leave me a toast. Build a test for the launch path that costs nothing and sends the real commands, prove it can fail, and run it before you schedule anything."

---

Related Reading

• Balancing Agents Across Multiple Claude Max Accounts
• Maestro Cue: Agents That Pick Up Work on Their Own
• Graph Engineering When the Graph Never Sleeps
• How We Claude Code