The Six Causes, Ranked
An n8n AI bill almost never doubles for a mysterious reason. In practice it is one of six things, roughly in the order we see them: a retry loop re-running failed calls, a model swap to something several times more expensive, context growing inside an agent's memory, a tool-heavy agent run making far more calls than you assumed, a trigger firing more often than you thought, or one client's workflow quietly scaling. Work down that list in order and you will usually find it inside ten minutes.
1. A retry loop. A failing call that retries three times costs four times as much as one that succeeds, and it produces no output to show for it. n8n's own retry settings, an agent retrying a tool it cannot satisfy, and a provider returning 5xx all compound. This is the single most common cause and the easiest to miss, because the workflow still looks like it ran.
2. A model swap. Someone changed a dropdown from a small model to a frontier one. Nothing else about the workflow changed, so nothing looks different — but the per-call price can be five to twenty times higher depending on which pair you moved between. A workflow doing 500 calls a day at $0.002 costs about $30 a month; the same workflow at $0.02 a call is about $300.
3. Context growth. Agent memory, appended chat history, a document that got longer, a prompt that now includes the last twenty records instead of the last five. Input tokens are billed on every single call, so a prompt that quietly grew from 2,000 to 12,000 tokens multiplies the input cost of every run by six — permanently, and silently.
4. A tool-heavy agent run. An AI Agent does not make one call — it reasons, calls a tool, reads the result, reasons again. Every tool result is fed back in as input on the next call, so a run with six tool calls costs far more than six times a single call. Add one more tool to an agent and the cost per run can jump by half without the number of runs changing at all.
5. A trigger firing more than you thought. A schedule set to every five minutes instead of every hour is twelve times the volume. A webhook that a partner started calling in a loop. A workflow that was manual and got switched to active. The per-call cost is unchanged; the count is not.
6. One client scaling. Nothing broke — a client's volume genuinely went up. This is the good version of the problem, but only if you can prove which client it was and bill accordingly. If you cannot, it looks identical to a bug.
How to Tell Which One It Was
The diagnosis is three questions, in this order, and each one narrows the field considerably.
First: did the number of calls change, or the cost per call? If the call count is flat and the bill doubled, it is a model swap or context growth. If the call count doubled, it is retries, a trigger, or genuine volume. This one question splits the six causes cleanly in half, and it is the question a provider dashboard cannot answer for a specific workflow.
Second: which workflow? Almost every spike is one workflow, not a general rise. Rank your workflows by cost over the period and compare against the period before. The offender is usually obvious once the list is sorted that way — and if the answer is genuinely spread across all of them, you have a pricing change or a provider-wide model default to look at instead.
Third: which step inside it? A workflow-level total tells you where to look; a step-level total tells you what to fix. If one step's cost dwarfs the rest, that is your agent loop or your grown prompt. If cost is spread evenly across steps but the execution count is up, it is a trigger.
How TokenSense Attributes Costs in n8n
When your n8n workflow executes, the community node automatically tracks the name of each node and the execution number. Watch how TokenSense maps the exact cost of every single workflow step in real time.
#98231Finding It Without a Gateway
You can get partway there, and it is worth being honest about how far. Your provider's usage dashboard shows spend by day and by model for the whole organisation. That answers question one — did cost per call change — reasonably well. It cannot answer question two or three at all, because OpenAI has no idea what an n8n workflow is. Every call from every workflow arrives on the same API key and lands in the same bucket.
The common DIY fix is to log token counts to Google Sheets from inside the workflow. It works, and plenty of people run it. Its limits show up exactly when you need it most: it only records the calls you remembered to instrument, the token counts come from the response so a failed or retried call often logs nothing, and you are maintaining a pricing table by hand as models change. In a spike, the calls you did not instrument are frequently the ones responsible.
The structural problem with both is that they measure after the fact. Neither can stop the next spike, only describe the last one.
Finding It in Under a Minute With Attribution
When your AI calls run through the TokenSense n8n node, every call is tagged automatically with the workflow, the step, and the execution ID — no headers, no code, no instrumenting individual nodes. That turns the three diagnostic questions into three sorts of the same table. Worth knowing before you rely on it: the step and execution tags come from the node. If you took the quicker route of only swapping the Base URL on n8n's own OpenAI node, you still get per-request cost and a workflow tag derived from the key, but not step or execution detail — you can send those yourself as metadata, or install the node and get them for free.
A worked example. Spend goes from about $40 a day to about $210 a day. Sorting workflows by cost shows one lead-enrichment workflow accounting for $170 of the increase. Its execution count is unchanged at 500 a day, so it is not a trigger — cost per execution went from $0.08 to $0.42. Opening one execution shows five model calls where there used to be two: the agent picked up a new tool and now loops on it. That is a prompt fix, and it took three clicks to find rather than an afternoon.
Multi-Client AI Cost Allocator
Spend Breakdown By Model
The mechanics of that tagging are covered in the attribution documentation, and the setup itself in the n8n integration guide.
Stopping the Next One
Diagnosis is worth doing once. After that the goal is that a spike cannot get far enough to need diagnosing. Two things do most of the work.
A hard budget cap is the ceiling. Set a dollar budget per workspace, per project, or per workflow, and requests are refused with a 402 once it is exhausted — before they reach the provider, so nothing is billed. This is the difference between finding out on the invoice and finding out at the cap. A runaway retry loop at three in the morning stops at the number you chose rather than running until someone notices.
Alerts are the early warning. A spend anomaly alert compares today's spend against your seven-day daily average, at workspace level or scoped to one project, and fires when it departs sharply from it. A budget threshold alert fires as you approach the cap rather than when you hit it. Neither watches an individual workflow against its own history, so a small workflow can still triple without moving the workspace total — the caps are what protect you there, and the per-workflow view is where you look.
Setting the cap itself is covered step by step in how to cap OpenAI spend in an n8n workflow.
See where your spend actually went. The TokenSense Starter plan is free, includes 10,000 requests a month with full per-workflow and per-step cost tracking, and takes about five minutes to set up.