How to Bill Clients for AI API Usage

The cleanest answer to how to bill clients for AI API usage is to not bill for it at all. Put the account in the client's name, let the provider invoice them directly, and charge only for your work. Everything else in this article exists because that answer is often unavailable, and because the alternatives fail in predictable ways.

The failure looks the same every time. You quoted a project, absorbed the model costs as a rounding error, then the client's usage grew fivefold in month three and you are now subsidising their business out of your margin.

Decide who holds the account first

This decision drives everything downstream, so make it before the proposal goes out.

Client-owned key. They create the provider account, they pay the provider, you get access. Provider invoices them directly, you never touch their spend, and you cannot be accused of marking it up. The tradeoffs: you have less control over rate limits and quota, and you will be on the phone when their card fails and production stops.

Agency-owned key. You hold the account and rebill. Setup is simpler and you control limits, but you are now carrying float, absorbing volatility, and holding a liability if the client leaves owing three months of usage. If you go this way, that liability needs a number attached in the contract.

For anything ongoing, push hard for client-owned. It is the arrangement that stays fair when volume grows in either direction. The related question of who owns the account when the engagement ends belongs in the same conversation as handing an AI-built app off to a developer.

Four ways to structure it

Direct pass-through

Client pays the provider. You bill your time only. Best for ongoing work, retainers, and any client whose usage might grow.

Pass-through with an admin fee

You hold the key and rebill actual cost plus a fixed monthly amount, say a flat fee that covers monitoring, reconciliation, and the invoice itself. Honest, simple to explain, and it does not scale with their usage, which is the point. The fee pays for your handling, not for their tokens.

Usage bundled into a monthly figure

You quote a single number that includes an allowance, for example a set volume of requests, with defined overage above it. Clients like this because it is one predictable line. It only works if you have real usage data to price against, so it belongs in month four of a relationship, not month one.

Markup on cost

You bill actual cost times a multiplier. It is the most common and the worst. It is invisible until the client compares your invoice to the provider's public pricing, and then the conversation is about your integrity rather than your work. If you do it, disclose the multiplier in writing up front.

The numbers to put in the contract

Vagueness here is what turns a billing question into a dispute. Four clauses cover most of it.

A usage assumption, written down. State the volume the quote assumes, in units the client understands: requests per month, documents processed, conversations handled. Not tokens. Nobody outside this industry has intuition for tokens.

A trigger, not a cap. "If monthly usage exceeds X, we pause and reprice" is better than a hard cap that breaks their product at 4pm on a Friday. The trigger protects your margin without making you the reason production stopped.

A model-change clause. Provider prices move, models get deprecated, and a model you priced against can be retired inside the contract term. Reserve the right to switch to an equivalent model, and to reprice if a provider changes rates materially. This is not hypothetical, as anyone who has been through an AI model deprecation can confirm.

A definition of billable usage. Your development, testing, and debugging tokens are yours. Their production traffic is theirs. Say so, because the alternative is billing a client for the afternoon you spent fixing your own prompt.

Instrument before you quote

You cannot price usage you have not measured, and estimates made from intuition are consistently wrong by an order of magnitude in both directions.

Log every call with the client or project it belongs to, the model, input and output tokens, and whether the request hit a cache. Do that from day one, in your own logs, not just in the provider dashboard. Provider dashboards aggregate at the account level, which is useless the moment you have two clients on one key.

Read the provider's own pricing page rather than a third-party summary, since rates and cache discounts change and the summaries lag. Anthropic and OpenAI both publish current rates directly.

Then check the obvious cost levers before you quote, because they change the number substantially: whether a cheaper model handles the task, whether a stable prompt prefix makes caching worthwhile, and whether anything can run in a batch mode at a discount. There is more on this in reducing AI API costs.

What the invoice should show

An AI line item invites scrutiny, so make it survive scrutiny.

Show the period, the volume in the client's units, the provider cost as a distinct figure, your fee as a separate figure, and a one-line note on anything unusual. If usage jumped 40%, say why, before they ask. An invoice that explains itself does not generate an email.

Keep your handling charge separate from the pass-through amount, always. The moment those two are merged into one number, every future conversation about cost becomes a conversation about whether you are marking it up.

FAQ

Should I mark up AI API costs?

Generally no. Margin belongs on your work, where it is defensible, not on a commodity the client can price-check in thirty seconds. If you need to cover handling, charge a visible fixed fee instead.

What if the client's usage suddenly spikes?

This is what the repricing trigger is for. Reach out when it crosses, share the numbers, and treat it as a scope conversation. The framing in handling scope creep on an AI project applies directly.

Do I bill for tokens spent debugging?

No. Your development and testing usage is a cost of doing business, and billing it reads as sloppy even when it is technically permitted. Separate the keys so the split is automatic rather than a judgement call each month.

How do I explain token costs to a non-technical client?

Convert to their units before the conversation: cost per document, per conversation, per customer. The full approach is in explaining AI costs to a client.