At the end of a billing period, I want to answer a simple question: how much did each client’s AI work cost?
Most provider dashboards answer a different question: how much did the account spend in total? That number is useful, but it doesn’t tell me how to divide the bill across clients.
The usual workaround is unpleasant. I export request logs, match timestamps to projects, estimate ambiguous records, and maintain a spreadsheet until the numbers look plausible. That process is slow, difficult to audit, and not something I want to use as the basis for an invoice.
The underlying issue is structural: provider billing is organized around my account, while my business is organized around clients.
Use API keys as cost centres
The clean fix is to issue a separate API key for each client—or for each client workflow—and track usage independently per key.
Every request already carries the identity of the key that made it. If each key maps to one client, attribution happens when the request runs instead of during month-end reconciliation. Cost per client becomes a dashboard value rather than something I have to reconstruct from raw records.
This is essentially a cost-centre model:
- One client or workflow gets one clearly named key.
- Requests made with that key accumulate in its usage bucket.
- The bucket reports the client’s spend and activity.
- The invoice is built from those totals.
This is particularly useful when multiple models are accessed through the same unified endpoint. I can keep all client keys and their usage in one account while still getting separate reporting. A unified multi-model API such as CometAPI is relevant here because the alternative is consolidating usage across several provider accounts.
The data available per key
A useful per-key report should expose the dimensions needed to support an invoice:
- Total spend: the dollar cost of requests made with the key during the billing period.
- Request volume: the number of calls, which helps validate activity.
- Token usage: input and output token counts behind the charge.
- Model breakdown: the models used and the cost associated with each.
That gives me more than a single number. If a client’s workload uses an inexpensive model for bulk processing and a frontier model for difficult tasks, the model split explains the resulting total. If a client questions the bill, I can provide usage and token context rather than presenting an unexplained portion of a larger account charge.
Why this is better than the usual workarounds
| Approach | Operating model | Failure mode |
|---|---|---|
| Single key, parsed logs | One key serves every client; usage is reconstructed at invoice time. | Slow, error-prone, and approximate whenever records are ambiguous. |
| Separate provider accounts | Each client gets separate accounts with each provider. | Credentials, dashboards, and invoices multiply quickly. |
| Manual spreadsheet tracking | Usage is recorded by hand as work happens. | It depends on sustained discipline, becomes stale, and compounds errors. |
| Per-key tracking | Each client gets a key on one account; usage is metered automatically. | Attribution is captured at request time and reported directly. |
The important difference is when attribution occurs. The first three options push the work to invoice time. Per-key tracking captures the relationship between request and client at the source.
For two clients, manually parsing logs may be tolerable. For fifteen, it becomes recurring operational work. With fifty clients, it is effectively a part-time job. Per-key tracking requires roughly the same setup pattern at each scale: issue a key, use it consistently, and read the resulting totals.
A setup pattern that holds up
1. Choose the reporting boundary
Start with one key per client unless the client needs separate billing streams. If a client has multiple projects or workflows that should be reported independently, use one key per client-project or per workflow.
Finer-grained keys produce finer-grained reports, but they also increase the number of credentials to manage. I use the smallest number of keys that matches the invoice structure I actually need.
2. Name keys for humans
A dashboard full of opaque key IDs is not a reporting system. Name keys with the client or project they represent so the usage list is immediately readable.
This matters at invoice time: the report should look like a client list, not like a collection of tokens that needs another mapping table.
3. Configure each deployment with its own key
Point each client integration at the corresponding key. In most cases, this is an environment or deployment configuration change rather than an application rewrite.
The important operational rule is that a shared service must not accidentally use a default key for every client. The key selection needs to follow the same client or workflow boundary as the work being billed.
4. Read the totals at the billing boundary
At the end of the billing period, inspect each key’s:
- Spend
- Request count
- Input and output tokens
- Model usage and model-level cost
Those values form the per-client usage report. There is no need to infer ownership from timestamps or manually split an aggregate total.
5. Rotate keys independently
Per-client keys also reduce the blast radius of credential operations.
If a client leaves, revoke that client’s key. If one key is exposed, rotate that key without interrupting every other client. The control boundary and the billing boundary are the same, which is much safer than relying on one credential for the entire operation.
Usage is metered per token against the same published rates regardless of which key made the request. That means the per-key total maps directly to the underlying pricing: the amount charged to the client traces back to the amount charged by the platform, with any agency margin added transparently.
The operational benefits go beyond invoicing
Client-level profitability
Once I can see AI cost per client, I can compare it with the client’s fee. That exposes engagements with healthy margins and those quietly consuming them.
This is useful for repricing, changing the workflow, or deciding whether a particular service should be packaged differently.
Faster detection of runaway usage
A bad loop, misconfigured integration, or unexpected traffic surge is easier to spot when usage is attached to a client key. The increase is visible in the relevant bucket instead of being hidden inside the account aggregate.
Fewer billing disputes
A client asking what they paid for can receive an explanation based on request volume, token counts, and model usage. That is more defensible than assigning them an estimated share of a lump-sum provider bill.
Better estimates for future work
Historical per-client usage gives me real data for quoting similar projects. Instead of guessing how much model usage a new engagement might require, I can use comparable workflows and their actual costs.
At larger agencies, the same account-level controls—team access, spending visibility, and administrative oversight—turn this from a billing convenience into an operational control. Per-key attribution is useful on its own, but it becomes more valuable when it is part of the broader account governance model.
The practical pattern
Provider dashboards generally make total account spend easy to see. They do not automatically know which client should receive each portion of that total.
The solution is to make client identity part of the request path:
- Issue one key per client or billable workflow.
- Give each key a clear name.
- Configure the matching integration to use it.
- Review per-key usage at the invoice boundary.
- Revoke or rotate keys independently when necessary.
That changes month-end reconciliation from log analysis into reporting. It also creates a useful operating dataset for profitability, anomaly detection, client conversations, and future estimates.
The dashboard behavior and per-key workflow described here were checked against platform documentation in June 2026. Platform features evolve, so specific reporting and administrative capabilities should be confirmed against current documentation before making them part of a billing process.
Originally published at cometapi.com
Top comments (0)