Guide

GPT-4o mini vs Claude Haiku: cost per 1K tokens worksheet

costpricingcomparison

See also / canonical cluster. Pillar for token & cost estimation: How to estimate LLM token costs before you ship. Interactive: token & cost estimator. This page stays on a different intent — see the intro.

Intent here: a two-SKU cost-per-1K worksheet (GPT-4o mini vs Claude Haiku class) — not the general estimation method. Use this when you are choosing between small/fast models; use the estimation pillar for feature-level monthly forecasts and the token estimator to re-run arithmetic.

Start from your invoice units

Vendors publish rates as USD per 1M tokens (input and output separately). Convert to per 1K for spreadsheet readability:

  • cost_per_1k_input = input_price_per_1M / 1000
  • cost_per_1k_output = output_price_per_1M / 1000

Always paste current list prices from the vendor dashboard or invoice into your sheet. Do not hard-code blog numbers into production budgets — rates move.

Example skeleton (replace with your live rates):

Model classIn $/1MOut $/1MIn $/1KOut $/1K
Small A (e.g. mini-class)
Small B (e.g. Haiku-class)

Cost per call, not cost per 1K alone

Per-1K is a unit price. Features burn asymmetric input vs output:

  1. Measure p50 / p90 input tokens (system + user + tools + RAG).
  2. Cap or measure typical output tokens (max_tokens is not the same as average completion length).
  3. Compute:

call_cost = (in_tokens/1000)*in_$1k + (out_tokens/1000)*out_$1k

  1. Multiply by calls/month × (1 + retry_rate) × agent_rounds.

A model that is cheaper per 1K input can still lose if your workload is output-heavy, or if it needs longer completions to reach the same quality bar.

Use the token & cost estimator with editable rates to stress-test both rows side by side.

What “same quality” means in a worksheet

Do not write “Model A wins” without a task definition. For cost decisions, define:

  • Acceptable failure modes (refuse vs invent)
  • Latency budget (p95)
  • Human review rate (review time is real money)
  • Schema compliance rate on structured outputs

If Model B needs 30% more output tokens or a second repair call to hit your schema, fold that into the sheet as an effective multiplier — not as a vibe score.

Common traps when comparing mini vs Haiku-class

  • Ignoring cached / batch / reserved pricing — list price ≠ what finance pays.
  • Mixing tokenizer families — “1K tokens” is not portable across vendors; see local vs vendor tokenizer differences.
  • Forgetting tool/agent overhead — tool schemas and multi-step transcripts dominate; see agent tool-calling token overhead.
  • Using toy prompts — size estimates on production p90, not a 40-token demo.
  • Treating blog prices as contracts — your sheet should cite the date and source URL of the rate table.

A one-page comparison worksheet

Columns that usually matter:

  1. Rate date / source
  2. Input $/1K, output $/1K
  3. p50 / p90 input tokens (measured)
  4. Avg output tokens (measured)
  5. Retry % and agent rounds
  6. Effective $/1K blended = total_monthly_cost / (total_tokens/1000)
  7. Non-token costs: eval time, guardrail calls, logging storage
  8. Exit criteria: when to re-evaluate the cheaper model

Keep this sheet next to the feature’s RFC. When a vendor changes prices, re-run rows 1–6 before rewriting prompts.

Decision rule of thumb

  • Prefer the cheaper effective blended $/1K that still meets schema + latency + review-rate gates.
  • If both meet gates, pick the one with clearer rate-limit / region / data fit — see also your comparison checklist tool.
  • Revisit monthly for high-volume features; small rate deltas compound.

Practical next steps

  1. Copy two rate rows into the token estimator.
  2. Paste three real production prompts (or anonymized shapes).
  3. Record p90 input and average output.
  4. Apply retry and round multipliers from your rate limit backoff playbook.
  5. Write the blended number into the feature’s unit-economics doc — see LLM feature unit economics for SaaS.

Price per 1K tokens is a starting unit. Effective cost per successful user outcome is the number that should survive a budget review.

Sample walkthrough (replace rates)

Suppose (illustrative placeholders only):

  • Model A: $0.15 / 1M in, $0.60 / 1M out
  • Model B: $0.25 / 1M in, $1.25 / 1M out
  • p90 input 2,000 tokens; avg output 400 tokens; 1M calls/month; 8% retries; 1.0 agent rounds

Per call (A): (2e3/1e6)*0.15 + (400/1e6)*0.60 = 0.0003 + 0.00024 = $0.00054
Monthly with retries: 1e6 * 1.08 * 0.00054 ≈ $583

Per call (B): (2e3/1e6)*0.25 + (400/1e6)*1.25 = 0.0005 + 0.0005 = $0.001
Monthly with retries: 1e6 * 1.08 * 0.001 ≈ $1,080

If Model A needs a 20% repair-call rate to match B’s schema success, add that multiplier before declaring A the winner. Re-run with your real rates in the token estimator.

Sharing the worksheet with finance

Attach: rate date, traffic assumptions, retry policy link, and the definition of “successful call.” Finance can challenge assumptions; they should not have to reverse-engineer a screenshot.

Tool links point to free client-side utilities on this site. Third-party product links may be affiliates — affiliate disclosure.