AI API costs explained: how to estimate before you build
AI API pricing looks simple and surprises people constantly. Here's how to estimate properly.
Tokens, briefly
You're billed per token, roughly ¾ of a word for ordinary English. Code, JSON and markup tokenize much less efficiently — often closer to one token per three characters.
Input tokens (what you send) and output tokens (what comes back) are priced differently, with output typically several times more expensive.
The mistake everyone makes
Underestimating input.
People think about the prompt they wrote and forget the data attached to it. If you're sending a page of HTML, a PDF's contents, or a JSON API response, that's the bulk of your bill.
A 500-word instruction is around 650 tokens. A page of raw HTML can be 5,000+. The instruction is a rounding error.
Estimating a real workflow
Take the audit tool on this site:
| Approx tokens | Note | |
|---|---|---|
| Instructions | 700 | The prompt itself |
| PageSpeed data | 4,000 | Truncated to 12,000 chars |
| Page HTML | 4,700 | Truncated to 14,000 chars |
| Output | 1,500 | Report, capped at 3,000 |
At Sonnet-tier pricing that lands around four US cents per run. A hundred audits is roughly four dollars.
The important design decision is the truncation. Capping inputs means a bloated e-commerce homepage costs the same as a lean landing page. Without caps, one submission could cost twenty times another and you'd have no way to predict spend.
Where costs run away
Sending whole documents when you need a section. Retrieve the relevant part first.
Conversation history in loops. Multi-turn agents that resend the full history each turn grow quadratically. This is the classic runaway bill.
No output cap. Set max_tokens. Always.
Using a frontier model for a simple task. Classification and extraction rarely need the most capable model. The cheaper tiers are often within a few percent on these tasks at a fraction of the price.
Practical controls
- Truncate every variable input to a defined character count.
- Set max_tokens on every call.
- Match model to task. Test the cheap one first; upgrade only if quality genuinely fails.
- Cache what repeats. If the same input recurs, store the result.
- Log token usage per call so you can see the shape of your spend.
- Set a billing alert. Non-negotiable for anything user-triggered.
That last one especially. A public tool that anyone can trigger is a public tool anyone can trigger repeatedly.
Modelling before you build
Cost per run × expected runs per month = monthly cost.
Then multiply by three. Real usage includes retries, tests, failures and the fact that you'll iterate on the prompt more than you expect.
If the tripled number is uncomfortable, redesign before building rather than after.
The comparison worth running
Prices move, and the gap between providers and tiers shifts with each release. Before committing to a model for a production workflow, run your actual prompt against two or three options and compare output quality and cost per task.
Cost per task is the number that matters, not cost per token — a model that's twice the price but needs half the context can be cheaper in practice.