Stop the n8n agent bill

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

Short answer: Runaway n8n agent bills usually come from four things: an agent that keeps reasoning, a workflow that triggers itself, retries of a call that will fail again, and a burst of input nobody planned for. No single setting stops all four. Stack the nine layers below. Everything here works in plain n8n, with short notes for Make and Zapier at the end.

Where the money goes

• The agent keeps going. Each iteration of an AI Agent is another model call, and each call usually sends the growing conversation again, tool results included. Cost grows faster than the number of steps.
• The workflow triggers itself. An agent replies to an email that starts the same workflow, or a sub-workflow calls the workflow that called it.
• Retries multiply calls. Retry On Fail on the node, the model node's own retries, and a retry in your error path can stack.
• Bursts. An import of thousands of rows fires the trigger once per row.

Layer 1: Cap iterations and output tokens

On the AI Agent node, open Options → Max Iterations. n8n describes it as "the number of times the model should run to try and generate a good answer", and the default is 10 ^[1]. Set it to the lowest value your task needs.

On the chat model sub-node, set Maximum Number of Tokens. Both the OpenAI Chat Model and the Anthropic Chat Model have it ^[2][3]. Without an output cap you can't know the worst case of a call, and without a worst case you can't budget (layer 6). With OpenAI reasoning models, the Responses API's max_output_tokens is an upper bound "including visible output tokens and reasoning tokens" ^[4], so the cap covers the thinking as well.

The OpenAI Chat Model node also has Timeout (milliseconds per request) and Max Retries ^[2]. Keep retries low (layer 4).

Your worst case per agent run is roughly Max Iterations × (largest expected context + Maximum Number of Tokens), priced at the model's rates. It's the amount you reserve in layer 6.

Layer 2: Put a clock on every workflow

In the workflow settings, turn on Timeout Workflow so n8n cancels a run after a set time ^[5]. On self-hosted n8n, the instance default EXECUTIONS_TIMEOUT is -1, which disables the timeout, and EXECUTIONS_TIMEOUT_MAX (default 3,600 seconds) is the most a user can set for a single workflow ^[6]. On n8n Cloud, each plan has its own maximum ^[5].

A timeout limits time, not money: a tight loop can spend a lot in minutes. Treat it as a backstop for runs that hang.

Layer 3: Break the loops you build yourself

• Carry a hop counter. When work passes to another workflow or back to the same one, add a field such as hops, increase it on every pass, and let an IF node route to Stop and Error above a limit. Stop and Error makes the execution fail on purpose and sends your error to the error workflow ^[7].
• Restrict who can call a sub-workflow. The setting This workflow can be called by controls which workflows may start it ^[5].
• Drop your own output at the trigger. If an agent sends email or posts where workflows also start, mark what it sends (a header, a tag, a sender address) and filter marked items out right after the trigger.
• Cap concurrency on self-hosted instances. N8N_CONCURRENCY_PRODUCTION_LIMIT sets how many production executions may run at once, in both regular and scaling modes. The default is -1, which disables the limit in regular mode ^[6].

Layer 4: Fail loudly, retry carefully

Create an error workflow that starts with an Error Trigger, and select it in the settings of each workflow under Error Workflow ^[8]. It receives the error message and the failing node, plus the execution's ID and URL if the execution was saved ^[8]. Two details catch people out: the error workflow doesn't have to be published, and it only runs when an automatic execution fails, so a manual test run won't trigger it ^[9].

Use the error workflow for three jobs: notify someone, set the client's stop flag (layer 6), and write the incident to your cost log (layer 9).

Retry On Fail reruns a failed node ^[10]. That helps with a network blip and costs money on anything else. Keep the number of tries low on model nodes, and never retry errors that will fail again. Provider limits are the classic case:

• OpenAI returns HTTP 429 with project_spend_limit_exceeded or organization_spend_limit_exceeded when a hard spend limit is reached ^[11].
• Anthropic returns HTTP 400 (invalid_request_error) when a spend limit you set is reached, and HTTP 429 (rate_limit_error, without a retry-after header) when your organization hits its usage-tier cap. The tier cap pauses usage until the start of the next month unless you get a higher limit ^[12].

A generic "retry on 429" will hammer a limit that won't lift until someone raises it or the month ends. Set the model node's On Error to Continue (using error output) ^[10] and route these errors to a branch that stops the client instead.

Layer 5: Throttle

n8n's guidance for rate limits gives you three tools: Retry On Fail with Wait Between Tries (ms) longer than the provider's window, Loop Over Items plus a Wait node to pace batches, and the HTTP Request node's Batching option with Items per Batch and Batch Interval (ms) ^[13]. Use them to pace bursts.

At the provider, you can set rate limits per model for each OpenAI project ^[14], and requests, input tokens and output tokens per minute for each Anthropic workspace ^[15].

Layer 6: A budget per client, checked before the call

Provider limits cap an account. Alerts arrive after the money is spent. Neither knows which of your clients caused the bill. If you run agents for more than one client, keep your own budget per client and check it before every model call.

The pattern is a reservation:

1. Keep one row per client and month with the cap, the amount reserved and the amount spent.
2. Before the call, work out the worst case (layer 1) using a model-price table you maintain, not numbers typed into the workflow. Reserve it with one conditional update. If no row comes back, don't make the call. Route to Stop and Error.
3. After the call, move the actual usage into "spent" and release the rest. Anthropic's Messages API returns input_tokens and output_tokens in a usage object ^[16]. On error, release the whole reservation.
4. Also log each reservation as its own row with a timestamp, and sweep those older than a few minutes, so a crashed run doesn't lock the budget.
5. If the database doesn't answer, the answer is no. A cap that lets calls through when it can't check isn't a cap.

In PostgreSQL:

-- Amounts in your billing currency.
create table client_budget (
  client_id text    not null,
  period    date    not null,          -- month start
  cap       numeric not null,
  reserved  numeric not null default 0,
  spent     numeric not null default 0,
  primary key (client_id, period)
);

-- Before the call. $3 = worst-case cost. No row returned = no call.
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;

-- After the call. $3 = the reservation, $4 = actual cost.
update client_budget
   set reserved = reserved - $3,
       spent    = spent + $4
 where client_id = $1 and period = $2;

Run it from n8n's Postgres node with Execute Query, and pass the values through Query Parameters ($1, $2 …), which n8n sanitises ^[17]. The conditional update holds up under parallel executions: in PostgreSQL's Read Committed mode, a second update waits for the earlier one and then re-evaluates its WHERE clause against the updated row ^[18]. Two runs can't both squeeze into the last of the budget.

The AI Agent node makes its model calls internally, so you can't check the budget between iterations. Reserve the worst case for the whole run before the agent node. If your setup doesn't give you the run's actual token usage, settle at the reserved amount and correct it against the provider's usage report (layer 9).

n8n Data tables are handy (Insert, Update, Upsert, Get and If Row Exists operations, 200 MiB by default) ^[19][20], but their documentation describes no atomic conditional increment. A read-then-write counter can let two parallel executions both pass, so use a real database once runs overlap.

Layer 7: A hard limit at the provider

Your own budget can have bugs. Set a hard limit at the provider as the last line of defence.

OpenAI added hard spend limits for organizations and projects in July 2026. Affected requests return HTTP 429 once tracked spend reaches the limit ^[21]. For a project, the path is Project settings → Limits → Spend → Edit spend limit ^[11]. OpenAI's documentation adds two cautions: spend alerts only send a notification while traffic continues, and "Enforcement is not instantaneous, so recorded spend can slightly exceed the configured amount" ^[11]. The help-center article on projects still describes a project's monthly spend limit as a soft threshold ^[14], so check which kind you've set. Projects can also restrict which models they may use ^[14].

Anthropic. In the Claude Console, each workspace has a Spend limits tab for a monthly cap and alerts, and a Rate limits tab ^[15]. Workspace limits can be lower than the organization's but not higher, and you can't set limits on the default workspace ^[15][12]. An API key scoped to a workspace only works in that workspace ^[15].

One project or workspace per client, each with its own key, gives you a provider-side ceiling per client. It backs up layer 6 rather than replacing it: it can react late, and it doesn't tell you which workflow caused the spend.

