Everyone selling you an AI agent shows you the demo. Almost nobody shows you the bill. So I took a support agent I'd built in n8n and ran it 100 times in a row — the same 12-ticket inbox, over and over — to find out what an agent actually costs when it's doing real work.
That's 1,200 real model calls. Here's what the meter said, and the two things the exercise taught me that the pricing page never will.
The setup
The agent is three code nodes in self-hosted n8n:
- Load the tickets and a small knowledge base.
- Answer or escalate — the model may only answer from the knowledge base, and it must cite which entry it used. No citation, no answer: the ticket escalates to a human. (This is the rule that keeps it from being a hallucination hose.)
-
Gate + receipts — deterministic code decides whether the model's answer counts, and writes
answered.json/escalated.json/summary.json.
To measure cost, I wrapped the whole inbox in a loop and ran it 100 times. Every model call goes to meta-llama/llama-4-scout through fal, which bills a flat rate per request, and every response carries an x-fal-billable-units header you can check yourself.
The bill
- 1,200 calls (100 runs × 12 tickets)
- fal's public rate: $0.001 per request, flat
- Total: $1.20
Per ticket, that's a tenth of a cent. Scale it out: a thousand tickets a month is about $1 in model calls, plus a ~$4 box to run n8n on. Call it five dollars a month, all in.
For comparison, Intercom's Fin — the market leader — charges $0.99 per resolution (their public price). Fin is a whole platform: inbox, routing, analytics, compliance. This build is none of that. But the raw model work inside that 99 cents? A tenth of a cent. The other 98.9 cents is packaging. Sometimes worth it — now you know what it's for.
The part nobody measures: consistency
Cheap is worthless if it's random. So I ran the same 12 tickets through all 100 passes and asked a different question: did the agent make the same decisions every time?
- 98 of 100 runs came back identical: 9 answered, 3 escalated, the same tickets every time.
- The 2 runs that differed? The agent got more careful, not less — it escalated one extra ticket instead of answering it.
That's the number I actually care about before trusting an agent with customers. A model that's cheap but non-deterministic in a decision path is its own kind of outage. The citation gate is what holds it steady: the model votes, and deterministic code decides whether the vote counts.
The honest part
Two things this bill leaves out, and one real failure:
- It excludes your build time, keeping the knowledge base current, and connecting a real helpdesk (that's OAuth and webhooks I didn't pay for here).
- Short tickets are cheap. Longer conversations mean more tokens, so token-priced providers will cost more than this flat-per-request math suggests.
-
My first run died at exactly 5:00. n8n ships a default task timeout of 300 seconds, and 1,200 sequential calls blew past it. One environment variable (
N8N_RUNNERS_TASK_TIMEOUT) fixed it. Round-number failures are almost always a config default, not your logic.
The math is the part that lasts: count your calls, multiply by your provider's public rate, and read your own bill. Don't estimate it — measure it.
Try it yourself
The whole workflow, the demo tickets, and the run receipts are here:
👉 https://github.com/Ships-Itself/builds/tree/main/ep05-cost-teardown
Import the workflow, point EP05_DIR and FAL_KEY at your setup, and hit execute. It writes its own receipts so you can check my numbers against yours.
I build one of these on camera each week and publish the real numbers — including the failures. If that's your thing, the video version of this teardown is on the Ships Itself channel.
Top comments (0)