OpenAI API token-based pricing pattern — Hovvi

What happened

Break expected task cost into model-specific input, cached-input and output usage, make processing-mode trade-offs explicit, then reconcile the estimate to observable usage dimensions. Make a model workload estimable before launch and reconcilable to observable usage after launch.

Evidence

Observed facts

• OpenAI's current model comparison prices text models per one million tokens and separates uncached input, cached input and output rates.
• On 2026-08-28, the comparison listed GPT-5.6 Sol at $4.00 input, $0.40 cached input and $20.00 output per one million tokens.
• On 2026-08-28, the comparison listed GPT-5.6 Terra at $2.00 input, $0.20 cached input and $12.00 output per one million tokens.
• On 2026-08-28, the comparison listed GPT-5.6 Luna at $0.20 input, $0.02 cached input and $1.20 output per one million tokens.
• OpenAI's token guidance says total cost depends on model, token category and the tokens a representative task actually consumes; a lower price per million tokens does not necessarily produce a lower task cost.
• OpenAI documents the Batch API as asynchronous processing within a 24-hour window at a 50% discount versus synchronous APIs; batch results are returned through output files and streaming is unavailable.
• The public Usage API reports uncached input, cached input and output token categories and can attribute usage by model, project, user, API key, batch state and service tier.
• OpenAI states that some API capabilities use billing units other than text tokens and that tool-specific models can add per-tool-call charges, so a text-token estimate is not a complete invoice model for every workload.

Editorial inference

• A usage-based AI product is easier to prototype when its estimate combines workload units with an explicit processing trade-off and a later reconciliation path instead of presenting a single headline rate.

Evidence views

1. Model and token-rate snapshot
2. Representative workload estimate
3. Processing-mode trade-off
4. Actual usage reconciliation
5. Version note

Founder takeaway

Estimate the model workload, disclose the delivery trade-off, then reconcile actual usage instead of relying on one headline rate.

Use when

• Workload cost varies materially with model, context reuse or generated output
• Users can inspect or estimate token categories before committing
• An asynchronous delivery path can trade time for lower price
• Usage records can be attributed to a model and bounded project or key

Avoid when

• Users cannot estimate a representative workload before committing
• A token meter would hide the outcome users actually buy
• Non-token tools or modalities dominate the invoice
• The interface presents a dated rate without its observation time

Next implementation step

Estimate one representative API workload before launch and reconcile the actual usage afterward.

Acceptance criteria

• A builder can identify the selected model and every token category in the estimate
• The estimate calculates uncached input, cached input and output separately
• Every rate example includes its source and 2026-08-28 observation date
• Batch visibly states the 50% discount, asynchronous 24-hour window and no-streaming boundary
• The product does not claim that the lowest per-token model yields the lowest completed-task cost
• Actual usage can be reconciled by model, project or API key and execution path
• Unsupported tool or modality charges remain declared gaps rather than inferred values

Related cases

• Different usage meter: Cloudflare Workers pricing: free quota, overage and CPU limits — Hovvi

  Both charge for infrastructure consumption but expose different counted units and cost controls.

• Funding boundary versus usage meter: Anthropic API prepaid credits and billing boundary — Hovvi

  Anthropic explains when funds must be committed and what happens at zero; OpenAI isolates the token units that make variable model cost legible.

• Public proof to usage meter: OpenAI API Platform public evaluation journey — Hovvi

  The public evaluation journey shows where model-meter context appears, while the token-meter case isolates the counted unit and processing-mode decision.

• AI allowance by seat versus by token: Figma pricing seat packaging pattern — Hovvi

  Both surfaces bundle an AI allowance into the entry decision, but Figma allocates credits per seat and plan tier while OpenAI meters tokens per request with hard purchase limits.

• Funding controls versus billable unit: OpenAI API prepaid balance and spend controls — Hovvi

  The token-meter reference explains what creates variable model cost, while the prepaid-balance reference explains how that cost is funded, delayed in settlement and bounded by separate spending and throughput controls.

Version history

Current snapshot: snap_openai_token_meter_2026_08_28 — Replaced a two-fact seed with current source-bound token categories, a dated representative rate snapshot, Batch delivery trade-offs and Usage API attribution. Authenticated usage and billing state remain excluded.

Use with an Agent

Example read-only MCP query: