The Models Behind Codex

The Model Layer Is Not a Detail

Most tutorials treat model selection as a footnote: "use GPT-4o for complex tasks, something cheaper for simple ones." That framing undersells how consequential the decision is. The model you pick and the reasoning effort you configure are the primary dials for cost, latency, and quality. Get them wrong in the wrong direction and you either overpay significantly or get outputs that fail at the worst moments.

This lesson is about reading those dials correctly.

The Tier Concept (Not the SKU)

OpenAI releases new models regularly and retires old ones. Specific model names — the SKUs that appear in API calls — have a short shelf life. A model that is the recommended choice today may be deprecated in three months when a successor arrives.

This is why you should internalize the tier concept rather than memorizing specific names:

• Fast / Mini tier — optimized for speed and cost. Short context, fast response, good at well-defined tasks. Built for high-volume, latency-sensitive applications.
• Standard tier — balanced capability. The default choice for most coding and analysis tasks. Handles multi-file reasoning and moderate complexity well.
• Advanced tier — maximum reasoning capability. Long context, deep chain-of-thought. Expensive and slow. Reserve for genuinely complex architectural analysis, hard algorithmic problems, and high-stakes decisions.

Check platform.openai.com/docs/models for the current SKU that maps to each tier. The tier logic stays constant; the names change. Write your code against the tier concept and update the SKU when OpenAI releases a new model — that is two lines of configuration, not a refactor.

The Reasoning Effort Control

The reasoning_effort parameter controls how much internal chain-of-thought processing the model performs before generating its response. Think of it as a dial between speed and depth. The accepted values are roughly ordered from least to most deliberation — none, low, medium, high, xhigh — with medium as the default. (The exact set is model-dependent and evolving, so confirm the values your chosen model supports in the live docs before relying on a specific one.)

At the low end (none/low), the model skips most internal deliberation and generates the response directly. This is appropriate for tasks where the right answer is immediately obvious from the input, or where low latency matters more than depth — short grammar corrections, simple code formatting, quick lookup questions.

At the high end (high/xhigh), the model works through the problem extensively before producing output. This is appropriate for tasks where the first instinct is often wrong — deep architectural analysis, hard algorithm design, debugging subtle race conditions, or hard asynchronous agentic work.

The key insight from the tradeoff chart: quality improves logarithmically as effort increases, but cost grows faster than quality above "medium." Stepping up from the lowest levels buys you substantial quality improvement for a moderate cost increase. The jump from medium to high/xhigh buys you marginal quality improvement for a steep cost increase. medium is the efficient frontier — and the default — for most non-trivial coding tasks.

You set reasoning_effort directly when you call the model through the API; the “The Responses API” lesson shows exactly where it goes in a Responses API request.

Cost & Latency Reference

Throughout this track you will see multipliers quoted in passing — "6-12x the cost," "3-20x slower," "10-15x more for the advanced tier." Those numbers are not arbitrary; they come from the same two dials. This reference grounds them in one grid: model tier down the rows, reasoning effort across the columns, with a relative cost multiplier and a rough latency band in every cell.

Read the grid in two directions. Down a column is the tier tax: holding effort constant, stepping from Fast/Mini to Advanced multiplies cost by an order of magnitude. Across a row is the effort tax: holding the tier constant, stepping from none to xhigh raises both the price and the latency floor. The cheapest, fastest cell is the top-left; the most expensive, slowest cell is the bottom-right. Most production routing decisions are about staying as close to the top-left as the task will allow.

A critical caveat: the cells are relative and approximate. Codex moved to token-based pricing in 2026, and OpenAI revises both SKUs and rates regularly — the example model names in the row labels (gpt-5.4-mini, gpt-5.3-codex, gpt-5.5) are current at the time of writing and will change. Use the grid to internalize the shape of the tradeoff; look up the current absolute numbers at developers.openai.com/codex/pricing before you commit a budget.

The Selection Matrix

The matrix is a decision tool, not a lookup table. Real tasks do not always fit neatly into one row. When a task falls between two rows, use the latency requirement as the tiebreaker: if your SLA has a ceiling, it usually forces the tier and effort choice regardless of quality preferences.

Three scenarios that come up frequently:

The user-facing interactive feature. If the user is waiting for a response in a text box, you have roughly 1-3 seconds before they start losing confidence. That ceiling limits you to the fast/mini or standard tier at low-to-medium effort. Design the task prompt to work within that constraint rather than upgrading the model to cover a poorly specified task.

The background analysis job. No user is waiting. The result will be stored and displayed later. This is where the advanced tier earns its cost — the latency is irrelevant, so you optimize purely for quality. Use high effort without hesitation.

The cost-constrained high-volume feature. At 100,000 requests per day, the difference between standard-low and advanced-high is not a quality discussion — it is a product economics discussion. Benchmark both. The standard tier at low effort almost always achieves 95%+ of the quality at 10-15% of the cost for well-defined tasks.

Context Windows

Context window size — the total number of tokens the model can process in a single call — varies significantly across tiers. The advanced tier handles much longer contexts than the fast/mini tier.

For Codex specifically, context window size matters in two ways:

First, the agent loop accumulates context across iterations. Each observe phase adds output to the running context (tool results, file diffs, command output). On long runs, this can push against the context ceiling of smaller models. If you are building multi-step agentic workflows that modify many files, ensure you are using a model tier with sufficient context for the expected run length.

Second, the cost calculation is token-based. Larger context windows cost more per call because there are more tokens being processed. This is another reason to scope tasks tightly — not just for quality, but because every file you include in the initial Perceive phase costs tokens.

Building the Router

The pattern that pays compound dividends is a task-classification step before every model call. A lightweight classifier — using the fast/mini tier at the lowest effort, which is nearly free — reads the task description and assigns it a complexity level and latency budget. That classification determines the model tier and reasoning effort for the actual task.

Production retrieval systems use this exact pattern. Every query in a knowledge base can be pre-classified by a fast router that estimates query complexity before deciding which model tier handles the actual retrieval and synthesis. The overhead of the classification call is negligible; the cost savings on the hundreds of simple queries that never need the advanced tier are significant. You can read more about these architecture patterns at jeremyknox.ai.