How do I cap AI spend per client in n8n, so it stops before the call and not after the bill?

By The Keelstamp team, PowerQuant ApS, Denmark · Last reviewed 30 September 2026 · Revised 4 October 2026

Answer: Check the budget before the call, not after the bill. Keep a monthly budget per client in a database, reserve the worst-case cost of each model call with one conditional update, skip the call if the reservation fails, then settle the real usage. Put a hard limit on a per-client provider project or workspace behind it as a backstop.

Why an alert isn't a stop

OpenAI's spend alerts send a notification and let API traffic continue ^[1]. If a workflow loops overnight, the alert arrives together with the bill. A cap has to act before the request leaves.

The reservation pattern

1. Keep one row per client and month: cap, reserved, spent.
2. Work out the worst case per call: input tokens plus the node's Maximum Number of Tokens, priced from your own model-price table ^[2]. For an AI Agent run, multiply by Max Iterations, since each iteration is another model call ^[3].
3. Reserve with one statement that only succeeds if the amount fits:

   update client_budget
      set reserved = reserved + $3
    where client_id = $1 and period = $2
      and reserved + spent + $3 <= cap
   returning cap - reserved - spent as remaining;

   No row back means no call. Route to a Stop and Error node.

4. After the call, move the actual usage to "spent" and release the rest. On error, release it all. Log each reservation with a timestamp and sweep stale ones every few minutes.

Run it from n8n's Postgres node with Execute Query and Query Parameters ^[4]. In PostgreSQL's Read Committed mode, a concurrent update waits and then re-checks its WHERE clause against the updated row ^[5], so parallel executions can't overspend the last of the budget.

When the database is down, the answer is no

If the check can't run, don't make the call. A cap that lets calls through when it can't check isn't a cap. Proxies make this a setting. LiteLLM, a proxy with budgets per key, team and customer, reports that its rate limiting across several proxy instances drifted by at most 10 requests in a high-traffic test ^[6]. Its option allow_requests_on_db_unavailable lets requests through when the database can't verify a key, and its production guide says to use that only on a private network ^[7][8].

Provider limits as a backstop

• OpenAI: hard spend limits per organization and project return HTTP 429 (project_spend_limit_exceeded for a project) when reached. OpenAI notes that enforcement "is not instantaneous" ^[1].
• Anthropic: each Claude Console workspace has a Spend limits tab. At a limit you set, requests return HTTP 400. The default workspace can't have limits ^[9][10].

One project or workspace per client gives you a ceiling per client, but it reacts late and tells the client nothing.

Disclosure: this page is written by the team building Keelstamp, a tool for per-client caps. It isn't released yet, and everything above works without it.