Money left on the table: harvesting AI quota before it resets, without making noise

Fixed-allocation AI capacity has a property most compute budgets lack: it is perishable. What you do not spend inside the window does not roll over. It stops existing at the reset instant. What surprised us, once we instrumented it, was the shape of the loss.

Our opening position, in one sentence: high measured volume, near-zero customer-visible output, and whole pools of paid capacity approaching their resets untouched. The tokens we spent went somewhere we could not name. The tokens we did not spend simply expired. In one observed reset, a pool reset with roughly 82 percent of its allowance unused. That is the money on the table.

The obvious remedy is a directive: spend the allowance before it resets. We had that directive, with one rider attached by the operator: harvest the tokens, but "not just theater and noise." The rider turned out to be the whole problem.

An autonomous system given a spending target and no value discipline will meet the target. That is what optimizers do. The question is what it meets the target with. Our ledgers record the failure family in detail: status re-posted as if it were work; pointers to pointers with nothing new at the bottom; long runs that produce partial output and call it a result; work marked done that was not; and, most dangerous because it looks most legitimate, new backlog items minted by the workers themselves, so the queue of "real work" never runs dry. Every one of these consumes tokens. None of them produces anything at the outcome layer.

So the problem has two sides, and both cost money. Leave knowable headroom unmeasured or unspent, and you forfeit it. Spend it on theater, and you have traded forfeiture for noise. Everything below exists to walk the line between the two.

The evidence below comes from our own ledgers over several weeks. Each incident is stated as a shape, with vendor names, plan details, and most figures stripped, followed by the rule it taught us. The last item is not an incident but a review of the guards themselves.

2.1 The dashboard said UNMEASURED while the data sat on disk

When we decided to take harvesting seriously, our unified burn dashboard showed several pools as UNMEASURED. The natural reading, that nobody was measuring them, was wrong. The headroom numbers existed. They sat on disk in three different formats, and nothing could read all three. The dashboard was not missing sensors; it was missing a normalizer for the sensors already running. Acting on the UNMEASURED label would have forfeited headroom that was knowable the whole time.

Rule taken: before building an actuator, unify the readers. "We don't know" is often a formatting problem, not a measurement problem. The first deliverable is making UNMEASURED impossible anywhere data exists.

2.2 One pool nearly untouched, another ahead of its pace

At handover, our live snapshot showed one pool nearly full of remaining allowance with its reset only days away, while the most-used pool was already well ahead of its pacing target for the week. A global "spend more" push would have spent into the wrong pool, the one already ahead, starving the days before its reset while barely touching the pool about to forfeit.

Rule taken: "use it or lose it" is per-pool, never global. A harvest system needs a protect list of pools that are ahead of pace and must not receive harvested work, and the forecast, not a human, keeps that list honest.

2.3 The pacing curve that expired

Our first pacing plan was a table of dates and target numbers, computed by hand for one specific week. It worked until the week ended. After the reset rolled over, the "target" kept rising past what was physically usable. The fixed curve had gone stale the instant the window it was named after expired.

Rule taken: never hard-code a time window. Compute the target fresh on every tick from the reset instant itself: target equals elapsed time divided by window length. The plan then lands near zero just before every future reset with no maintenance, because it has no memory of any particular week.

2.4 Someone else's batch drained the short window

While we were pacing a weekly window, a scheduled off-hours batch, run by someone else on the same shared allowance, consumed nearly all of a short rolling sub-window inside fifteen minutes. Our agent hit the wall and went silent for about two hours. Nothing was wasted, but the pacing plan had not modeled nested windows at all.

Rule taken: windows nest, and they are shared. A harvester that schedules "spare" work into a short window it does not model will collide with someone else's batch and lose hours, not tokens. Read every window, every tick, before admitting work.

2.5 The week the correct action was to idle

Mid-week, every remaining high-value item in the queue was gated on a human decision. The agent was behind its burn pace and had tokens to spend. The action it took, for hours, was the cheapest possible mode: doing nothing but logging the situation. The one rule with no exception was that tokens must never be converted into theater. The forfeit for that stretch was recorded as a fact instead of being covered with busywork.

Rule taken: the hard part of quota harvesting is not finding work; it is refusing fake work. "Idle and record the forfeit" must be an honored outcome, or the system will optimize itself into a noise generator.

2.6 Fifteen minutes changed the sign of the gap

Twice in one week, the gap between actual and target pace reversed sign within fifteen minutes, because other sessions on the same allowance spent tokens our controller did not schedule. A plan that extrapolated from its last reading would have spent into a wall or idled into a forfeit. The controller survived because it re-read live usage every tick and never trusted its own forecast of where it "should" be.

Rule taken: on a shared pool, telemetry is an observation, not a plan. Treat any number older than the current tick as stale, and make stale readings fail to UNKNOWN rather than to the last good value.

2.7 Every anti-noise guard ships with a test that watches it fail

