Squeeze the Quota Before Sunday

At 12:19 AM a failure note recorded one line: “the spend gate deferred the model call (band orange, discretionary), not a code bug.”

The note said it was not a code bug. The gate had deferred the call.

What the gate was doing

One seat’s weekly quota resets on Sunday. The aim was to use it up by then, on blog updates.

The deferred call landed in the orange weekly band and was classed as discretionary.

Before the fix, those limits did not give way for a seat that was projected to run out before its reset anyway. A seat that will run dry before the reset has nothing left to ration.

The first fix, and why it was not enough

The seat router was changed first. A seat projected to run out before its reset now keeps taking work until it is really dry. That change was committed and pushed that morning.

A live spawn did not prove it. The spend gate still deferred the spawn on the seat’s weekly envelope.

The second fix, in the gate

The gate now has a burn-to-reset rule. The weekly band and the per-job envelope no longer defer a seat projected to exhaust before its own reset.

The rule shares the router’s predicate. The 5-hour window and the hard exhaustion limits stay in force, and they protect interactive sessions, so the waiver does not reach them. The unsigned penalty also stays.

The third fix, in the discretionary gate

By 7 AM the two blog jobs were still blocked. The discretionary gate has its own off-hours clock check, and it ran first and refused before the spend gate was ever asked. It now asks the same burn-to-reset question before refusing on the clock.

What was checked

The tests passed, with a few known failures that were already red. A live role spawn went through on that seat.

After the third fix both blog jobs were run for real. The editorial review completed cleanly. The backfill published four posts, and each was verified as a 200 on the live site.

dxdev LESSON · paste into your AI coding agent
LESSON: Treat Quota Scarcity Differently As Reset Approaches
SOURCE: dxdev.com/blog/2026-09-25_burn-to-100-before-reset
WHAT HAPPENED: A spend gate deferred a model call, classed as discretionary, because the weekly quota band had moved to orange. Its rule considered only how full the quota was, not whether the seat would run out before its own reset anyway. The seat router was changed first, so a seat projected to run out before its reset keeps taking work until it is really dry. That fix could not be proven live, because the spend gate still deferred the spawn on the seat's weekly envelope. The gate then got a burn-to-reset rule that shares the router's predicate. The 5-hour window, hard exhaustion limits and the unsigned penalty stayed in force.
THE RULE: Treat limited capacity as scarce only if it can still be used later in the cycle. When one component decides a resource is safe to spend, every other gate on the same path must ask the same question, or the first fix is blocked by the second.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any rationing or throttling rule that looks only at how full a budget is and never at when it resets or whether it will be exhausted first.
      2. Any two gates on the same request path that decide "may this spend" with different predicates, so one can veto what the other allows.
      3. Any waiver of a spending limit that also waives the hard floors (short-window caps, true exhaustion) meant to protect interactive use.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.