Layer 8: Ask before expensive or irreversible steps

For tools the agent can call, n8n has a Human review step. Click the Tools connector on the AI Agent node, find Human review in the Tools Panel, choose a channel and attach the tools that need approval ^[22]. The channels are Chat, Slack, Discord, Telegram, Microsoft Teams, Gmail, WhatsApp Business Cloud, Google Chat and Microsoft Outlook. The reviewer sees the tool and its parameters. On approval the tool runs with the AI's input. On denial it doesn't run ^[22].

Outside the agent, use a send-and-wait operation, such as Slack's Send and Wait for Response ^[23] or Gmail's option to send a message and wait for approval with Approve Only or Approve and Disapprove buttons ^[24]. Or use a Wait node set to On Webhook Call, with $execution.resumeUrl in the link you send ^[25]. Three details matter:

• The resume URL is unique to each execution, and the webhook can require Basic, Header or JWT authentication ^[25].
• Turn on Ignore Bots, which ignores link previewers and web crawlers ^[25]. Otherwise an email client's link preview could approve on your behalf.
• Limit Wait Time makes the workflow resume automatically when the limit is reached ^[25]. After the Wait node, check that an explicit approval arrived, and treat anything else as a rejection.

The same step works as a spending check: ask before a run whose worst case is above a threshold you set, or before anyone raises a client's cap.

Layer 9: Log every call, per client

Don't use the execution list as your ledger. On self-hosted n8n, execution data is pruned by default after 336 hours, and at most 10,000 executions are kept ^[6]. Write one row per model call to your own table: client, workflow, execution ID, model, input and output tokens, cost, and the reservation it settled.

To find executions later, the Execution Data node saves metadata you can filter on in the Executions list (keys up to 50 characters, values up to 512). It's available on Cloud Pro and Enterprise and on self-hosted Enterprise and registered Community editions ^[26].

Once a week, reconcile against the provider. OpenAI's Usage and Cost APIs can group results by project with an Admin key ^[27]. Anthropic's Usage and Cost API can filter and group by workspace and API key, needs admin credentials, and its data "typically appears within 5 minutes" ^[28].

Make and Zapier in brief

Make. In the scenario settings, Max number of cycles sets the maximum number of cycles in one run, Number of consecutive errors deactivates the scenario after that many errors in a row, and Sequential processing makes Make finish each execution before it starts the next ^[29]. The last one matters if you keep a counter in a data store, Make's built-in storage shared across scenarios ^[30]: runs of that scenario then can't read the same value at the same time. Among the error handlers, Commit and Rollback stop the run when an error occurs ^[31].

Zapier. The Request Approval action pauses a Zap until reviewers approve, decline or change the data. Reviewers must have a Zapier account, and for a timeout you choose between "Skip and continue" and "End run". Choose End run. The action isn't available on the Free plan ^[32]. Flood protection holds runs when a trigger returns many records at once, by default from 100 ^[33]. Storage by Zapier has an Increment Value action for simple counters ^[34].

The short version

• Max Iterations and Maximum Number of Tokens on every agent.
• Timeout Workflow, hop counters and one error workflow everywhere. No blind retries on model nodes.
• A budget per client, reserved before the call, that says no when the database is down.
• A hard limit per client project or workspace at the provider.
• Approval before anything irreversible or expensive.
• Your own cost log, reconciled weekly.

If you run this for clients

Disclosure: we build Keelstamp, a product for this problem. It isn't released yet, and nothing above depends on it.

The layers above protect your margin, and they're built for you, the operator. Clients often want a say of their own: approve before the agent acts, stop it when something looks wrong, and check afterwards what happened, without taking your word for it.

That's what we're building Keelstamp to do:

• an approval inbox under your agency's brand, where your client approves, rejects or stops an action from their phone, without an n8n account;
• a hard monthly cap per client, checked before each call, that says no when it can't check;
• a signed receipt for every approval, rejection and stop, which your client can verify without trusting you or us.

Questions? Write to contact@keelstamp.com.

Keelstamp is made by PowerQuant ApS, Denmark.