How API billing works
Every LLM provider bills the same way: you pay per token, at separate rates for input (what you send) and output (what the model generates), quoted per million tokens. The whole calculation is one line, applied twice:
cost = tokens × price-per-million ÷ 1,000,000
A token is roughly 4 characters of English text, about three-quarters of a word. So a 1,000-token prompt is around 750 words, and a 500-token response is a solid few paragraphs.
Worked example
Say your product makes 1,000,000 requests a month, each sending 1,000 input tokens and receiving 500 output tokens, on a model priced at $3/M input and $15/M output:
| Direction | Tokens/request | Price | Monthly cost |
|---|---|---|---|
| Input | 1,000 | $3 / M | $3,000 |
| Output | 500 | $15 / M | $7,500 |
| Total | 1,500 | - | $10,500 |
Notice the shape of that bill: output is a third of the tokens but 71% of the cost. That asymmetry is the single most useful thing to know about LLM pricing, the model's verbosity, not your prompt length, is usually what you are paying for.
Why we ask for prices instead of assuming them
This calculator deliberately has no built-in model price list. Provider pricing changes monthly: models launch, prices drop, tiers appear, old models retire. A hardcoded table would be quietly wrong within weeks, and a cost estimate built on stale prices is worse than no estimate. Instead, you paste the current per-million prices straight from your provider's pricing page, and the arithmetic is guaranteed current. It also means the page works for every provider and every model, including the ones that don't exist yet.
The levers that actually cut the bill
- Cap output length. Output is the expensive direction. Set a max-tokens limit, ask for concise answers, and stop paying for prose nobody reads.
- Route easy requests to a cheaper model. Most workloads are a mix: classification, extraction and short answers rarely need a frontier model. A 10× price gap between model tiers is common, routing even half your traffic down a tier roughly halves that half of the bill.
- Use prompt caching. If every request re-sends the same system prompt, instructions or reference documents, caching bills those repeated tokens at a steep discount (often 90%). For long shared prefixes this is close to free money.
- Trim the prompt. Boilerplate instructions, redundant examples and over-long context all bill at full input rate on every single request. A 200-token trim across a million requests is 200M tokens saved.
- Batch what can wait. Batch endpoints typically run at around half price in exchange for minutes-to-hours latency, ideal for backfills, evaluations and nightly jobs.
Estimating your token counts
For planning, count characters and divide by 4, a page of English text (~3,000 characters) is roughly 750 tokens. Code and non-English text run heavier. If you already have traffic, your provider's usage dashboard shows real per-request averages; feed those into the calculator rather than guessing.
Putting the cost in context
Per-request costs look tiny, the example above is about a cent per request, which is exactly how bills sneak up: nothing is expensive until you multiply by a million. Model the volume you expect at scale, not the volume you have today. If you are pricing API costs into client work, the freelance rate calculator helps make sure expenses like this end up in your rate rather than your margin. For the revenue side of a content business, the YouTube earnings calculator applies the same honest-inputs approach, and the percentage calculator is handy for working out what share of your unit economics the model bill represents.