All OpenAI (GPT) models available through the API

Choose an OpenAI API model using the documented identifier, input capabilities and request interface. Keep your application’s evaluation criteria independent of the model’s marketing description.

Model families at OpenAI

The official model catalog groups general reasoning and text models alongside specialized capabilities. Its current model entries provide the identifiers used by the API. Official documentation.

For a shortlist, record the required input, output form, tool support and latency tolerance. A text-generation candidate is not automatically a substitute for an embedding or speech endpoint.

Define the job before selecting an identifier. An extraction application needs reliable fields and evidence handling; a coding application needs changes that pass the repository’s checks; a voice application needs an audio path whose output can be evaluated by listening. These requirements should determine the model shortlist rather than the order of a marketing catalog.

Keep model capability and application quality separate. A documented structured-output feature may help constrain shape, but you still need to check the values. A tool-capable model still needs a correct application tool loop. Write evaluation criteria for both layers and preserve the fixtures used to test them.

Compare candidates on the same task and with the same acceptance bar. Review failed cases before turning a price difference into a recommendation. A model that produces an acceptable result less often may require additional work elsewhere in the application. Record that repair effort rather than counting every generated answer as a completed task.

All models

Inspect exact identifiers and lifecycle status, not just family names. If the live record does not contain verified evidence for a field, leave the field unresolved. The catalog is a reference for what is documented, not a promise that your particular account can call every listed model.

Keep the endpoint alongside the model in your application inventory. A Responses request, an embedding request and an audio-generation request should not be treated as interchangeable simply because they use the same provider account. The request schema and response handling belong in the model selection decision.

When reviewing a code example, copy identifiers from the current catalog rather than building them from a display label. Record which model the running application actually selected, including configuration overrides. This helps explain why a deployed worker can behave differently from an editor that appears to use the same model family.

Cheapest / strongest / longest-context

Price and context rankings are measurable attributes. The strongest candidate for your workflow still depends on accepted results from representative tasks.

Use numerical rankings to filter candidates, then test the survivors. Input price, output price and context capacity describe different attributes. An application that produces detailed patches should not rank candidates solely by the cost of its short user instruction. A retrieval-heavy workflow should not assume that the largest context necessarily finds evidence most accurately.

Prepare a comparison record with task quality, accepted completion, elapsed time and returned usage. Label whether each item is documented by the provider or measured by your own evaluation. Do not combine a vendor positioning statement with an unrelated benchmark into an invented overall strength score.

If you lack quality evidence, state the fit you can establish: the model accepts the required input and supports the needed interface. Leave the stronger claim unresolved. That is still a useful shortlist and gives the next evaluation a clear purpose.

Deprecations and replacements

Keep a saved baseline and review the provider’s linked deprecation guidance before changing production identifiers. Test request fields as well as response quality when moving between model generations.

Before a migration, save a baseline of requests, outputs and application checks. Inventory optional fields, output parsers and hosted features that depend on the current model or interface. An identifier change can affect more than response wording, so the test should cover the complete request path.

Read the linked lifecycle and migration guidance for the selected model. Treat a recommended replacement as a candidate to evaluate, not a guarantee of identical behavior. Keep difficult inputs and failure cases in the regression set. Make rollback a deliberate decision while the previous deployment remains available.

After adopting a replacement, update the configuration, evaluation record, budget assumptions and operating documentation together. Preserve the reason for the change and the evidence that supported it. A future maintainer should be able to distinguish a deliberate migration from an unexplained model string copied into a worker.

Naming and versions

The catalog distinguishes model IDs and, where applicable, aliases. Preserve the actual selected identifier in your application configuration. Official documentation.

Check the model’s price categories and available throughput as part of the same decision.

Use the AI API cost calculator to turn the model and workload you are considering into an estimate.

Use a display name in human-facing explanations and an exact API identifier in configuration. If an alias is offered, decide whether convenience or reproducibility is more important for this application. Preserve the actual selected identifier with evaluation results so a later review can understand what produced them.

Search the application inventory for hidden model selections before declaring a migration complete. Examples, background jobs and deployment settings can each contain their own value. Centralize the decision where practical and make changes reviewable rather than allowing every call site to choose independently.

When a model-not-found error appears, inspect the runtime value and account access. Do not replace it with a familiar name merely to get any response. Select a documented candidate that fits the task and rerun the relevant checks before restoring unattended work.

Last verified 12 Sep 2026 · Source ↗

Frequently asked questions

Sources

• OpenAI developer quickstart ↗
• OpenAI models ↗
• API pricing ↗
• Rate limits ↗
• Error codes ↗
• Production best practices ↗
• Batch API ↗
• Spend limits ↗

Last verified 12 Sep 2026 · Source ↗