How to Read Pricing Pages

Phase 4 · Document 04 · Model Catalogs and Trend Reading Prev: 03 — How to Read Benchmarks · Next: 05 — How to Build a Model Watchlist

Table of Contents

1. Why This Matters
2. Core Concept
3. Mental Model
4. Hitchhiker's Guide
5. Warmup Readings
6. Deep Readings and External References
7. Key Terms
8. Important Facts
9. Observations from Real Systems
10. Common Misconceptions
11. Engineering Decision Framework
12. Hands-On Lab
13. Verification Questions
14. Takeaways
15. Artifact Checklist

1. Why This Matters

The pricing page is where your product's unit economics are decided — and it's full of small print that turns a "cheap" model expensive: output priced 2–5× input, reasoning tokens billed invisibly, image tokens, rate limits that throttle you, and batch discounts you're not using. The catalog (00) gives an approximate price; the provider's own pricing page is ground truth and changes often. Reading it correctly — and turning it into a real cost-per-request estimate — is the difference between a profitable feature and a margin-negative one. This is the applied companion to Phase 1.08.

2. Core Concept

Plain-English primer (the line items, from zero)

LLM pricing is per token (≈ ¾ word), quoted per 1,000,000 tokens, and input and output are billed separately. Here's every line item you'll meet:

• Input price — cost per 1M prompt tokens (everything you send: system prompt + history + user message + retrieved docs).
• Output price — cost per 1M generated tokens. Usually 2–5× the input price (generation is the expensive phase — Phase 2.07).
• Cached input price — a big discount (often 75–90% off) for repeated prompt prefixes (e.g. a fixed system prompt) when prompt caching applies (Phase 2.06).
• Reasoning/"thinking" tokens — for reasoning models, the hidden thinking is billed (usually at output rates) even though you don't see it (Phase 2.09).
• Multimodal tokens — images/audio/video are converted to a token-equivalent and priced (often a flat per-image cost or per-tile); a single image can be hundreds–thousands of tokens.
• Batch pricing — async/batch endpoints often cost ~50% less for non-urgent work.
• Rate limits / quotas — RPM (requests/min), TPM (tokens/min), RPD (requests/day), tier-based; not a price, but they cap throughput and cause 429 errors.
• Billing model — pay-as-you-go (default), committed-use discounts, or subscription/enterprise tiers.

The one calculation that decides profitability

request_cost = input_tokens/1e6 × input_price
             + output_tokens/1e6 × output_price
             + reasoning_tokens/1e6 × output_price          (reasoning models)
             − cached_tokens/1e6 × (input_price − cached_price)   (prompt caching savings)
monthly_cost = request_cost × requests/day × 30
gross_margin = (price_to_customer − cost_to_serve) / price_to_customer

Worked example (support bot, 10,000 calls/day, 500 in / 150 out tokens, model at $0.15/$0.60 per 1M):

input : 10,000 × 500/1e6 × $0.15 = $0.75/day
output: 10,000 × 150/1e6 × $0.60 = $0.90/day
total ≈ $1.65/day ≈ $50/month

With a 300-token system prompt cached at 75% off:
cached input : 10,000 × 300/1e6 × ($0.15×0.25) = $0.11/day
fresh input  : 10,000 × 200/1e6 × $0.15        = $0.30/day
output       : $0.90/day
total ≈ $1.31/day ≈ $39/month   → ~22% saved by caching the prefix

Why the headline price lies

A model's input price is the least of your cost story. What actually moves the bill: output volume (cap max_tokens, prompt for brevity), reasoning tokens (route, don't blanket-enable), token efficiency (a "cheaper" model that needs more tokens/retries can cost more — compare cost per resolved task), and caching (often the biggest lever). Always model your token mix, not the per-1M sticker.

3. Mental Model

PRICE PAGE = the line items behind your unit economics:
  input $ · OUTPUT $ (2–5× input) · CACHED $ (−75–90% on repeats) ·
  reasoning tokens (billed, hidden) · image/audio tokens · batch (−~50%) · rate limits (429s)

