GPT-5.6 Luna vs Claude Haiku 4.5: cost per 1K tokens worksheet

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-5.6 Luna vs Claude Haiku 4.5) — 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.

GPT-4o mini / GPT-4o are legacy SKUs. Do not treat them as the current OpenAI default when you plan cost.

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.

Snapshot used on this page (as of 2026-09-16 — verify vendor pages):

Model	ID	In $/1M	Out $/1M	In $/1K	Out $/1K
GPT-5.6 Luna	gpt-5.6-luna	0.20	1.20	0.00020	0.00120
Claude Haiku 4.5	claude-haiku-4-5	1.00	5.00	0.00100	0.00500

Sources: OpenAI Models, Anthropic models. Re-copy from those pages (or your invoice) before you present numbers to finance.

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

4. 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. The estimator is an approximate client-side count (chars÷N, not tiktoken); rates are editable.

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 Haiku 4.5 (or Luna) 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 Luna vs Haiku 4.5

• 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.
• Planning against GPT-4o mini — that SKU is legacy; current small/fast OpenAI list is GPT-5.6 Luna.

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 (rates as of 2026-09-16 — verify vendor pages)

Worked example using the snapshot above (replace with your live rates):

• Luna: $0.20 / 1M in, $1.20 / 1M out
• Haiku 4.5: $1.00 / 1M in, $5.00 / 1M out
• p90 input 2,000 tokens; avg output 400 tokens; 1M calls/month; 8% retries; 1.0 agent rounds

Per call (Luna): (2e3/1e6)*0.20 + (400/1e6)*1.20 = 0.0004 + 0.00048 = $0.00088
Monthly with retries: 1e6 * 1.08 * 0.00088 ≈ $950

Per call (Haiku 4.5): (2e3/1e6)*1.00 + (400/1e6)*5.00 = 0.002 + 0.002 = $0.004
Monthly with retries: 1e6 * 1.08 * 0.004 ≈ $4,320

If Luna needs a 20% repair-call rate to match Haiku 4.5’s schema success, multiply Luna by 1.20 before declaring a winner (≈ $1,140 vs $4,320 in this toy shape). Quality, latency, and review time can still flip the decision. Re-run with your real rates in the token estimator.

Sharing the worksheet with finance

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