For those running n8n workflows for multiple clients. One OpenAI/Anthropic account, several clients’ workflows on it. How do you actually know who used what when the bill comes?
I’ve seen people use the “log costs to Google Sheets” template workflows, some just estimate on the invoice, some make each client bring their own API key. Curious what actually holds up at 5+ clients, especially when re-billing with a markup.
Also, has anyone had a workflow loop and quietly burn through credits before you noticed? How did you catch it?
1 me gusta
are they bringing their own key or is it all on your account? that fork changes every answer downstream.
the sheets-logging templates hold up fine until you add a sub-workflow call or a parallel branch, then attribution quietly goes sideways. execute-workflow nodes don’t carry the parent’s client tag unless you pass it through explicitly, so the sub-workflow’s tokens land in whatever bucket it defaults to. at 5+ clients that’s where the markup math starts lying to you.
the loop thing is real. had a webhook retry chain go infinite because my error handler was hitting the same endpoint, ate about $40 in tokens before i noticed. what actually saved me was a hard monthly cap at the provider, not anything inside n8n, since a runaway workflow won’t stop itself but the api will. then a cheap alert on any workflow firing more than X times an hour.
are you marking up raw cost or flat fee on top? changes whether you need per-call precision or just a decent estimate.
The attribution problem across sub-workflows is the real issue - the Google Sheets logging template breaks the moment you call Execute Workflow.
What holds up at 5+ clients: tag every workflow name with a client prefix in n8n itself (e.g., [ClientA] Lead Scorer), then after each OpenAI/Anthropic call, log $workflow.name, $execution.id, and usage.total_tokens from the API response to a Postgres or Airtable table. The workflow name carries through sub-workflow executions and gives you a reliable attribution trail even when calls are nested.
For the runaway loop issue - hard monthly caps at the API provider level plus a rate check in workflow static data (if runs-per-hour exceeds X, stop and alert) is the only reliable defense. The Sheets log catches it after the fact; the static data counter catches it before the damage compounds.
mostly on my account, which is why the fork hurts. Client-owned keys kill the markup option and cost-plus markup, so per-call precision matters, can’t invoice off estimates. your provider-cap point is the one that stuck: enforcement has to live at the api boundary, nothing inside n8n can stop a loop n8n is running. that’s basically what I ended up building. Per-client caps enforced at the boundary + a usage statement per client. launching this week, free credits if you want to break it
I built LumaTrack (lumatrack.io) to tackle a problem similar to this. It’s a P&L for automation and AI. @Sakshit could you check out the Free tier and see if that handles your use case? We have a verified n8n node that allows you to pass in the AI tokens (or the token cost) which can help you determine which ones are providing actual value.
If it currently falls short of what you’re looking for, the foundation is there, and I can add some functionality that lets you attribute token costs per client/tenant. Would that be useful to you?
Hey Jonathon thanks, will take a look at the free tier. Quick question while I have you: when MSPs come to you, is it usually because they need to prove value to a client, or because a bill surprised them? Trying to get a read on which pain is the sharper one.
that’s the right place to put it, and building it yourself makes sense when the markup is the business model.
one thing worth locking down before it faces a client invoice: retries. a call that failed and got retried three times can land in the usage statement as four, and an invoice that overcharges costs you more trust than an outage does. so the meter needs to dedupe on an idempotency key rather than count requests, and you need an explicit decision on whether a failed call is billable at all. clients will ask, and “it depends” is the wrong answer when it’s on a statement with their name on it.
going to pass on the credits, my time’s all in paid builds at the moment. good luck with the launch, the per client statement is the bit that’ll sell it.
A little of both. Some, especially MSPs, have a responsibility to show their clients a figure on how much their automations saved them. At the very least, it’s a good business concept as it can make or break a renewal. Other companies may not have that responsibility, but need to know which workflows are paying them back, and which ones are burning budget without any value being produced. Those companies get to learn which workflows to cut, which is arguably more valuable than just knowing which are paying off.
good catch on retries, that’s a real gap. going to check how the meter handles it before anyone’s client sees a statement.
where i’ve landed: a failed call that never returns tokens isn’t billable, and a retry that succeeds bills once. so it needs to key on the provider’s request id, not count requests. explicit rule on the statement rather than “it depends.”
and yeah, statement over caps is the read i’m going with, you and jonathon both landed there independently.
all good on the credits, appreciate you thinking through it either way. it’s live at trymandate.dev if you ever want to point a client at it.
hey, you gave me the best answer on that attribution thread a few weeks back. built the thing, trymandate.dev
went the proxy route instead of the workflow name prefix, mainly because the prefix tells you who burned it after the fact but nothing stops them. hard cap sits at the api boundary, sub workflow attribution via a tag header.
would you be up for poking at it and telling me where it breaks? free credits, no pitch. you clearly run more clients than i do and i’d rather find the holes from you than from someone’s invoice.