OpenAI API token-based pricing pattern — Hovvi

What happened

Price the measurable resource that drives service cost, then expose cheaper processing modes separately. Make the billable unit traceable to the workload that creates cost.

Evidence

Observed facts

• The API pricing page meters text models separately for input, cached input and output tokens per one million tokens.
• The page exposes Standard and Batch processing modes, with Batch presented as a lower-cost option rather than a separate product subscription.

Editorial inference

• Hovvi should expose its own cost-bearing retrieval unit even if customers ultimately buy a simpler allowance.

Evidence views

1. Pricing overview
2. Meter definition
3. Usage estimate
4. Version note

Founder takeaway

Expose the cost-bearing unit, then simplify how customers purchase it.

Use when

• Workload cost varies materially with input or output volume
• Users can inspect or estimate the metered unit

Avoid when

• Users cannot predict the unit before committing
• A token meter would hide the outcome users value

Next implementation step

Explain an API meter before a founder commits usage.

Acceptance criteria

• A founder can name the billable unit
• A rate example includes its observation date
• A cheaper mode does not look like an unrelated plan

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.

• 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.

Version history

Current snapshot: snap_openai_pricing_2026_08_25 — Retained as the second product-family seed; a complete OpenAI product hub and visual flow have not yet been captured.

Use with an Agent

Example read-only MCP query: