Fronting AI API costs for clients: how to bill with cost reports

If you’re a freelancer or run a development service, this pattern is familiar: the client agrees to build a chatbot, you front the API token cost first, the project runs, then comes the moment to bill “last month’s usage”. And that’s where the fight starts. What exactly was the usage? Why is this month more expensive? Proof?

Our short name for this problem: fronting without proof. This article covers the working setup that removes the argument: one key per project, a budget limit per client, and a per-request cost report that attaches to the invoice.

Why “proof” is the main problem

API tokens get fronted because that’s simply how it works: the API needs balance, the balance is bought first, then the project runs. What makes it a problem is not the fronting itself but that usage isn’t separated per client:

• All clients share one account, one key, one balance. Client A’s and B’s usage mix in one report.
• Billing becomes an estimate (“roughly Rp200k”), and estimates are fuel for arguments.
• When the project ends, you still carry the risk of continued usage you don’t control.

The first two are solved by the right account structure. The third is solved by a brake.

The correct setup: one key per project

With Giant Router, the structure that becomes the working standard:

1. One API key for one client project. The key is created in the dashboard for as long as the project runs. That key’s usage is recorded separately from other keys; from the first request to the last.

2. A budget limit is set per key. Set it per the deal with the client; say Rp100,000 for one project phase. Requests stop at the limit. That means your worst case per project is the amount you already agreed on, not a balance that suddenly blows up. The balance cannot go negative.

3. Per-request cost reports. Every request is recorded: model, tokens, cost, time. When you bill the reimbursement, attach that report. Not an estimate: per-request figures the client can check themselves.

4. A locked payment quote. When you top up, the rate and the USD credit amount are shown before you pay and locked per invoice. The conversion rate doesn’t become a gray area in your report.

Example invoice line (template)

API token reimbursement: Our Shop Chatbot Project
Period: 1-30 November 2026
API key: "toko-kita-prod" (budget limit Rp100,000)
Recorded usage: 214 requests, total Rp83,450
Detailed per-request report: attachedCopy

A line like this almost never gets disputed, because every number in it can be checked by the client in the attached report. The argument “why did it reach that much?” turns into “okay, matches the records”.

The cost report arrives monthly, just forward it

That report is not something you assemble yourself from the dashboard. On the 1st of every month, Giant Router emails a monthly cost report to your account’s email: usage details per API key (your key’s name becomes the project’s name), with request counts, tokens, and cost per request in rupiah. The format is ready to attach to an invoice, and the matching fronting invoice template you just fill in is available as its companion; ask for it by email at halo@giantrouter.my.id if you haven’t received it. Other cost guides are in Guides.

A cost quote template for the deal (before the project runs)

Fronting problems often start with a deal that never mentions token costs. Add this to your quote:

AI API costs are billed per actual usage (not flat), with a per-request cost
report as proof. Estimated usage for this scope: RpX-Y per month. We set a
budget limit per project at the agreed amount; if usage approaches the limit,
we confirm with you before adding more.Copy

These sentences stop you from silently funding the client, and let the client know from the start that their API cost is transparent.

Why not to use shared accounts for client work

The “buy a cheap sharing package, one account for all clients” pattern has two serious problems for freelancers: your usage trail mixes with strangers’ on one account, and once that account is blocked by the provider (sharing patterns are the most common mass-ban candidates), ALL your client projects stop at the same time. For work billed to clients, a key isolated per project through an official gateway is the correct standard; the structural explanation is in official API, not shared accounts.

Two common objections (and the answers)

“The client can see how much I paid for tokens, they’ll bypass me and buy directly.” It happens, and honestly: if all the value you sell is “a person who has a credit card”, that is indeed your fate. But most AI service projects are sold as work product (architecture, integration, maintenance), not token access. The cost report actually strengthens your position there: the client sees honest, professional usage, and you can include the quote template above in every future deal so the rules are clear from the start.

“If tokens are billable per request, what about the trial-and-error during development?” Development experiments are also real usage; separate the key. A development key with a small limit for your own experiments; a production key per client per the deal. The development usage report doesn’t go into the client’s invoice, and you still keep a clear picture of your experiment costs.

Start from one project

You don’t have to move all your work at once. Take one running project, create a dedicated key for it with a small budget limit, run one week, then read the report. If the report format is enough to bill from (and it usually is more than enough), move the other projects over one by one.

Set your first key for a client project, starting at Rp10,000 →