How to Bill Clients for AI API Costs: Pass-Through vs. Markup

The Two Honest Ways to Bill for API Usage

When you build something for a client that runs on a paid API - Claude, OpenAI, or any usage-billed model - you have exactly two honest options for how the client pays for that usage. Pass it through at cost, itemized and separate from your fee. Or fold an estimate of it into a flat fee, with a markup that covers the risk of guessing wrong. Everything else is a variation on these two, and most billing disputes with clients come from picking one without saying so clearly upfront.

Neither option is more honest than the other as long as the client knows which one they are getting before they sign. The dishonest version is the third, unofficial option some builders slide into: an unstated markup buried in an unclear number, discovered by the client later when they compare notes with someone else. That erodes trust faster than almost anything else in a client relationship, because it reads as billing them for something they did not know they were being charged for.

When to Pass API Costs Through at Cost

Pass-through billing means the client pays their own API bill directly, or reimburses you exactly what the usage cost with a copy of the invoice. Your fee for building and maintaining the system is entirely separate and does not move with usage.

• It is the right default when usage volume is genuinely unpredictable - a new build with no history to estimate from, or a client whose usage could spike based on their own growth.
• It removes an entire category of risk from your side. You are not exposed if the client's usage triples unexpectedly, and you never have an awkward conversation about a markup that turned out to be too thin.
• It is simpler to defend. 'You pay Anthropic directly for what you use, and you pay me for the system I built and maintain' is a sentence any client understands immediately, with nothing to negotiate.
• The tradeoff: you give up a real revenue line. Infrastructure margin is standard practice in software, and pass-through means you are the only party in the chain not earning anything on the usage itself.

When a Markup Actually Makes Sense

A markup on API costs makes sense once you have enough real usage history to price the risk instead of guessing at it, and once you are willing to own that risk in exchange for the margin. This is not a default - it is something you earn the right to do by having the data.

If you do markup, price it off your actual historical usage for that client, not a guess, and add a buffer - 15 to 30 percent over your best estimate is a reasonable range depending on how volatile the client's usage has been. State the cap in writing: 'This fee covers up to $X in usage; anything beyond that is billed at cost.' Without a cap, one usage spike from the client's own growth turns your margin into a loss.

Put It in Writing Before the Build Starts

Whichever model you use, the client needs to see it in writing before you start, not discover it when the first invoice or the first surprise API bill arrives. One short paragraph in your proposal or agreement does the job: which model you are using, what the client can expect to pay and when, and what happens if usage runs higher than expected.

Decide Your Model Before Your Next Proposal

Before you send your next proposal for a build with real API usage attached, decide which model you are using and write the sentence that explains it to the client. Default to pass-through if you do not yet have real usage history for this kind of build. Move to a capped markup once you do, and only once you are comfortable pricing the risk instead of guessing at it.