Why This Lesson Exists

Unit 1 already made one point that's worth restating before going further: model names change faster than almost anything else in this ecosystem. gpt-6-astra and gpt-5.6-luna are today's names; by the time you're reading this, OpenAI may well have shipped another generation. If this lesson taught you to memorize "use gpt-5.6-luna for cheap tasks," that advice would quietly expire and you wouldn't necessarily notice — your code would keep running against a model that's no longer the best (or cheapest, or fastest) option for the job.

So instead, this lesson teaches you two things that don't expire: a decision process for picking a model based on what your task actually needs, and how to read OpenAI's models and pricing pages so you can apply that process to whatever models exist when you're actually building.

The Decision Process: Accuracy First, Then Cost and Speed

OpenAI's own model-selection guidance boils down to a specific order of operations, and it's worth following rather than reinventing:

1. Start with the most capable model you have access to, and establish whether it can do the task at all. Before optimizing for cost, confirm the ceiling — build a small evaluation set (even 10–20 representative examples of your actual task) and run it against the strongest available model, currently something like gpt-6-astra. If even the most capable model can't reliably do what you need, no amount of model selection further down the list will fix that; you have a task-design problem, not a model-selection problem.

2. Once you have a working baseline, work backward toward "cheapest and fastest model that still hits your accuracy target." This is the part people skip, and it's where real money gets left on the table. A huge share of production AI features — classifying a support ticket's category, extracting a name and date from text, answering a narrow FAQ — do not need a flagship reasoning model. They need a small, fast, cheap model that's good enough, run against the same evaluation set you built in step 1 to confirm it's still accurate enough once you swap down.

3. Re-run your evaluation set every time you change models. "Good enough" for one prompt and one task is not transferable — always verify empirically rather than assuming a cheaper model will behave the same way a more capable one did.

This process matters more than any specific model name, because it's the same process whether you're choosing between today's four model tiers or a completely different lineup two years from now.

The Axes That Actually Differentiate Models

When you open OpenAI's models page, you'll see each model described along a handful of consistent axes. Understanding what each one means lets you read that page intelligently instead of pattern-matching on names.

Capability tier. Models are generally organized into a small number of tiers — a flagship/frontier tier (maximum capability, highest cost), one or two mid tiers, and a lightweight/fast tier. As of this writing, OpenAI's lineup looks roughly like this:

Treat every number in that table as a snapshot, not a fact to memorize. Prices move, tiers get renamed, and new models slot in above or below existing ones. What's durable is the shape of the table: there is consistently a spread of roughly 50x between the cheapest and most capable models, and that spread is the entire reason step 2 of the decision process above matters — picking the wrong tier for a high-volume task can mean paying fifty times more than necessary for no accuracy benefit.

Context window: short vs. long. Notice the pricing table above only shows "short context" rates — most current models actually have two pricing tiers depending on how much text you're sending in a single request (a "long context" rate applies above a certain input size, and it's noticeably higher — for gpt-6-astra, roughly double). This matters directly for cost planning: a task that processes long documents needs its cost estimated at the long-context rate, not the headline short-context number that's easiest to remember.

