← Blog  ·  June 30, 2026

LLM API Pricing Explained: Tokens, Context Caching, and How to Cut Costs

The first LLM API bill surprises almost everyone. You are not billed per request, per user, or per month — you are billed per token, in both directions, at rates that vary by model, direction, and whether the tokens were cached. Once you can read a pricing table fluently, most cost optimizations become obvious.

Tokens: the billing unit

Models process text as tokens — fragments averaging about 4 characters of English. “Hello, world!” is 4 tokens; a 1,000-word article is roughly 1,300 tokens. Every API call is billed on:

• Input tokens — everything you send: system prompt, conversation history, retrieved documents, the user’s question.
• Output tokens — everything the model generates.

Prices are quoted per million tokens (MTok). A model at $3/MTok input and $15/MTok output charges you $0.003 for a 1,000-token prompt and $0.015 for a 1,000-token reply.

Why your bill is dominated by three things

1. Conversation history compounds. Chat APIs are stateless: each turn resends the entire conversation. By turn 20, you are paying input price for 19 turns of history — every single message. Long-running chats have quadratic token growth unless you truncate or summarize.

2. Output is the expensive direction. Output rates typically run 3–5x input rates. A verbose model that pads answers with preamble is charging you for the padding. Setting max_tokens and prompting for concision are direct cost levers.

3. Model choice is a 100x lever. Flagship models can cost two orders of magnitude more than small fast models. The most effective optimization in production systems is routing: send easy tasks (classification, extraction, reformatting) to a cheap model and reserve the frontier model for the hard reasoning that actually needs it.

Context caching: the discount most teams ignore

If your requests share a long, stable prefix — a 2,000-token system prompt, a product catalog, a set of few-shot examples — context caching lets the provider skip reprocessing it and bill those tokens at a steep discount, commonly 50–90% off.

To benefit, structure prompts with the stable part first, variable part last:

[ system prompt + few-shot examples ]   ← identical every call → cached
[ user's question ]                      ← changes every call → full price

For a support bot resending a 3,000-token system prompt on every message, caching alone can cut input spend by more than half.

A worked example

Say a support assistant handles 10,000 conversations/month, averaging 8 turns, a 2,000-token cached system prompt, 300 tokens of user input, and 250 tokens of output per turn, on a model priced $3/$15 per MTok with 90% cache discount:

Without caching, the same workload costs roughly $1,140 — and with unbounded history growth, more. The pattern generalizes: cache the stable, trim the history, cap the output, route the easy stuff down-market.

Comparing prices across providers

Cross-provider price shopping is tedious when every provider has its own account and billing. A unified gateway like MEYATU API lists per-model rates side by side and bills everything against one prepaid balance — so testing whether a cheaper model handles your workload is an afternoon experiment, not a procurement exercise. Balance on MEYATU API does not expire, and a real-time dashboard breaks spend down per model and per sub-key, which is how you catch a runaway prompt before it becomes a line item.

Checklist to cut your LLM bill

1. Log token counts per request — you cannot optimize what you don’t measure.
2. Cap max_tokens and prompt for concise output.
3. Truncate or summarize conversation history beyond ~10 turns.
4. Put stable prompt content first and enable context caching.
5. Route simple tasks to smaller models; measure quality on your own data.
6. Re-benchmark quarterly — prices and models change fast.

MEYATU API is operated by MEYATU LLC, a Wyoming-registered US company. See supported models and payment options on the MEYATU API page.