Tying every AI call back to a flow and a person

Your model provider knows exactly how many tokens you consumed last month. It has no idea which automation consumed them, and it never will. That attribution can only be done on your side, and until it is done, an AI bill is a number you can pay but cannot manage.

This is not a billing problem. It is a governance problem wearing a billing problem’s clothes.

What the invoice can and cannot tell you

A provider invoice gives you, at best: a total, a split per model, and sometimes a split per API key. That is enough to answer “how much” and nothing else.

The questions that actually come up in a review meeting are different:

• Which automation drove the increase this quarter?
• Did it grow because volume grew, or because someone changed a prompt?
• Which department should this be charged to?
• Is this flow using a model far more capable than its task needs?
• If we cut this in half, what stops working?

Every one of those needs a link between a call and a flow. None of them can be answered from the invoice.

Why API keys are not attribution

The common first attempt is one API key per team, or per project. It helps, and it stops helping quickly.

Keys get shared, because creating one requires a ticket and copying one takes a second. A key created for a project outlives it. A flow built by team A gets duplicated by team B with the key still in it. Six months in, the key split describes the org chart as it was, not as it is.

More fundamentally: a key tells you who provisioned the credential, not what made the call. Those are different facts, and it is the second one you need.

What attribution actually requires

Three pieces of information, joined:

1. The call. Which model, how many input tokens, how many output tokens, when. Available from the provider, per request, if you capture it.

2. The flow that made it. This exists only in your automation platform. It is the join key, and it is the piece nobody has by default.

3. The owner of that flow. This exists only in your own records, and often nowhere at all, which is the other half of the problem.

Once those three are joined, the AI bill stops being a total and becomes a table you can sort. Everything useful comes from that table.

Doing the join

There are two honest ways to get the link between a call and a flow, and one that looks like a third but is not.

Tag at the call site. Most providers accept metadata on a request, a user field, a header, a custom identifier. If every flow that calls a model sends its own identifier, the provider’s own logs carry the attribution and the join is trivial. This is the clean answer, and it requires touching every flow that already exists.

Reconcile from both sides. Read the flow definitions from the platform, find the ones that call a model, extract what they send, and match against the provider’s usage records by time and shape. Less exact, requires no change to existing flows, and works retroactively, which matters, because the flows you most want to understand are the ones already running.

Estimate from the flow alone. Read the prompt, count the tokens, multiply by run count. This looks like attribution and it is arithmetic. It is a useful sanity check and it is not a measurement: it does not see retries, truncations, or the variable size of real inputs. Do not present it as the bill.

In practice, a new estate should tag at the call site. An existing estate has to reconcile, at least until every flow has been revisited.

What changes once you have it

Optimisation stops being a guess. “We should use a smaller model” is an opinion. “This one flow is 60% of our AI spend, it is classifying three categories, and it is calling the largest model available” is a decision that takes ten seconds.

Chargeback becomes possible. A cost per flow rolls up to a cost per team. That single change moves the conversation from “AI is expensive” to “your department’s automations cost this much, here is the breakdown”, which is a conversation someone can act on.

Drift becomes visible. The cost of a flow rising 30% with no change in run count means something changed in what it sends. Without attribution, that shows up as a slightly larger invoice and nobody looks. With it, it shows up as one flow moving up the list.

Reviews get an anchor. “Which of our automations depend on an LLM, and who signed off on that?” is a question that will be asked, by a risk committee, an auditor, or a client. Answering it from an invoice is not possible. Answering it from a list of flows with named owners takes one screen.

The prerequisite nobody mentions

All of this assumes each flow has an owner. If it does not, attribution stops one step short: you will know that Flow_v3_FINAL is costing you the most, and you will not know who to talk to about it.

Which is why cost attribution and ownership are the same project, even though they arrive as two separate complaints, one from finance, one from IT. Solve them apart and you get two half-answers. The flow is the unit both of them need, and it is the unit neither platform gives you.

That is the whole reason Synoptial exists, and it is why the first thing it asks for is not a budget but a name.