Your prototype cost eleven rupees to run all week. Then you ship it, and the first invoice is a number you can't explain. The fix is a habit: work out the LLM API cost per 1,000 requests before you launch, using real token counts and current prices.
The short answer: cost per request is the sum of each token type times its price, and cost per 1,000 requests is that times a thousand. Output tokens cost several times more than input. Cached input costs a fraction. Below is the formula, a calculator script I ran, worked examples with prices I read from vendor pages on 2026-10-08, and the tactics that actually move the number. If you want a broader view of how pricing works across vendors, start with AI model pricing in 2026; this post is the arithmetic.
The formula
cost per request = ( fresh_input x input_price
+ cached_input x cached_price
+ output x output_price ) / 1,000,000
cost per 1,000 requests = 1,000 x cost per request
Prices are quoted in dollars per million tokens (MTok). Three things trip people up:
- Output is priced higher. Often 5x the input rate. A request that sends 200 tokens and receives 2,000 is mostly an output bill.
- Hidden tokens are billed. Tool definitions, the system prompt, conversation history and reasoning tokens all count. The Anthropic pricing page also notes that tool use adds a system-prompt overhead per request (286 tokens on the newest models listed that day, more on older ones).
- Tokenizers differ. The same page says Claude 4.7 and later models use a tokenizer that produces roughly 30 percent more tokens for the same text than earlier ones. A price drop can be partly eaten by a token-count rise, so compare cost per task, not price per token. For counting, see token counting and context management.
Prices used here (read 2026-10-08)
These come from vendor pages, fetched on 2026-10-08. They change often, so recheck before you budget.
| Model | Input $/MTok | Cached input $/MTok | Output $/MTok | Source |
|---|---|---|---|---|
| Claude Haiku 5.5 (prompts up to 100k) | 0.10 | 0.01 | 0.50 | Anthropic pricing |
| Claude Sonnet 5.5 | 2.00 | 0.10 | 10.00 | Anthropic pricing |
| Claude Opus 5.5 | 4.00 | 0.20 | 20.00 | Anthropic pricing |
| GPT-6 Luna | 0.10 | 0.01 | 0.50 | OpenAI pricing |
| GPT-6 Sol | 2.00 | 0.20 | 10.00 | OpenAI pricing |
| Gemini 2.5 Flash-Lite | 0.10 | 0.01 | 0.40 | Gemini pricing |
| Gemini 3.5 Flash-Lite | 0.30 | 0.03 | 2.50 | Gemini pricing |
Notes on the sources: OpenAI's main pricing page at openai.com returned an access error when I tried it, so the OpenAI numbers come from the developer docs pricing page instead. Gemini rates are the paid-tier standard rates; the page gave no effective dates for the two Flash-Lite models, and it flags scheduled changes only for some other models. Anthropic's cache read price for Sonnet 5.5 and Opus 5.5 is 0.05x input (not the usual 0.1x), which is why those cached prices look low. All three vendors document a 50 percent discount for their batch APIs.
The calculator script
This is the core of what I ran (Python 3, standard library only). The MODELS dictionary holds the table above; each entry is input, cached read, output, and the batch factor.
MODELS = {
"Claude Haiku 5.5": (0.10, 0.01, 0.50, 0.5),
"Claude Sonnet 5.5": (2.00, 0.10, 10.00, 0.5),
"Claude Opus 5.5": (4.00, 0.20, 20.00, 0.5),
"GPT-6 Luna": (0.10, 0.01, 0.50, 0.5),
"GPT-6 Sol": (2.00, 0.20, 10.00, 0.5),
"Gemini 2.5 Flash-Lite": (0.10, 0.01, 0.40, 0.5),
"Gemini 3.5 Flash-Lite": (0.30, 0.03, 2.50, 0.5),
}
def cost_per_request(model, fresh_in, cached_in, out, batch=False):
pin, pcache, pout, bf = MODELS[model]
usd = (fresh_in * pin + cached_in * pcache + out * pout) / 1e6
return usd * (bf if batch else 1.0)
def per_1000(model, fresh_in, cached_in, out, batch=False):
return 1000 * cost_per_request(model, fresh_in, cached_in, out, batch)
Swap in your own prices and your own average token counts from logged usage fields. The averages matter more than the model name.
Worked examples with real output
Four invented-but-typical workloads, in tokens per request (fresh input, cached input, output):
- A. Classifier: 300 in, 20 out.
- B. RAG answer: 1,800 in, 250 out.
- C. RAG answer with a cached prefix: 1,200 fresh in, 600 cached in, 250 out.
- D. Long summary: 6,000 in, 800 out.
Output from the script, dollars per 1,000 requests (standard, then batch):
workload model $/1k req batch $/1k
A. classifier (300 in, 20 out) Claude Haiku 5.5 0.0400 0.0200
A. classifier (300 in, 20 out) Claude Sonnet 5.5 0.8000 0.4000
A. classifier (300 in, 20 out) GPT-6 Luna 0.0400 0.0200
A. classifier (300 in, 20 out) Gemini 2.5 Flash-Lite 0.0380 0.0190
B. RAG answer (1,800 in, 250 out) Claude Haiku 5.5 0.3050 0.1525
B. RAG answer (1,800 in, 250 out) Claude Sonnet 5.5 6.1000 3.0500
B. RAG answer (1,800 in, 250 out) Claude Opus 5.5 12.2000 6.1000
B. RAG answer (1,800 in, 250 out) GPT-6 Sol 6.1000 3.0500
B. RAG answer (1,800 in, 250 out) Gemini 3.5 Flash-Lite 1.1650 0.5825
C. RAG answer, 600-token prefix cached Claude Haiku 5.5 0.2510 0.1255
C. RAG answer, 600-token prefix cached Claude Sonnet 5.5 4.9600 2.4800
C. RAG answer, 600-token prefix cached GPT-6 Sol 5.0200 2.5100
D. long summary (6,000 in, 800 out) Claude Sonnet 5.5 20.0000 10.0000
D. long summary (6,000 in, 800 out) Claude Opus 5.5 40.0000 20.0000
D. long summary (6,000 in, 800 out) Gemini 3.5 Flash-Lite 3.8000 1.9000
(The full run prints all seven models for each workload; I trimmed rows for space.)
How to read it:
- The classifier is nearly free on a small model. About four cents per 1,000 requests on Haiku 5.5. On Sonnet 5.5 it's $0.80, which is 20x more for a task that rarely needs the bigger model.
- Workload B on Sonnet 5.5 is $6.10 per 1,000 requests. Input is 1,800 x $2 = $0.0036 per request, output 250 x $10 = $0.0025. At 100,000 requests a month, that is $610.
- Opus 5.5 on the same job is $12.20. Exactly double, because its prices are exactly double Sonnet 5.5's. Pay that only if your evals show the quality difference matters.
- Caching moved B from $6.10 to $4.96 on Sonnet 5.5 (about 19 percent), because only 600 of 1,800 input tokens were stable. This excludes the cache write cost on the first request in each window, so treat it as the steady-state figure.
- Batch is a flat half in this table. Caveat: Google's page shows cached-input prices in batch mode that are not always halved, so for cached workloads on Gemini the batch column slightly understates cost. OpenAI's and Anthropic's pages describe batch as 50 percent of standard.
Tactic 1: prompt caching, and when it pays
Anthropic's page states a 5-minute cache write costs 1.25x the base input price and a cache read costs a fraction of it, with the exact multiplier depending on the model. I computed the break-even on Sonnet 5.5 per million tokens of prefix:
cache break-even, Sonnet 5.5, 5-minute write at 1.25x input
prefix used 1x: uncached $2.000 vs cached $2.500 per MTok of prefix
prefix used 2x: uncached $4.000 vs cached $2.600 per MTok of prefix
prefix used 3x: uncached $6.000 vs cached $2.700 per MTok of prefix
prefix used 6x: uncached $12.000 vs cached $3.000 per MTok of prefix
prefix used 21x: uncached $42.000 vs cached $4.500 per MTok of prefix
One use costs 25 percent more with caching; two uses already win; twenty-one uses cost about a tenth. The takeaway: cache a big, stable prefix that you reuse inside the window. Put stable content (instructions, tool definitions, reference documents) first and variable content last, because caching is a prefix match. Confirm it works by reading the cache fields in the response usage; a timestamp in the system prompt silently breaks it. Check each vendor's minimum cacheable length and cache lifetime on its docs before relying on it; I did not verify those for this post. Longer guides: prompt caching for Claude and caching strategies across Anthropic and OpenAI.
Tactic 2: batching
If nobody is waiting, use the batch API. Bulk classification, archive summaries, evaluation runs and synthetic data are the natural fits. The cost is operational: you submit, poll, and match results by request ID. See the Anthropic Batch API guide.
Tactic 3: routing
Send easy requests to a cheap model and hard ones to a stronger one. I computed a blend for workload B, Haiku 5.5 versus Sonnet 5.5:
routing, workload B (1,800 in / 250 out), per 1,000 requests
0% to Haiku 5.5, rest Sonnet 5.5: $6.1000
50% to Haiku 5.5, rest Sonnet 5.5: $3.2025
70% to Haiku 5.5, rest Sonnet 5.5: $2.0435
90% to Haiku 5.5, rest Sonnet 5.5: $0.8845
The arithmetic is only half the story. Routing saves money only if the router sends the right traffic. Measure the quality of the cheap model on a labelled set, per category, and add the router's own cost and error rate to the sum. Start with a rule (short, low-risk, templated requests go small) before building a classifier. Implementation options are in AI model routing with LiteLLM and OpenRouter.
Tactic 4: smaller models, shorter prompts, tighter outputs
- Cap output length with
max_tokensand ask for terse formats. Output is the expensive side. - Cut retrieved context. Every extra retrieved chunk is billed as input on every request. Rerank and keep fewer.
- Control reasoning effort. Reasoning tokens are billed as output on current models, so a high effort setting can multiply the cost of a simple task.
- Test the smaller model first. Run your eval set on the cheapest tier and move up only when it fails. The classifier above is the case where the smallest model is plenty.
- Cache whole answers for repeated questions with a semantic cache. See semantic caching.
- Retries count. If 5 percent of requests retry once, your bill is about 5 percent higher than your calculator says.
Paying in INR: what an API gateway changes
Many Indian developers hit a practical wall before any of the above: the vendor billing page wants an international card, and domestic cards get declined. An API gateway that accepts UPI and bills in rupees solves that, and costs you a markup.
Some links on this page are affiliate links; they cost you nothing and I only link tools I'd mention anyway. One option is AICredits, an OpenAI-compatible gateway with INR top-ups. Our own AICredits review states its pricing as live forex plus a 5 percent forex buffer plus a 5 percent platform fee, which that review puts at roughly a 10 to 11 percent markup over direct USD pricing (I used 1.10 below). I haven't re-verified AICredits' rates for this post, so check its dashboard. Applying that markup to workload B on Sonnet 5.5, at a rate of Rs 95.7 per USD (the rate quoted in that review, not a live rate), the script printed:
workload B on Sonnet 5.5, markup x1.0: Rs 583.77 per 1,000 requests at Rs 95.7/USD
workload B on Sonnet 5.5, markup x1.10: Rs 642.15 per 1,000 requests at Rs 95.7/USD
So the gateway adds about Rs 58 per 1,000 requests on that workload. Downsides to weigh: the markup, credits that expire (the review says after one year), and an extra party between you and the model vendor, which matters for data handling and outage blame. Alternatives: a direct vendor account if you have a card that works, a cloud marketplace route if your company has one, or another gateway; the site compares one in AICredits vs OpenRouter for India. If you're a company with a working international payment method and meaningful volume, the markup probably isn't worth paying. Also check how GST and invoicing apply to your situation with an accountant. I haven't covered that here.
A budgeting checklist
- Log
usage(input, cached, output) from real responses for a day. - Compute average tokens per request by type; use the script above with your prices.
- Multiply by expected monthly requests, then add 10 to 20 percent for retries and growth. That margin is my rule of thumb, not a measured figure.
- Set a spend cap and an alert at 50 percent of it.
- Re-run the numbers whenever you change the model, the prompt or the retrieval depth.
All prices and rates above were read on 2026-10-08 and re-checked on 2026-10-09. Treat them as a snapshot, and rerun the script with fresh numbers before you commit to a budget.
