How to Calculate Your AI API Bill (Developer's Guide)

Last updated: October 2026

Every AI API bill comes down to one thing: tokens in, tokens out, multiplied by the price list. But the gap between "I understand the pricing page" and "I can predict my monthly invoice" is where most teams get surprised.

This guide closes that gap. You'll learn what a token actually is, how the three prices on every rate card work, a formula for modeling any workload, and five practical ways to cut the bill — with real numbers throughout.

What Is a Token?

A token is the unit of text the model reads and writes. As a rough rule of thumb:

• 1 token ≈ 4 characters of English text
• 1 token ≈ 0.75 words

So 100 tokens is roughly 75 words. A typical page of text (~500 words) is about 650–700 tokens.

Why it matters: everything is metered in tokens, but you think in tasks, messages, and documents. The single most useful habit in API cost management is building an intuition for converting between the two. A few anchors:

• A short chat message: 20–50 tokens
• A system prompt for a coding agent: 2,000–8,000 tokens
• A medium source file loaded into context: 3,000–10,000 tokens
• A long document or small codebase: 50,000–200,000+ tokens

Tokenizers differ slightly between providers, but the 4-characters-per-token approximation holds well enough for budgeting. If you need precision, every major provider publishes a tokenizer tool — but for cost modeling, the approximation is fine.

The Three Prices on Every Rate Card

Nearly every LLM API prices three things separately. Understanding why they're priced differently is the key to the whole game.

Input tokens

What you send to the model: prompts, context, conversation history, documents. This is usually the cheapest of the three per-token rates — but in agentic workloads it's often the largest volume, which makes it the largest line item.

Cached input tokens

Input tokens the provider has seen before and kept in cache. When you send the same system prompt or the same repo context for the hundredth time, the provider doesn't recompute everything from scratch — and passes most of the savings to you.

Cached reads are typically priced at 5–10% of the input rate. On GPT-5.6 Sol, for example, cached input is $0.40/1M versus $4.00/1M fresh — a 90% discount. That single pricing detail reshapes how you should architect: anything stable and repeated (system prompts, few-shot examples, repo context) should be structured to hit the cache.

One caveat: writing to the cache usually costs extra (1.25x the input rate on GPT-5.6 Sol). The first time a prompt is cached you pay a small premium; every reuse after that is nearly free. For repeated workloads the math is overwhelmingly in your favor.

Output tokens

What the model generates. Almost always the most expensive per token — typically 5x the input rate. On GPT-5.6 Sol: $20.00/1M output versus $4.00/1M input.

This asymmetry drives real design decisions. Verbose chain-of-thought reasoning, long explanations, and rambling agent loops are the most expensive thing you can do with an API. Concise outputs, structured formats, and stopping the model when it has the answer aren't just good UX — they're cost control.

The Workload Formula

With those three prices, any workload reduces to one formula:

Monthly cost = tasks/month × [(fresh_in × P_in) + (cached_in × P_cache) + (out × P_out)]

Where P_in, P_cache, and P_out are the per-token prices from the rate card.

Let's run it with real numbers. Take GPT-5.6 Sol's promo pricing: $4.00/1M input, $0.40/1M cached, $20.00/1M output.

Assumptions:

• A coding agent running 50 tasks/day × 22 days = 1,100 tasks/month
• Per task: 12K fresh input tokens, 48K cached input tokens, 6K output tokens

Per task:

• Fresh input: 12,000 × $4.00/1M = $0.0480
• Cached input: 48,000 × $0.40/1M = $0.0192
• Output: 6,000 × $20.00/1M = $0.1200
• Total per task: $0.1872

Per month: 1,100 × $0.1872 = $205.92

Two things jump out. First, output tokens — only 6K of the 66K total — are 64% of the cost. That's the 5x price asymmetry at work. Second, the 48K cached tokens cost less than half the 12K fresh tokens. Caching is doing enormous work in this bill.

Now change one variable: if that promo pricing reverts to $5/$30 (the pre-promo list price), the same workload costs $290.40/month — a 41% jump with zero change in usage. This is why you model scenarios, not just today's rate card. (For the full breakdown of that deadline, see our GPT-5.6 pricing guide.)

5 Practical Ways to Cut the Bill

These are ordered by typical impact, not difficulty.

1. Maximize prompt caching

This is the highest-leverage move available. If your workload repeats context — and agentic loops almost always do — structure prompts so the stable prefix (system instructions, repo context, few-shot examples) is identical across calls and the variable part comes last. Cache hit rates above 80% are achievable, and at a 90% discount per cached token, that transforms the bill.

In our example workload, cached tokens are already 73% of input volume. Push that higher and the per-task cost drops fast.

2. Use batch APIs for anything that can wait

Most providers offer a batch mode at roughly 50% off — same model, slower turnaround (usually hours). Evals, bulk classification, backfills, nightly jobs: if it doesn't need an answer in seconds, it shouldn't pay the real-time rate. This is the easiest discount in the industry and the least used.

3. Route simple tasks to smaller models

Not every task needs the flagship. Classification, extraction, formatting, simple Q&A — a smaller model at a fraction of the price handles these fine. The pattern that works: a cheap model attempts the task, and only escalates to the expensive one when confidence is low or the task is flagged as hard. On GPT-6.1 Sol at $2/$10, for instance, our example workload drops to $97.68/month — less than half.

The key discipline is measuring: run the small model on a sample of your real tasks and check quality before committing. Don't assume, and don't guess — benchmark.

4. Watch context-window bloat

Input volume is the silent killer. Every file you stuff into context, every full conversation history you resend, every verbose tool result — all billed, every call. Audit what you're actually sending: teams routinely find 30–50% of their input tokens are context nobody reads.

Practical fixes: summarize conversation history instead of resending it raw, retrieve only the relevant files instead of the whole repo, truncate tool outputs to what the model needs. And remember the threshold trap — on some models, crossing a context size (272K input tokens on GPT-5.6 Sol) reprices the entire request at a higher rate. Know your provider's thresholds.

5. Use off-peak / flex tiers where offered

Some providers offer discounted tiers for flexible timing — your request runs when capacity is available, you pay less. If your workload is asynchronous by nature (and much of it is), flex pricing is nearly free money. Check whether your provider offers it and what the discount is; the tradeoff is latency variability, which batch-tolerant work doesn't care about.

A Checklist Before You Commit to a Model

Pricing pages change — November and December 2026 are proof, with two major models repricing within weeks of each other. Before you build on any model:

1. Measure your token mix — fresh vs. cached vs. output, from your actual usage, not guesses.

2. Model at least two price scenarios — today's rate and the plausible next rate.

3. Benchmark cheaper alternatives on your real tasks before you need them.

4. Check the thresholds — context-size pricing cliffs, cache write costs, minimum charges.

5. Build for portability — abstract the model call so a price change is a config edit, not a rewrite.

The developers with the lowest AI bills aren't the ones who found the cheapest model. They're the ones who measured their usage, cached aggressively, batched what could wait, and never let a promo price become a load-bearing assumption.