A daily spend ceiling that degrades the right thing

Any product that gives something away needs a ceiling on the giveaway. The naive version is a daily spend cap: count the estimated upstream cost of every request, refuse everything once the day's total passes a number.

It fails in a specific and predictable way. The first time a genuinely busy day hits the cap, paying customers start getting refused. So somebody raises the cap. Then raises it again. Within a month the number is high enough that it never fires, and you have a ceiling in the code and no ceiling in reality.

The gate should only refuse the giveaway

A purchased run is not the exposure the ceiling exists to bound — it was paid for before it was made. So the rule becomes: count everything toward the day's total, but only refuse the runs that were free.

That keeps the counter honest, which matters more than it sounds. The counter is the day's whole upstream bill, and a counter that stops counting at the ceiling turns the one number worth alerting on into an estimate.

The deliberate consequence is worth writing down where somebody will read it: a heavy paid day shortens the free lane. That is the correct trade — the free tier is the thing that should degrade — but it is a surprise if nobody said so in advance.

"Was this bought" is not "which lane did it take"

Here is the part that cost us a real bug.

The first version exempted anything that spent credits, on the reasoning credit-funded, therefore sold. Only one of those follows from the other. New accounts get a welcome grant of credits, and a grant lands on the same balance a purchase does. So the giveaway was reachable in unlimited quantity through the door marked not the giveaway, and the day's ceiling never saw a cent of it.

The rule that actually works is stated in terms of the purchased pool:

function spendsBudget({ freeTier, paidCredits, cost }) {
  if (freeTier) return true;
  // Exempt exactly as far as the purchased balance reaches.
  return paidCredits < cost;
}

Somebody who bought a credit pack is untouched. Somebody spending a welcome grant is the giveaway wearing a different hat, and is held to the giveaway's ceiling.

The same predicate answers a second question

Once you have was this run bought as a function, it turns out to be the right answer to every question of that shape. Ours is now also the watermark rule.

The mark used to be applied on the free lane only, which sounds identical and is not: an account holding nothing but the welcome grant has no plan, so by our own pricing copy it should carry the mark, and it did not. Switching that switch to the same predicate fixed it without inventing a second definition of "paid" for the two to drift apart.

If you have a rule like this, look for the other places you have re-derived it by hand. The second copy is usually the wrong one.

The published grid this is enforced against, with the measured cost behind each cell, is at gptimage25.top/pricing.