How to Read an LLM Pricing Table Without Fooling Yourself

Start with three fields

LLM pricing tables look precise because they are packed with numbers. That precision can be misleading. For most real-world comparisons, begin with only three fields:

1. Input price ($/M tokens). What you pay for the text, instructions, documents, and conversation history sent to the model. “M” means one million tokens.
2. Output price ($/M tokens). What you pay for the model’s generated answer. This is usually the more expensive line.
3. Context window. The maximum amount of text the model can consider in one request, normally measured in tokens. It is a capacity limit, not a direct fee.

Those three fields answer the practical questions: Can the model fit the job? What does the request cost to send? What does the answer cost to generate?

The output-is-the-real-cost rule

For many workflows, output is the real cost. Input may include a long reusable prompt, but output grows with the work you ask the model to do. A review, report, product description, or code patch can generate thousands of tokens. If output is priced several times higher than input, an apparently cheap model can become expensive when it writes at length.

This is why the ABS matrix should be read as a workflow comparison, not a race to find the lowest input number. Ask how much the model will write, how often it will write it, and whether you can cap that output without damaging quality.

Three fields that can mislead

Cached input

Cached-input pricing can be useful when a provider discounts repeated prompt prefixes. But it is not the default price for every request. Caching may depend on exact token reuse, cache duration, minimum lengths, or provider-specific routing. Treat it as a bonus until your workload reliably produces cache hits. Compare ordinary input pricing first.

The trap: a cached-input rate at 1/10 the standard input rate tempts you to assume the discounted rate applies to all calls. Most workloads hit the cache on 30-70% of calls, not 100%. Your effective input cost is a weighted average of cached and standard rates, not the cache rate itself.

Batch pricing

Batch prices may be lower because requests run asynchronously and are not intended for interactive use. A batch discount is relevant for overnight classification or bulk enrichment, not necessarily for a user waiting for an answer. Do not use batch pricing to estimate a live assistant, support reply, or editorial workflow unless you will actually submit batches.

Most batch APIs have a 24-hour turnaround SLA. If your task needs an answer in under 5 seconds, batch is the wrong tool. If your task accepts a day of latency, batch is 50% off and worth it.

Free tier after month

A free allowance can make the first month look like it costs nothing. It does not tell you the steady-state cost after the allowance is consumed. Model the paid month, then subtract any genuinely recurring credit. A temporary promotion, trial balance, or “free tier after month” note belongs in a separate column called cash-flow timing, not in the core model comparison.

The most common gotcha: a provider offers 1M free tokens the first month. You ship a workload that uses 2M tokens in month 1 (free) and 2M in month 2 (full price). The dashboard shows “$0 this month” and you assume the model is free. The month-2 invoice tells a different story.

The price-with-no-context trap

A line item like “$0.0001 / 1k input tokens” is sometimes quoted without the context window or any reference to what counts as a token. Tokenization varies. A 1,500-word English review at 1.3 tokens/word is 1,950 tokens; at 1.5 tokens/word (more conservative) it’s 2,250 tokens — a 15% difference in cost. Build your budget with a 1.5x multiplier on the headline token counts to leave room for tokenizer variance.

Worked example: 30 reviews a day

Suppose you produce 30 reviews per day, each 1,500 words long. A rough planning conversion is about 1.3 tokens per English word, so each finished review is approximately 1,950 output tokens. The daily output is:

30 × 1,950 = 58,500 output tokens

Over a 30-day month:

58,500 × 30 = 1,755,000 output tokens, or 1.755 million output tokens.

If a model charges $5 per million output tokens, the monthly generation cost is approximately:

1.755 × $5 = $8.78.

Now add input. If each review sends 2,000 tokens of product notes and instructions, that is 60,000 input tokens per day, or 1.8 million input tokens per month. At $1 per million input tokens, input adds only $1.80, making the estimated total $10.58 per month.

The exact token count varies, but the lesson is stable: output dominates this workload. A table showing input at $0.10/M may look impressive; it barely changes the bill when output is $5/M and the model writes 1.755M tokens.

A better comparison habit

Read the matrix in this order: context window, output price, input price, then discounts. Confirm that the context window fits your largest prompt plus requested answer. Estimate monthly output from your actual workflow. Add input. Only then consider cached or batch rates—and label them as conditional.

Pricing tables are useful when they help you predict a bill. They are dangerous when a tiny promotional number becomes the headline. For most writing-heavy jobs, start with the answer the model will produce. That is where the budget goes.

A 60-second price check

Before you commit to a model, run this calculation:

1. Estimate output tokens per task at 1.5 tokens/word for English prose, 2.0 for code or dense math, 1.0 for casual chat.
2. Estimate input tokens per task at 1.5 tokens/word for the prompt (system + history + user).
3. Multiply by your daily volume for both numbers.
4. Look up the input/output rates per million tokens on the matrix.
5. Calculate output_tokens × output_rate + input_tokens × input_rate and divide by 1,000,000.

For the 30-reviews/day case above, this is roughly 5 lines of arithmetic and 60 seconds of work. Most “why is my bill so high” surprises come from skipping step 1 — assuming the model reads 500 tokens when it actually reads 5,000, or assumes it writes 200 tokens when it actually writes 2,000.