cost/request = in×in$ + out×out$ (+reasoning) − cache_savings
margin = (price − cost_to_serve)/price

Headline input price ≈ the SMALLEST part of the story.
Biggest levers: OUTPUT volume · caching · routing · token efficiency (cost per RESOLVED task).

4. Hitchhiker's Guide

What to read first: input and output price (and the ratio), cached-input price, whether reasoning tokens are billed, and the rate limits.

What to ignore at first: enterprise/committed-use tiers until volume justifies them.

What misleads beginners:

• Quoting "the price" as the input number (output dominates many workloads).
• Forgetting reasoning tokens are billed and hidden.
• Ignoring caching (leaving 75–90% on repeated prefixes unclaimed).
• Comparing models by per-1M price instead of cost per resolved task.
• Treating rate limits as irrelevant until production 429s hit.

How experts reason: they build a cost-per-request model from their real token mix, apply caching/routing, compute gross margin, and re-verify on the provider page (catalog prices drift). They size against rate limits and plan fallback for 429s.

What matters in production: verified pricing, a margin model, caching for stable prefixes, output caps, batch endpoints for async work, and rate-limit headroom + fallback.

How to verify: reconcile your computed cost against the provider's actual invoice / usage dashboard for a sample of real traffic.

Questions to ask: Input/output/cached prices? Reasoning tokens billed, at what rate? Image/audio pricing? Batch discount? RPM/TPM/RPD and how to raise them? Committed-use discounts?

What silently gets expensive: uncapped/large outputs; blanket reasoning; non-cached repeated system prompts; non-English/JSON token inflation; retries doubling cost; surprise multimodal token charges.

5. Warmup Readings

6. Deep Readings and External References

7. Key Terms

8. Important Facts

• Pricing is per token, input/output billed separately, quoted per 1M tokens.
• Output is typically 2–5× input — it usually dominates the bill.
• Cached input is 75–90% cheaper — caching stable prefixes is often the biggest lever.
• Reasoning tokens are billed (output rates) and hidden — budget them.
• Images/audio cost tokens — a single image can be hundreds–thousands of tokens.
• Batch endpoints are often ~50% cheaper for async work.
• Rate limits (RPM/TPM/RPD) cause 429s — plan headroom + fallback.
• Catalog prices drift — verify on the provider page; compare cost per resolved task.

9. Observations from Real Systems

• OpenAI/Anthropic/Google all price input/output separately, offer prompt caching discounts, and publish batch pricing — the same structure with different numbers.
• Usage dashboards / usage objects report input, output, cached, and reasoning tokens — your ground truth to reconcile estimates against (Phase 1.00 lab).
• OpenRouter shows per-provider prices for the same model — the cheapest host can differ (Phase 8).
• Reasoning-model bill shock is common when teams enable thinking globally and pay for hidden tokens (Phase 2.09).
• Caching-driven margin jumps are routinely 20–40% for chatbots with fixed system prompts.

10. Common Misconceptions

11. Engineering Decision Framework

Turn a pricing page into a decision:
  1. EXTRACT: input, output, cached, reasoning, image, batch prices + RPM/TPM/RPD.
  2. MODEL: cost/request from MY token mix → monthly → gross margin.
  3. APPLY LEVERS: cache stable prefixes · cap max_tokens · route easy→cheap (Phase 1.08) · batch async work.
  4. COMPARE: cost per RESOLVED task across candidates (not per-1M sticker).
  5. SIZE LIMITS: RPM/TPM ≥ peak load? else raise tier + add fallback (Phase 8).
  6. VERIFY: reconcile estimate vs the actual usage dashboard on sample traffic.

12. Hands-On Lab

Goal

Build a pricing-page-to-margin calculator: input the line items + your token mix, output cost/request, monthly cost, caching savings, and gross margin — then reconcile against a real usage number.

Prerequisites

