A single company API key with no attribution becomes a governance problem the first time you need to know who spent what. You cannot see if adoption is real or if one script ran away. You cannot set spending limits because you have no place to set them. You cannot charge back a team or enforce quotas. You end up with a bill and no idea where it came from.
Why attribution matters
Centralised billing has a simple appeal: one API key, one vendor bill, one contract. It is operationally simple. It is also how you lose control.
When anyone can use the company key without a name attached, the incentives misalign. An engineer running a training loop on an expensive model does not see their own cost. A data analyst running an experiment and forgetting it does not learn. A team running an expensive operation does not get feedback on cost. A runaway script does not fail gracefully; it just accumulates charges.
With no attribution, you cannot tell adoption from waste. A spike in costs could mean the tool is working or could mean a bug. You cannot answer a finance question: which teams are users, which are heavy users, is spending growing? You cannot optimise because you cannot see what to optimise.
Most organisations solve this eventually, but usually after a bill surprises them.
What to record per request
Attribution requires recording metadata at the point of each inference or API call.
User identity. Who made the request? This is the minimum. It is usually an ID (employee ID, user ID, email address) rather than a name, for logs.
Timestamp. When did it happen? You need this to aggregate spending by time period, find anomalies, and correlate with other events ("why did spending double on Tuesday").
Model and provider. Which model was used? If your system can route to multiple providers or model families, you need to know which one so you can allocate the right cost.
Tokens or usage. Input and output token counts, or the unit the vendor bills in. This is what the cost actually scales to.
Source context (optional but useful). Where did the request come from? A workflow, a direct API call, a chat interface? This helps you understand usage patterns. Is one application driving all the cost? Is it documented use cases or unexpected uses?
Cost. What did this individual request cost? You can calculate this from tokens and the current provider pricing, but it is useful to record it at the time so you do not have to recalculate later if pricing changes.
That is the core: user, timestamp, model, tokens, source. Store it in a log or a database table. It needs to be immutable (not deleted or edited) and queryable.
What to do with it
Once you have attribution, you can do things you could not before.
Set per-user or per-team limits. A team lead can have a higher monthly quota than an individual contributor exploring the tool. You can enforce these limits: deny the request if the user has hit their quota, or warn and allow (soft limit). Without attribution, you have no place to enforce a limit.
Spot anomalies. If an account usually costs $5 per month and suddenly costs $500, something broke or someone automated a task poorly. You can alert on this. You can ask the user what happened. You can prevent it from happening again.
Charge back or allocate costs. Finance can see that the research team spent $3000 on AI this quarter. If the company budgets by team, teams know their spending. They may choose cheaper models or reduce volume. This is useful feedback only if they see the cost.
Measure adoption trends. You can count monthly active users, see if usage is growing, and tell adoption from one-time exploration. Is each team using the tool, or just a subset?
Optimise routing. If you see that a certain team is hitting expensive models for simple tasks, you can suggest cheaper alternatives. You cannot optimise what you cannot measure.
Audit compliance. In regulated industries, you may need to show who accessed what and when. Attribution logs let you answer those questions. Without them, you have no audit trail.
The architecture
How you build this depends on your setup. If you control the API layer — you run a server that wraps the vendor's API — you can intercept every request, log it, and decide whether to allow it. This is straightforward: before sending to the vendor, log the user and parameters; after receiving, log the usage and cost.
If your application calls the API directly and you cannot interpose, attribution becomes harder. You would need to enforce limits at the application level, which is error-prone (a misconfigured app can ignore your limits). You might also require the application to send headers or parameters that identify the user, and parse those from vendor logs after the fact — but this is brittle.
A platform like Nodus Veritatis records usage per member and per model, and can enforce per-member limits. This handles attribution and limits without requiring your application to implement its own tracking.
Getting started
Start small: log user, timestamp, model, tokens, cost. Store in a table or log file. Query it weekly at first. Do you see the adoption pattern you expected? Do any users stand out as heavy users? Do any costs look wrong?
Once you have a log, you can build on it. Add limits. Add alerts. Build dashboards. But the log is the foundation. Without it, you are operating blind.