Weekly AI Quota

This policy defines how we treat the prepaid weekly AI subscription quota: a fixed cost that is already paid and that resets on a timer whether or not it was used. Capacity left unspent at reset is gone β€” we cannot bank it, refund it, or carry it forward. The discipline is therefore simple: turn paid-for-but-idle capacity into real value before the reset, without manufacturing busywork to run the number up. It sits under the AI Usage Guideline (what we let AI do and on what terms) and complements Preparing for Overnight AI Operation (the biggest single sink for spare capacity is the unattended night) and the Development Guide (what "value" and "done" mean here).

Two failure modes are equally wrong, and this policy exists to steer between them: waste β€” letting paid capacity expire unused β€” and count-filling β€” burning the quota on processing that produces no value just to say it was used. The target is neither an idle meter nor a maxed-out one; it is the most value the paid week can yield. Requirement levels follow RFC 2119: MUST / MUST NOT are absolute, SHOULD / SHOULD NOT are strong defaults overridable only with a documented reason.

This is where three OSBR values pull the same direction. Be Nice: spend the spare cycles on the debt, security, and research that make a teammate's next week easier. Be Kind: never hand a colleague or client output that exists only because a meter had to be emptied. Be Strong: do the harder planning work of pointing idle capacity at real problems, instead of letting it lapse or letting it churn.

1. Goal

Extract the maximum genuine value from capacity that has already been paid for before it resets and disappears. The quota is a fixed weekly cost; once bought, the only question left is how much useful work it produces before the clock runs out. An unused hour of quota at reset is not "saved" β€” it is spent and wasted, identical in cost to an hour used well, but with nothing to show for it.

The goal is high utilisation of a fixed cost, not high activity. A week that ends with the quota near-exhausted on work worth doing is a success; a week that ends the same way on work not worth doing is a more expensive failure than leaving it idle, because it also burned the developer's review attention. Utilisation is the means; value is the end.

2. Responsibility

3. Practices

3-1. Treat the quota as a fixed, perishable cost β€” not a sunk one to ignore

The weekly fee is paid up front regardless of use. That has a precise economic consequence: at any moment mid-week, the money is already gone (it is sunk and must not sway the decision), but the remaining capacity is a live asset worth something only if used before reset.

Sunk vs. perishable β€” hold both. The money is sunk: never let "but we already paid" justify low-value churn. The capacity is perishable: never let "we might not need it" justify letting it lapse. Both truths point the same way β€” spend the remaining capacity on the best available work, and only that.

3-2. Keep a standing backlog of spare-cycle work

Utilisation only works if there is somewhere worthwhile for spare capacity to go the moment it appears. Idle capacity with an empty backlog is what causes count-filling.

3-3. Direct idle capacity before it lapses β€” "use it before you lose it"

Capacity that will expire unused should be actively steered at the standing backlog, not left to evaporate.

3-4. Do not optimise the count β€” beware Goodhart's Law

The instant "quota utilisation" becomes a number people feel judged by, the incentive flips from doing valuable work to making the number go up β€” and those two come apart fast.

A full meter is not an achievement. "We used 98% of the quota" says nothing on its own β€” 98% on debt paid down, security hardened, and research banked is a great week; 98% on padding and re-runs is waste dressed as productivity. Never celebrate, target, or rank on the utilisation number. Celebrate what the capacity produced.

3-5. Every spare-cycle result still gets reviewed

Work done to soak up spare capacity is still work, and it enters the codebase and the client's world exactly like scheduled work. The prepaid, low-urgency origin of a task lowers its scheduling priority β€” it lowers none of its quality bar.

4. Summary loop

  1. See β€” recognise the weekly quota as a fixed, prepaid, perishable cost: unused at reset means spent-and-wasted, and the fee itself is sunk and irrelevant to the decision.
  2. Stock β€” keep a standing backlog of genuinely valuable, non-urgent spare-cycle work: refactoring, security, research, tests, docs.
  3. Steer β€” point capacity that would otherwise lapse at the highest-value backlog item, usually as overnight work; if nothing is worth doing, let it lapse.
  4. Don't game β€” never run the meter up for its own sake; utilisation is a diagnostic, never a target (Goodhart), and value, not consumption, judges the week.
  5. Review β€” every spare-cycle result clears the same human review bar as scheduled work before it is trusted.

Waste nothing that is worth doing. Manufacture nothing that isn't.

References

Named ideas this policy is built on, chosen because they are established and freely readable.

Fixed cost, sunk cost & opportunity cost

Perishable capacity & utilisation β€” "use it before you lose it"

Spare-cycle / idle-time work

Don't optimise the count

Related OSBR standards