The guards in our harvest design were not invented in a vacuum. Each encodes one of the failures listed in section 1. A run that produces no new artifact is scored NULL. Output that echoes recent status traffic is scored NULL. Spend is held under a hard drift cap with a checkpoint. Receipts are re-checked by the guard itself, and a fraction of accepted runs are re-verified end to end by a different provider than the one that produced them. Two NULLs suspend an item. Workers cannot add items to the backlog. And the design's own bar: a guard you have never watched fail on a seeded bad run is decoration. Each rule was proven by planting a deliberate violation, such as a run with no artifact, an echo of recent posts, or a drift cap violation, and confirming the system caught it.

Rule taken: autonomous spending needs negative controls. Plant a violation for every anti-noise rule and prove the system catches it before trusting it with unattended tokens.

2.8 The clock that ran fast

Twice, an agent wrote human-readable timestamps by doing arithmetic in its head instead of asking the clock, and the labels ran up to an hour fast. That is harmless in prose. In a reset-anchored system, "how many hours until the window closes" is the number that decides what work gets admitted. A harvester that misjudges the deadline either burns early or stops late, and both cost money.

Rule taken: every time that feeds a quota decision comes from a clock call, a commit time, or a file timestamp in the same turn, never from a model's arithmetic. If a deadline cannot be anchored, write UNKNOWN and re-read.

2.9 A scoreboard that can catch success in the wrong direction

A spending system can fail while every spending metric looks good. Our design pairs two numbers in a morning report. The first is forfeit share: how much paid capacity expired unspent. The harvester exists to push it down. The second is value density: accepted, receipt-backed artifacts per unit of harvested tokens. It is supposed to stay flat or rise. If forfeit falls and value density falls with it, the system is not harvesting; it is generating filler that happens to consume tokens. Behind the numerator sits a never-list: no status summaries, no recaps of the room, no health checks with no state change, no re-runs of passing suites, no plans for plans.

Rule taken: pair every "spend more" metric with a "was it worth anything" metric, and review them together. When they diverge, pause and re-score the backlog. Do not celebrate the lower forfeit.

2.10 No ceiling, no percentage

One pool reported how fast it was being spent but not its total allowance, so "percent remaining" was uncomputable. The temptation is to guess a ceiling and produce a tidy percentage anyway. Our rule forbids it. Pools without a measured ceiling run in a conservative mode, throttled hard and halting on the first sign of a rate limit, and the forecast reports UNKNOWN instead of a made-up fraction.

Rule taken: an unmeasured denominator turns every downstream number into fiction. Fail closed to UNKNOWN, throttle the action, and let the first rate-limit response be the sensor.

2.11 The review that found seven ways to fail open

The admission stage, the per-tick harvest loop, and the morning metrics report now exist and run in shadow mode. They compute what they would admit and record it, but they admit nothing. They sit behind nine guards and a kill switch. Before trusting those guards, we had them examined by an independent reviewer from a different provider than the one that wrote them.

The reviewer found seven edge cases in which a guard failed open, letting something through that it should have stopped: negative or not-a-number usage passing the drift cap; symlinks escaping owned paths; failed-run hashes poisoning novelty checks; future timestamps counted as fresh; malformed receipts silently dropped; duplicate run identifiers double-counted; and concurrent judges running unserialized. All seven were fixed, and each fix came with a test that failed before the fix and passed after it.

Rule taken: a guard is reviewed by someone who did not write it, and every fix arrives with a test that fails first. Invalid, duplicated, concurrent, and redirected inputs belong in a guard's specification.

Nothing admits real work yet, by design. The incidents informed the design. This paper makes no claim about the harvester's results, because there are no results yet.

Six rules fell out of this evidence. None of them is clever.

1. Measure before you move. The dashboard that said UNMEASURED, the pool with no measured ceiling, and the asymmetric snapshot at handover all teach the same thing: a harvester acting on a missing or invented number will spend into the wrong place. Normalize the readers you already have. Report UNKNOWN when you do not know. Pace per pool, with a protect list for pools already ahead.

2. Pace from the reset, every tick, against every window. Plans go stale, windows nest, shared pools move under you, and clocks estimated in a model's head run fast. Our pacer addresses all four by recomputing from the reset instant on every tick, reading every window it lives under, re-reading live usage instead of extrapolating, and taking its deadlines from a real clock.

3. Harvested tokens buy only pre-qualified work. Spare tokens never go looking for something to do. They draw from a fixed backlog of work classes qualified as valuable before any harvest pressure existed. In our case those are tests that kill deliberately seeded mutants, adversarial review of work already produced, research that must come back with sources, and maintained banks of evaluation cases. In our ledgers, the default spare-token spend was sweeps of stale blocked work: re-reviews and sweeps of blocked items. Qualification happens in calm times, by humans, with a value argument attached. A class of work that cannot explain why it would be worth doing at full price is not admitted at any price. And workers cannot add to that backlog. This is the load-bearing rule: once a spending system can author its own justification, every downstream control is auditing fiction.

