How to Track and Bill AI Costs Per Client: A Guide for Consulting Firms (2026)

Consulting firms we talk to are now seeing AI as a core cost of delivering each client project. Finance needs to know how much AI each client's work used, how much was internal, and how to recover the cost in client pricing. But it’s not easy for most firms to answer those questions.

This guide starts with an example of how that plays out at a consulting firm. Then it covers how to tie each tool's usage to a client, handle costs shared across clients, and decide how to charge clients for AI.

A consulting firm's AI cost problem

The request came in during the new head of AI operations' first week: finance wanted to know what AI was costing each client. The firm had a few hundred engineers using Claude, Cursor and the OpenAI API every day, nearly all of them billing their time to client projects.

Finance expected the vendor bills to show this, but Anthropic broke spend down by workspace and API key, OpenAI by project and key, and Cursor by user. None of them showed spend by client.

The engineering lead had a workaround already in place: a separate API key for each client's repository. For most of the code, it held. But engineers move between clients during the day, and when one forgot to switch keys, that client's usage landed on someone else's tab. Claude Desktop and Cowork had no key to switch at all, and Anthropic kept changing how it attributed that usage.

Some engineers also split their month between two clients and an internal project, and the seat bill had no way of showing that. By the end of the week, finance still had no per-client number it could put on an invoice.

Two kinds of AI cost

The firm's first problem, bills that never mention a client, starts with the fact that AI tools charge in two different ways. Some charge a monthly fee per person, and some charge for every token processed. Each kind reaches a client by a different route, so it helps to sort the bills before trying to allocate anything.

Seat-based costs

A seat belongs to a person, so its cost can only reach a client through that person's work. More and more seats also carry a usage meter on top of the fee. Claude Enterprise bills all usage separately at API rates with no included tokens, and Cursor's Teams seats bill token rates once a person's weekly pool runs out. For these tools the seat fee is often the smaller part of the bill, but the usage is still reported per user, so it follows the same route to a client as the seat.

Usage-based costs

API usage is billed per token, and Claude and OpenAI rates vary widely from one model to the next, so a single agent workflow or large refactor can move a month's bill. Every request carries an identifier, such as the key, workspace or project it was made with, so usage can be traced to a client without timesheets, as long as the identifier was right when the request was made.

Measuring AI cost by client

With the bills sorted, the next job is linking each one to a client. That link can come from four places: the credential a request was made with, a tag attached to the request, a gateway every request passes through, or records of who worked on what. Most firms need more than one, because no single method covers every tool.

What each tool reports

Start with what the vendors already give you. None of them report by client, but each reports by something you can map to one.

Each vendor exposes this data through its own API, such as Anthropic's Usage and Cost API, OpenAI's Costs API and Cursor's Admin API. In general, API tools report by credential and seat tools report by person, and the methods below follow the same split.

By credential

The simplest link is a separate credential for each client: an Anthropic workspace, an OpenAI project, an AWS account or IAM role, or at least a dedicated API key. Every request made with it lands on that client's line in the vendor's report, with no extra tooling.

This works best where the key is set once in configuration and left alone, such as a client's repository, pipeline or deployed application. It fails wherever a person has to pick the key. An engineer working on two clients in one afternoon has to remember to switch, and when they don't, the usage goes to the wrong client with no error to flag it. Desktop tools like Claude Desktop and Cowork don't take a per-client key at all.

By tagging each request

Tagging puts the client on the request instead of the credential, so one shared key can serve many clients. The main options:

• Amazon Bedrock accepts request metadata, key-value tags such as a client or project ID, on each call. The tags land in model invocation logs, not in the AWS bill, so you need a tool that reads those logs.
• Bedrock can also allocate cost by IAM user or role. Tag the role a client's workloads run under, and its costs show up under that tag in the Cost and Usage Report.
• Claude Code adds any custom attributes you set, such as client=acme, to its cost metrics. Admins can set them for everyone in managed settings, but they apply per machine rather than per project.

Tags set by application code or a gateway are dependable. Tags a person has to change every time they switch clients fail the same way keys do.

Through a gateway

A gateway such as LiteLLM sits between engineers and the model providers. Each person, team or client gets a virtual key with default tags, and the gateway logs spend by key and tag across every provider it routes to. That gives you one record across vendors, with tags set centrally by an admin instead of by each engineer.

A gateway only sees traffic routed through it, though, so seat tools like Claude Enterprise and Cursor's built-in models fall outside it, and your team has to run and maintain it.

By time and assignment records

For seats and per-user usage, the link to a client runs through the person, and most consulting firms already keep the records needed: timesheets, resource plans or staffing in a professional services tool. Each person's AI cost is split by their share of time on each client, so someone who logs 60% of the month to one client and 40% to another has their AI cost split the same way.

