How AI API pricing works

AI API pricing describes the billable work performed by a selected model and service. Keep the request categories, processing mode and qualifying conditions separate before calculating a total.

Definition with a live example

A useful price comparison identifies both the unit and the operation. Ordinary input, generated output, cached input, image generation and a hosted search operation can represent different work. A low amount without its unit and condition is not a complete price. Begin with the source row that applies to the exact model and endpoint.

The OpenAI API pricing reference separates model usage and additional service categories. Official documentation.

Read the live table as a set of conditions, not a universal price attached to a provider name. The model identifier determines which row is relevant, while its request mode and enabled features determine which categories apply. Preserve those choices in application configuration and in the estimate record.

Input and output should stay separate because the application controls them differently. Input comes from the instructions, material and state it sends. Output follows the required response contract and actual generation. A document-heavy extractor and a patch-generating assistant can have very different cost profiles even when both use a text model.

A worked estimate should contain the underlying task, assumed or measured usage, applicable rates and result scope. If a category is unsupported or unknown, keep it visible as an unresolved item. An exact-looking total can still be incomplete when a hosted feature was omitted.

How it affects cost / limits / results

First describe an accepted task. If the model’s first response needs another call, count both calls in the workload. If a pipeline extracts sections and then synthesizes them, count the extraction and synthesis stages. This prevents an isolated demonstration price from masquerading as the cost of a completed product action.

Use the AI API cost calculator for supported categories and retain an ordinary and a demanding scenario. Keep the response requirement fixed when comparing models, then replace assumptions with returned usage from representative accepted tasks.

Caching changes the category of eligible reused input according to the provider’s rules. It does not make every repeated string free or guarantee that the application will achieve its planned hit share. Keep an uncached baseline, inspect actual cache usage and consider initialization or expiration where the feature requires them.

Batch processing changes the workflow. A delayed job with submission and result retrieval can be appropriate for offline work while failing an interactive requirement. Use the batch rate only when the application actually uses the documented path and eligible model. Include result reconciliation and failed rows in the operating plan.

Account credits and offers change how charges are covered, while spending controls change when work is allowed to continue. Neither should erase the underlying paid workload estimate. Keep a paid fallback scenario so the application has an intentional plan when an offer ends.

Compare cost per accepted result when possible. A smaller model can be a good choice for a narrow task, but only if it passes the relevant fixtures. A cheaper call that often requires manual repair may not improve the product. Record the extra work instead of changing the acceptance standard to justify the price.

Provider differences

Anthropic pricing distinguishes cache-related categories and processing modes. Use the Claude pricing source with the actual request structure.

Gemini pricing lists model and feature conditions in its official table. Inspect the relevant interface when applying caching or batch assumptions.

Alibaba Model Studio pricing includes model-specific context and deployment conditions. Preserve those qualifiers from the inference pricing reference.

These differences should remain in the comparison data. A normalization into a common token unit is useful only for compatible categories. Image, time, request and character units still need explicit labels; they cannot be treated as interchangeable because they appear in the same catalog.

For routed or hosted models, preserve the actual provider path. A related family name does not establish that a direct endpoint and another host use identical charge conditions. Keep the host and any permitted fallback in the workload scenario so the estimate describes the deployed application.

Common mistakes

Do not describe missing price evidence as free. Unknown fields should remain unknown and should prevent a supposedly complete forecast when the category is essential.

Do not equate an output cap with actual usage. Inspect returned usage and completion state, then use the observed distribution of accepted responses when forecasting.

Do not count only the visible user prompt. Inspect assembled instructions, history, retrieved evidence and tool definitions. Those often explain a gap between a prototype estimate and deployed usage.

Do not turn on batch or caching in a calculator while leaving the application workflow unchanged. The estimate’s assumptions should correspond to implemented eligible behavior.

Do not combine a rate change and a prompt change when explaining a budget difference. Recalculate the old workload at the new rate first, then inspect application changes separately.

Last verified 12 Sep 2026 · Source ↗

Frequently asked questions

Sources

• OpenAI pricing ↗
• Claude pricing ↗
• Gemini pricing ↗
• Model Studio pricing ↗

Last verified 12 Sep 2026 · Source ↗