4. Receipts or it didn't happen, and two strikes. Every harvested run ends in an artifact a check can re-observe: a file with a hash, a test result with an exit code, a review with a verdict. No artifact, or an echo of recent traffic, scores NULL. Two NULLs suspend the item. Without that limit, an unbounded retry policy turns one failing item into a slow token leak, and the burn dashboard looks fine while value density goes to zero. Suspension turns a silent leak into a visible queue of things that need a human look.

5. Idle is an honored outcome. When every real item is waiting on a human decision, the correct spend is zero, and the forfeit goes in the ledger as a fact. A harvest system that treats idle as failure will find something to do, and what it finds will be noise.

6. Guards earn trust in stages. A guard you have never watched fail is decoration. A guard only its author has tested has been checked against its author's imagination. A guard that has never run against real traffic has not met the inputs that will break it. So: seed violations, get an independent review, fix with tests that fail first, run in shadow, keep a kill switch, and only then admit real work.

If you pay for fixed-allocation AI capacity, in any stack, these are the six moves in the order we would make them:

1. Unify your readers before you build anything. If your usage view says UNMEASURED or shows blank cells, find out whether the data exists in a format nobody reads. The first harvest deliverable is a normalizer, not a sensor. Where a ceiling truly is unknown, report UNKNOWN and throttle.

2. Draw your window map. List every quota window you live under, the long weekly or monthly one and every shorter rolling window inside it, and who else shares each one. If your plan does not model the short windows, someone else's batch will teach you about them at the cost of hours.

3. Recompute pace from the reset instant, every tick. Target equals elapsed time divided by window length, computed fresh, with no hard-coded dates. Delete any pacing table that names a specific week. Never extrapolate: re-read live usage every tick, fail stale readings to UNKNOWN, and take every deadline from a real clock.

4. Build the value gate before the throttle. Write down, while you are calm, the classes of work harvested tokens may buy. Require each admitted run to end in a re-checkable artifact. Suspend any item after two NULL results. Make it structurally impossible for workers to add their own items to the harvest queue.

5. Prove the guards, then run in shadow. For each anti-noise rule, plant a deliberate violation and watch the system catch it. Then have someone who did not write the guards try to break them with invalid, duplicated, and concurrent inputs. Fix with tests that fail first. Run the whole loop in shadow, behind a kill switch, before you let it admit real work.

6. Score two numbers, together. Track forfeited share and accepted artifacts per unit of harvested tokens on the same morning report. If both fall, you have built a noise machine: pause and re-score. And make "idle and record the forfeit" an honored outcome. The week every real item is waiting on a human decision, the correct spend is zero.

None of this requires our tooling. It requires refusing to let a spending number stand in for value.

We want to be as skeptical of the cure as of the disease.

We have not measured real admission. The harvester runs in shadow mode. It admits nothing yet, by design. Every result this architecture promises, lower forfeit at flat or rising value density, is unmeasured. The falsifier above is published ahead of the data, and the first real-admission month may fail it.

Shadow is not live. A shadow loop records what it would have done. It does not meet the contention, rate limits, and shared-pool surprises that real spending will. Incidents 2.4 and 2.6 happened under real load, and we expect real admission to produce new ones.

Seven found does not mean none left. An independent reviewer found seven fail-open cases. That is evidence the review was worth doing. It is not evidence that the guards are now complete. Independent review widens the gap between author and checker; it does not close it.

There is nothing to harvest on pure pay-per-use. This system exists because our capacity is fixed-allocation, per-pool, and shared across processes. If you pay strictly for what you use, the problem statement does not apply to you.

The evidence base is small. Ten incidents in one organization over several weeks, drawn from internal ledgers, is a case study, not a study. We report shapes, not industry statistics. We stripped vendor names, plan tiers, account counts, and most figures, because the mechanics of any one provider's quota system are beside the point. The failure modes are properties of perishable capacity plus autonomous optimizers.

The value gate is only as good as the backlog. A harvester drawing on a weak backlog produces weak value efficiently, and no pacing math fixes that. Qualifying the backlog remains human work.

The scoreboard is slow. The two-number report catches theater only in aggregate and only in the morning. A sufficiently clever noise generator could stay under it for days. We accept that risk because the alternative we measured, forfeiture alongside spend we could not account for, was worse.

Perishable capacity punishes two opposite mistakes: leaving it on the table and spending it on noise. The second is easier to fall into, because it looks like success on every chart that counts tokens. What we have built so far is the part that refuses: sensors that say UNKNOWN instead of guessing, a pacer that forgets every week as soon as it ends, a gate that buys only work someone qualified in advance, and guards that have been watched failing, by us and by a reviewer who did not write them. What we have not done yet is let it spend. When we do, we will report the two numbers, whichever way they move.