How much did that one click cost?

The record of a request can tell us how it failed. It can also show how many attempts we paid for. A task that appears once on the screen may have called a provider several times before returning an answer.

A fixed-price compute allocation limits one part of a bill, though bandwidth and external services may still be metered. With pay-per-use services, repeated work keeps adding charges until a limit actually stops it. We need to count the work behind the interaction the person sees.

Model calls are priced this way, usually per token, a token being a small piece of text the model reads or writes. So the useful habit is to do the arithmetic before you ship, with your own numbers.

Arithmetic with labelled numbers

Here is a hypothetical. The numbers are made up to show the shape of the calculation, not taken from any provider's price list.

Your app turns uploaded documents into summaries, and each summary is a task. On average a task makes 3 model calls, and that average already includes retries. Assume each call costs $0.02.

1,000 tasks × 3 calls × $0.02 = $60.

Now look at what moves that number. If a bug makes each call retry ten times, calls per task multiply. If an agent loops between two steps without a stopping rule, calls per task have no ceiling at all. If one visitor can create tasks without a limit, the number of tasks has no ceiling either. The prices hardly matter. The multipliers do.

Notice what is not in the formula: page views. Not every web request calls a model. A visitor who reads an already generated result may trigger no model call, while still using hosting or storage. Count model calls per task and tasks per user, instead of multiplying your traffic by a price. Before reading on, write the formula for one feature of your own app, and look up its price on your provider's current pricing page.

Agents make the unit bigger

A simple chat answer may need one model call. An agent working on a task makes calls in a loop: it reads, decides, calls a tool, reads the result and decides again. Several agents handing work to each other multiply that loop. A design mistake that used to cost a paragraph now costs a whole loop, and nothing in the interface tells you which one you wrote.

So every agent loop needs a stop condition that does not depend on the model agreeing to stop. Give it a maximum number of iterations, a maximum number of tokens or calls per task, and a time limit. When any of them trips, the task ends in a visible failed state.

A cap is a refusal

Most people answer all this with a budget alert and consider themselves covered. An alert is a message addressed to a human. It assumes that human is awake, near a phone, has the password, and moves faster than a machine that does not sleep. Billing alerts can also arrive late, because usage is often aggregated before it shows up on the bill. A cap is not a message. It is a refusal.

Enforce the cap where the calls are made. Reserve allowance atomically before starting each call, with per-user and whole-app limits. A separate read-then-increment can overspend when concurrent requests all see the same remaining allowance. Reconcile the reservation with measured usage afterwards. A call-count cap limits calls, not currency; token and tool costs need their own bound. If your provider offers spending limits, they are a second wall behind yours.

Then test the cap. In a development environment with a stubbed model, set the daily cap to five, run a loop that creates ten tasks, and check that the sixth is refused.

A meter you can inspect

Record provider-reported usage against the task that caused it, including unsuccessful attempts where they incur charges. Keep estimates visibly separate from billed usage. Logs themselves have storage and retention costs, so record the fields needed for attribution rather than dumping document bodies.

Compare one task's expected call count with its recorded attempts. If they differ, investigate that gap before projecting the cost to a thousand tasks.