Time records assume AI use tracks time evenly, which won't always be true. They are also the only option for desktop tools, and the only method that needs no change in how engineers work.

Which methods hold up

The methods differ mainly in what they depend on. The most reliable ones are set up once in configuration and don't depend on anyone remembering to do something.

In practice that means credentials or tags for anything automated, time records for seat tools and desktop apps, and nothing that relies on an engineer remembering to switch. Vendors also change how their desktop tools report usage, so check your mapping after major product updates.

Costs that don't belong to one client

Even with good links in place, some AI cost won't map to a single client. It falls into two groups: people who work for several clients, and work that serves the firm itself.

People on several clients

Split per-person costs by the same time shares used for seats. If part of someone's usage is already tagged to a client through a key or tag, allocate that part directly and split only the untagged remainder, so nothing is counted twice.

Decide once whether internal projects get a share of a person's time and cost, and apply the same rule every month. A rule that changes from month to month makes per-client numbers impossible to compare.

Baseline and internal work

Some AI spend is the cost of running the firm: internal tools, sales proposals, research and experiments, onboarding and training. There are two ways to handle it:

• Treat it as overhead and keep it off client allocations. This is simpler, and clients don't pay for each other's experiments.
• Spread it across clients by revenue or hours. This shows the full cost of serving each client, but it's harder to explain if a client ever sees the number.

Either way, report baseline cost as its own line, alongside an unallocated line for spend nothing could be mapped to. The unallocated line shows where the links are missing, and it should shrink as they improve.

Charging clients for AI

Per-client numbers also settle the second question from the opening story: how AI shows up on a client invoice. Firms handle this differently. Digiday found agencies splitting between metering AI costs to clients, showing them at cost as a line item, and absorbing them, and others build AI into their rates. Each approach needs a different level of precision from the numbers above.

Absorbing it

The firm treats AI like laptops or software licenses and recovers it through margin. Full-service agency RPA covers clients' token costs because the benefits are still uncertain, and one agency leader called passing costs on "a money grab." This needs no client conversation, but the firm still needs per-client numbers internally to see which engagements AI is eating into.

Building it into rates or retainers

The firm raises blended rates or retainer fees to cover expected AI use. Kepler doesn't pass token costs through because it works mainly on retainers. This works when usage is steady, and it gets risky when one client's usage climbs well above the estimate. Under the ABA's Opinion 512, lawyers who bill hourly must bill their actual time, so time AI saves can't be billed, which pushes firms toward fixed fees or a separate charge.

Showing it at cost

AI appears as a line item at what the firm paid, the way travel does. Lerma/ includes tokens at cost in its estimates with no markup. This is the most transparent approach, and it needs the most defensible numbers, because the client's finance team will check them.

Metering it or selling credits

The firm charges by units of use or sells prepaid credits. Brandtech's Pencil sells generation credits priced by volume, with top-ups when a client exceeds its allocation. This fits firms that run AI products or platforms for clients, and it needs per-request metering to work.

What clients will want to see

Clients who pay for AI will ask how the number was produced. Digiday expects client CFOs to scrutinize pass-through token costs, and Ebiquity's CEO expects clients to audit token usage the way they audit media spend. Be ready to show:

• Which tools and models the charge covers
• How usage was tied to their work, whether by key, tag or time share
• Whether any shared or baseline cost is included
• Whether there's a markup
• Any cap or budget agreed upfront

Agree on the basis for the charge before the work starts. In law, Opinion 512 requires it, and in most other services it avoids disputes when the invoice arrives.

How nOps handles AI cost allocation

Allocating AI cost to clients means pulling spend from every AI vendor and cloud, mapping it to clients through keys, tags and people, and splitting whatever is left, every month, while vendors keep changing how their tools report usage.

That's where nOps comes in: helping FinOps teams see and allocate AI spend alongside the rest of their cloud costs, down to the client, team and user.

• Unified visibility brings spending from AWS, GCP, Azure, AI and SaaS into one place, with budgets, forecasts, reports and hourly anomaly detection that flags spend running 3x over its usual baseline.
• Cost allocation maps that spend to clients automatically using metadata. Easily assign spend to a client directly or split shared and per-person costs by your desired method, whether custom percentage, share of spend, or evenly.
• AI Wallets set spend limits at the seat or group level and send predictive alerts before a seat runs through its usage pool.

Book a demo to see your AI spend by client, team and user across your AI tools and cloud.

nOps manages $5B+ in AI and cloud spend and was recently rated #1 in G2's Cloud Cost Management category.

FAQ

Demo

AI-Powered Cost Management Platform

Discover how much you can save in just 10 minutes!

Book a Demo