• Python 3.10+; one provider pricing page; (optional) an API key to generate a real usage sample.

Setup

pip install openai   # optional, for reconciliation

Steps

def request_cost(in_tok, out_tok, in_p, out_p, cached_tok=0, cached_p=None, reason_tok=0):
    cached_p = in_p if cached_p is None else cached_p
    fresh_in = max(in_tok - cached_tok, 0)
    return (fresh_in/1e6*in_p + cached_tok/1e6*cached_p
            + out_tok/1e6*out_p + reason_tok/1e6*out_p)

# From the pricing page (example numbers — replace with the real ones you read):
IN_P, OUT_P, CACHED_P = 0.15, 0.60, 0.0375   # $/1M (cached = 25% of input here)

calls_day, in_tok, out_tok, sys_prompt = 10_000, 500, 150, 300
base   = request_cost(in_tok, out_tok, IN_P, OUT_P) * calls_day
cached = request_cost(in_tok, out_tok, IN_P, OUT_P, cached_tok=sys_prompt, cached_p=CACHED_P) * calls_day
print(f"daily base ${base:.2f}  | with caching ${cached:.2f}  | saved {100*(1-cached/base):.0f}%")
print(f"monthly with caching ≈ ${cached*30:,.0f}")

price_to_customer = 0.01   # per request you charge
margin = (price_to_customer - cached/calls_day) / price_to_customer
print(f"gross margin/request: {margin*100:.0f}%")

Expected output

• Daily/monthly cost, the caching savings %, and a gross-margin figure — your unit economics on one screen.

Debugging tips

• Margin negative? Output or reasoning tokens likely dominate — cap/route them.
• Estimate ≠ invoice? You probably omitted reasoning tokens or mis-set the cached fraction — reconcile against the usage object.

Extension task

Add a reasoning scenario (reason_tok=1500) and a batch scenario (prices × 0.5) and compare margins.

Production extension

Pull live numbers from the Phase 1.00 logging wrapper's usage data to auto-reconcile predicted vs actual cost, and alert on drift — the seed of a cost dashboard (Phase 8).

What to measure

Cost/request, monthly cost, caching savings %, gross margin; predicted-vs-actual reconciliation error.

Deliverables

• A pricing→margin calculator.
• A caching/reasoning/batch scenario comparison.
• A reconciliation note (estimate vs real usage).

13. Verification Questions

Basic

1. Why are input and output priced separately, and which usually dominates?
2. What are reasoning tokens and how are they billed?
3. What does cached-input pricing save, and when does it apply?

Applied 4. Compute monthly cost: 20,000 calls/day, 800 in / 400 out tokens, $2.50/$10.00 per 1M. Then apply a 400-token cached prefix at 10% of input. 5. Why can a "cheaper" model end up costing more?

Debugging 6. Your bill is 3× the estimate. List three things to check. 7. You hit 429s at peak. What pricing-page facts and mitigations apply?

System design 8. Design a cost model + margin guardrail for a feature mixing simple and reasoning-heavy requests.

Startup / product 9. Walk an investor through how your gross margin improves at scale via caching, routing, and batch — with numbers.

14. Takeaways

1. Pricing is per token, input/output separate; output is 2–5× input and usually dominates.
2. Caching (75–90% off repeats) is often the biggest margin lever.
3. Reasoning and multimodal tokens are real, sometimes hidden, costs — budget them.
4. Compare cost per resolved task, not the per-1M sticker.
5. Rate limits cause 429s — size headroom and add fallback.
6. Verify on the provider page and reconcile against the usage dashboard — catalog prices drift.

15. Artifact Checklist

• Code: pricing→cost/margin calculator.
• Scenario comparison: base vs caching vs reasoning vs batch.
• Reconciliation note: predicted vs actual usage cost.
• Rate-limit plan: headroom + fallback for peak load.
• Margin guardrail: target margin + the levers to hold it.
• Notes: the cost formula and "headline price lies" levers.

Next: 05 — How to Build a Model Watchlist