Reasoning vs. non-reasoning. Some models (like gpt-6-astra, and specific reasoning-focused snapshots) do internal, extended reasoning before answering — useful for math, multi-step logic, and complex debugging, at the cost of higher latency and more output tokens (since reasoning consumes tokens too, billed at the output rate, even when you don't see the reasoning text itself). Others are tuned for fast, direct responses without that extended reasoning step. Unit 3 covers how to control this behavior explicitly via reasoning_effort; for model selection purposes, the takeaway is: don't reach for a reasoning-tier model for tasks that don't need multi-step logic — you'll pay more and wait longer for no benefit.

Caching discount. Every current model offers a steep discount — roughly 90% off the standard input rate — for tokens the API recognizes as repeated from a recent prior request (this is the same caching behavior referenced in Lesson 1's discussion of why the Responses API improves cache hit rates). If your application repeatedly sends a large, mostly-unchanging block of instructions or context, this discount can dominate your actual cost far more than the headline per-token price does.

Specialized variants. Beyond the general-purpose tiers, OpenAI publishes narrower models for specific jobs — for example, a coding-specialized model (gpt-5.3-codex in the current lineup) or a chat-optimized snapshot (chat-latest). These exist because a model tuned for one job can outperform a larger general-purpose model at that specific job, often at a lower price. Don't assume "biggest general model" beats "smaller specialized model" for a specialized task — check, using the same evaluation-driven process as everything else in this lesson.

Reading the Models Page Itself

When you open OpenAI's models documentation, resist the urge to just find a name that looks familiar and copy it. Instead, look for these specific things:

The model ID column — the exact string you'll pass as model=. Copy this precisely; a nearly-correct model ID fails with an error rather than silently falling back to something close.

Aliases vs. dated snapshots. OpenAI generally publishes both a rolling alias (something like gpt-5.6-terra, which points at "whatever the current best terra-tier snapshot is") and specific dated snapshots (something like gpt-5.6-terra-2026-08-15, frozen at that exact version forever). This distinction matters for a real engineering decision:

• Use the rolling alias during development, prototyping, and for most applications where you want to automatically benefit from quality and safety improvements as OpenAI updates the underlying snapshot.
• Pin a specific dated snapshot for production systems where behavioral consistency matters more than automatically getting the newest version — for example, if your prompts were carefully tuned against one specific snapshot's behavior, and an automatic upgrade could shift outputs in ways your tests don't catch. Pinning trades "automatically getting better" for "guaranteed not to change out from under you."

Context window size, usually listed in tokens (for example, a model might support a 128,000 or 400,000 token context window). This caps how much conversation history, document text, or tool output you can send in a single request — relevant the moment you build anything in Unit 4 involving longer conversations, or Unit 7 involving large documents.

Modalities supported. Not every model accepts every kind of input — some support text only, others accept images (Unit 7), and capabilities like audio input/output or image generation are sometimes handled by entirely separate specialized models rather than a flag on a general-purpose one. Check this before assuming a model can handle whatever input type your feature needs.

Rate limits, usually documented per-tier based on your account's usage level rather than per-model — worth checking separately if you're planning a high-throughput application, since this affects how many requests per minute you can actually sustain, independent of per-token pricing.

A Practical Example: Choosing a Model for Three Different Tasks

Applying the process above to three concrete scenarios:

Classifying incoming support tickets into five fixed categories. This is a narrow, well-defined task with a small, checkable answer space — a strong candidate for the lightest tier. Build a 20-example evaluation set of tickets with known correct categories, test gpt-5.6-luna against it, and only move up a tier if accuracy falls short.

Debugging a gnarly multi-file concurrency bug from a large codebase. This is exactly the kind of multi-step reasoning task that benefits from a reasoning-capable, flagship-tier model — gpt-6-astra — where the higher per-token cost is worth paying because the task genuinely requires deeper reasoning, and getting it wrong costs more (in engineering time) than the price difference between tiers.

A customer-facing chatbot answering general product questions at high volume. This sits in the middle — probably too broad and unpredictable for the lightest tier to handle reliably, but not complex enough to justify flagship reasoning pricing at high volume. A mid-tier model like gpt-5.6-terra, validated against a representative evaluation set of real customer questions, is the natural starting point — with room to reconsider if evaluation reveals specific categories of questions it handles poorly.

Common Mistakes

Defaulting to the flagship model for everything "to be safe." This treats model selection as a cost-blind decision, and given the roughly 50x price spread across tiers shown above, it's often the single most expensive mistake in an OpenAI-powered application's budget.

Defaulting to the cheapest model for everything "to save money." The inverse mistake — without an evaluation set confirming the cheap model actually performs the task correctly, you're trading a knowable cost for an unknowable accuracy risk.

Hardcoding a specific dated snapshot everywhere out of caution, then never revisiting it. Pinning is a legitimate choice for stable production systems, but pinning and then forgetting means you never benefit from real improvements — and eventually, older snapshots do get formally deprecated and stop working, which is a worse surprise than a planned upgrade.

Comparing prices without accounting for context length. Estimating cost using only the short-context rate for a workload that regularly exceeds the context threshold will noticeably underestimate your actual bill.

Best Practices

Build a small, representative evaluation set for any task before you commit to a model tier — it's the only reliable way to know whether "cheaper" still means "accurate enough" for your specific use case. Use rolling aliases during development and reserve pinned dated snapshots for production systems where consistency matters more than automatic improvement. And revisit this decision periodically: because model names, tiers, and prices genuinely do change over time, treat "which model should this feature use" as a question worth re-asking every few months, not a decision you make once and never touch again.