Usage-based pricing plus a public endpoint is the combination that produces alarming bills. A bug, a loop, or a stranger who finds your URL can run up a number unrelated to anything you intended. The protections take an afternoon and you should build them before launch, not after.

Know your numbers first

Work out what one typical request costs, then multiply by a volume you'd consider a disaster rather than a volume you expect. If a thousand requests an hour is a number you couldn't absorb, you need a ceiling before anyone can reach the endpoint.

The four protections

A hard spend cap that fails closed. Track spending, and when the daily limit is hit, stop serving. Not a warning. A stop. This is the one that turns a catastrophe into an outage, which is a much better kind of bad day.

Rate limits per user and per address. Stops both runaway loops and casual abuse.

Input length caps. Somebody pasting a novel into your summariser costs real money. Cap it before it reaches the model.

Output length caps. Set a maximum on every call. Output bills at five times input, so an unbounded response is the expensive direction to be unbounded in.

spend-controls.txt
My app calls <model> at <endpoint>, expecting roughly <n> requests a
day. It's reachable by <anyone / logged-in users only>.

Add cost controls:
- Track spend per request and accumulate per day.
- A hard daily cap that stops serving when reached. Fails closed, not
  open. Tell me what users see when it triggers.
- Alerts at 50% and 80% of the cap.
- Rate limits per user and per IP. Say what limits you chose and why.
- Input length cap before the call, and a max output length on it.

Then estimate my monthly cost at 10x and 100x expected volume, and tell
me which line grows fastest.

Per-user limits are not enough on their own

A limit of fifty requests per user doesn't help when someone creates four hundred accounts. You need a global ceiling across all users as well, and it's the global one that saves you.

Watch it daily at first

Check your usage dashboard every day for the first fortnight after anything goes public. You'll find out quickly whether your endpoint has been discovered and what's being done with it. See reading your usage.

The one rule

Never put an uncapped model call behind an unauthenticated public form. Not as a demo, not temporarily, not while you're testing. It is the single most expensive mistake available in this area and it's entirely preventable.

A spend cap that warns you is not a spend cap. If it doesn't stop serving, it's a notification that you're losing money.