How to Bill Clients for AI API Costs: 4 Models (2026)

Quick Answer (August 2026): Agencies bill clients for ongoing AI API costs (the OpenAI or Anthropic token bill an app runs up after launch) using one of four models: bring-your-own-keys, cost-plus pass-through with a markup, a blended flat fee folded into the retainer, or tiered usage bands. The right choice depends on how predictable the app's token usage is, how sophisticated the client is, and who should legally own the model-provider account. This guide gives you the four models side by side, a worked monthly-bill example, and a decision matrix.

Most agency contracts price the build cleanly and then go quiet on the meter that runs forever after. An AI app is not a static website. Every conversation, summary, and classification calls a model provider, and that provider sends a bill every month whether or not anyone thought to put it in the statement of work. Deciding who pays that bill, and how, is now a contract term in its own right, not an afterthought you sort out when the first invoice from the model provider lands.

This is the variable-cost lane. It sits next to, but is genuinely distinct from, the flat maintenance retainer (labor for fixes and updates) and the one-time build fee. Token cost scales with usage, so it needs its own billing logic.

The four ways to bill clients for AI API costs

Here are the four models agencies actually use in 2026, with the trade-off each one makes.

Bring-your-own-keys

The client creates their own OpenAI, Anthropic, or other provider account and gives your app their API keys. The provider bills the client directly. You bill only for labor, through the build fee and the retainer.

This is the cleanest model for high or spiky usage, because the agency never fronts a cost it cannot predict. It is also the honest default when the client is technical enough to manage a provider dashboard. The catch is ownership: the account and its keys become one of the assets that must change hands correctly at the end of an engagement, which is why we treat account and key custody as a first-class handover term in our client-offboarding-ai-app-builds-ownership-terms-agencies-2026 framework. Set it up in the client's name from day one and you avoid an awkward migration later.

Cost-plus pass-through

You hold the provider account, the app runs on your keys, and you re-bill the client the actual usage plus a markup, usually 10 to 30 percent, on a monthly line item. The client gets one invoice from one vendor. You get a small recurring margin for carrying the account and doing the metering.

The discipline this model demands is transparency. You must be able to show the client the real usage that produced the number, or the markup starts to look like a hidden fee. Log token usage per client and attach the provider's own figure to every invoice.

Blended flat fee

You estimate the monthly usage, add a buffer, and fold the whole thing into a single flat "AI operations" line inside the retainer. The client sees one round number and never thinks about tokens. You absorb the variance, so this only works when usage is genuinely low and stable, and it needs a written overage clause: above an agreed ceiling, the flat fee converts to pass-through.

This is the model clients love and agencies lose money on when usage grows quietly. Cap it.

Tiered usage bands

You productize consumption into bands, the same shape most SaaS usage pricing takes. Band 1 covers up to X million tokens for a fixed price, Band 2 covers more for a higher fixed price, and the client self-selects or moves up when they cross a ceiling. Each band carries its own margin, and the client above the top band moves to metered pass-through. This gives the client predictability inside a band and gives you protection at every ceiling.

The arithmetic nobody puts in the proposal

Numbers make the choice concrete. The rates below are illustrative; always pull the exact per-model figure from the provider's live pricing page before you quote a client, because model prices move and vary sharply between input and output tokens (see the Anthropic API pricing page for current figures, and OpenAI's is linked in the Sources).

Take an AI customer-support assistant that handles about 40,000 conversations a month. Each conversation spends roughly 2,000 tokens once you count the system prompt, the retrieved context, the user turn, and the model's reply. That is about 80 million tokens a month. At an illustrative blended effective rate of about $5 per million tokens, the raw model bill is roughly $400 a month.

Here is what that same $400 raw cost looks like under each billing model.

Notice the pattern: the models that hand the client predictability (flat fee, bands) transfer variance risk to whoever holds the account. If that is you, price the buffer honestly and cap it. If the buffer is thin and usage doubles, your margin does not shrink, it inverts.

Which model should you use? A decision matrix

Match the model to the situation, not to habit.

• Unpredictable or high usage, technical client: BYO keys. Do not front a cost you cannot forecast.
• Moderate usage, client wants one bill, non-technical: cost-plus pass-through with a transparent line item.
• Low, stable usage, client is price-anxious: blended flat fee with a hard overage cap.
• Usage that will grow and a client who accepts step pricing: tiered bands.
• Enterprise client with procurement and a security team: BYO keys almost always, because they want the provider relationship, the data-processing terms, and the spend controls in their own name.

Whichever you pick, name it in the ai-app-statement-of-work-template-agencies-2026 up front. The single most expensive mistake in this whole area is silence: an app ships, tokens burn, and the first anyone discusses the bill is when it arrives. If you want to sanity-check the raw per-model math before you quote, the pricing-teardown work at BudgetForge runs the kind of real 30-day cost arithmetic these estimates should be grounded in.

Where the build platform fits (and where it does not)

A point that confuses new agencies: the platform you build the app on and the model provider you run it on are two separate bills. The build platform generates and hosts the code; the model provider charges per token at runtime. Prototyping-first builders like Lovable and Bolt.new charge you for generations and hosting, but the OpenAI or Anthropic calls your finished app makes are billed separately, to whichever account holds the keys.

This matters for the BYO-keys model specifically. If you build resellable, white-label apps for clients, you want a build substrate whose output you fully own and can hand over, so the client can hold their own provider account cleanly. Platforms built for that, such as the white-label option from Totalum, ship downloadable source and let the client take the codebase, which keeps the "who owns the account" question answerable. It does not change the token bill itself; a model call costs what the provider charges regardless of what generated the app. Choose the build platform on ownership and output quality, and choose the billing model on usage and who should hold the account. They are separate decisions.

Common mistakes agencies make

• No line item at all. The build SOW is silent on runtime cost, and the first bill is a surprise for both sides.
• Flat fee with no cap. Usage grows, the flat fee does not, and the margin inverts.
• Markup with no evidence. A pass-through markup the client cannot verify reads as a hidden fee and erodes trust.
• Agency-owned account with no exit plan. When the engagement ends, the app is wired to keys the client cannot access, forcing a rushed migration.
• Quoting a token rate from memory. Model prices change; a stale number in a proposal becomes a loss you eat.

If you take one thing from this: the AI API bill is a variable cost with its own billing logic, not a footnote to the build fee. Pick a model, write it into the SOW, and decide who holds the provider account before a single token is spent.