Spend caps over the trailing 24 hours, checked before every provider call.

Usage rows already carry cost, endpoint and user; a cap is a sum over the trailing day plus a refusal. Three scopes, each a module setting in US dollars (a decimal string, "5" or "0.10") where 0 or blank means no cap; the usage rows' cost is summed and compared as it is:

The released versions kept these caps under ai_daily_budget* in integer millionths of a dollar ("5000000" was $5). The module's migration chain copies them to the keys above in dollars and leaves the old keys alone. A scope whose old key is still set while its new key is missing (the migration has not run) refuses every call with {:error, {:budget_unmigrated, scope}} rather than read millionths as dollars, which would loosen the cap a million times over.

Beside the money, ai_daily_calls_per_user caps how many calls one user may make in the same trailing day (a count, 0 = no cap; scope :user_calls). A cheap model makes a money cap meaningless as a limit on how much one person can use, and a count says it directly.

It counts successful calls (cached answers included — each writes a zero-cost success row); failed provider calls cost nothing and do not count. Like the money cap it reads the usage rows by user_uuid, so a user_uuid: that is not a PhoenixKit user (its rows are written unattributed, with a warning) is never capped — pass real user uuids.

ai_budget_warn_percent (default 80) marks when a scope is close: the call still runs, but a Logger.warning and a [:phoenix_kit_ai, :budget, :warning] telemetry event fire once per crossing per scope (the flag clears when spend drops back under the line). Its spent / limit measurements are in the scope's unit: dollars (floats — a measurement must be a number), or a call count for :user_calls — check the scope metadata before adding them up.

Once a cap is reached every verb returns {:error, {:budget_exceeded, scope}} without a provider call — cached answers included: a cap is a stop switch, so a runaway site goes quiet rather than half-quiet. The window is rolling, not a calendar day: spend from 23:00 still counts at 09:00. The check reads the usage table; there is no reservation, so concurrent callers can overshoot by their in-flight calls. It also fails open — a database error reads as zero spend and no cap — because the module would otherwise refuse everything on a blip.

The per-user cap only bites when the caller passes user_uuid:, and the value must be a PhoenixKit user uuid (the usage row has a foreign key on it; a row with an unknown user is written without it, with a warning, so it counts toward no user). Anonymous visitors cannot be capped individually; cap the endpoint or the site instead.