Introduction to GPT & the OpenAI Model Family

1 · What GPT is essential

Here's a mistake almost everyone makes on day one. They open the docs, copy the first responses.create snippet, swap in their prompt, and treat the model as a magic box that "understands English." Then it does something baffling — invents a fact, refuses a reasonable request, or trails off mid-sentence — and they have no mental model to explain why. The fix isn't more prompt-tweaking; it's knowing, at a gut level, what the thing actually is. Ten minutes here saves you a week of confused debugging later.

So here's the honest one-sentence version: GPT is a very, very good autocomplete. Think of the predictive text on your phone that suggests the next word — now imagine that same trick scaled up on a supercomputer, trained on a huge slice of the written world, until "predict the next word" starts producing working code, coherent essays, and step-by-step reasoning. That's not a metaphor that breaks down later; it's literally the machinery. GPT stands for Generative Pre-trained Transformer — "generative" because it produces text, "pre-trained" because it learns from vast data before you ever call it, and "transformer" after the neural-network architecture underneath. Everything it does is choosing the next token (roughly, the next chunk of text) given everything it has seen so far, one token at a time, left to right.

But raw autocomplete would be useless — and often dangerous. A model that only predicts "what text usually comes next" will happily continue a harmful rant, or make up a citation because made-up citations look like real ones. So OpenAI does a second stage of training called alignment — chiefly RLHF (reinforcement learning from human feedback) — that reshapes which continuations the model prefers, steering it toward answers that are helpful, honest, and safe. The everyday analogy: the base model is a brilliant new hire who has read everything but has no judgment; alignment is the onboarding that teaches them what's actually appropriate to say at work.

The common mistake to name and avoid: believing GPT "knows" things the way a database knows things. It doesn't look up facts — it predicts plausible text, and plausible is not the same as true. That single insight explains hallucinations (confident wrong answers), why grounding it in retrieved documents (RAG, Ch 3) matters so much, and why you verify anything load-bearing. Keep the autocomplete picture in your head and GPT stops being mysterious.

2 · The model family essential

Picture the tool wall in a decent workshop. There's a cordless screwdriver you grab a hundred times a day, a heavy drill for the jobs the screwdriver can't manage, and a tiny precision driver for fiddly, repetitive work. A good tradesperson doesn't reach for the biggest drill every time "to be safe" — they match the tool to the task. OpenAI ships GPT the same way: not one model, but a family, and your job is to grab the right one.

Here's where OpenAI differs from Anthropic in a way worth naming up front. Anthropic publishes three tidy, stable tier names — Opus, Sonnet, Haiku. OpenAI's lineup is less tidy and changes faster: there's a general-purpose flagship model (this course's examples use the id gpt-5.5), smaller and cheaper "mini" variants for high-volume work, and specialized realtime/audio models (for example gpt-realtime-2 for voice and gpt-4o-family models for multimodal). The important discipline: don't memorize or hard-code a tier name as if it were permanent. Think in roles — flagship for the hard stuff, mini for the cheap high-volume stuff, realtime for voice — and pin the exact model id in one config value you can swap when OpenAI ships the next generation.

Why have a family at all, rather than one model that does everything? Because the three axes you care about — capability, speed, and cost — genuinely trade against each other. A bigger model reasons over more steps and makes fewer mistakes on hard problems, but every token it produces costs more and arrives a little slower. There is no single model that is simultaneously the smartest, the fastest, and the cheapest, any more than there's one vehicle that's the roomiest, quickest, and most fuel-efficient. The family exists precisely so you can pick your point on that triangle per task.

The common mistake — the expensive one this chapter is built to cure — is defaulting to the flagship for everything because it's "the best." At the volume of a real production system that habit can multiply your bill many times over for tasks a mini model handles identically. The professional instinct is the opposite: pick by the task, not by habit, start from a mid/mini model, and justify every move up to the flagship with evidence.

3 · Tokens & the context window essential

Here's the unit that quietly runs your whole bill. The model doesn't read characters or words — it reads tokens, chunks of text roughly ¾ of a word on average ("tokenization" splits "unbelievable" into something like un, bel, iev, able). Every request is priced in tokens: what you send (input tokens) and what comes back (output tokens), and output usually costs several times more per token than input. If you only remember one thing for cost control, make it this: fewer tokens in and out means a smaller bill and a faster reply.

The second concept is the context window — the maximum number of tokens the model can "see" in a single request, input plus output combined. Think of it as the model's working desk: everything it can reason about has to fit on the desk at once. Modern GPT models have large windows, but they are not infinite, and two things go wrong when you forget this. First, a long conversation or a big pile of retrieved documents can simply overflow the window and the call fails. Second — subtler — stuffing the window full costs real money and can actually dilute the model's attention on what matters. More context is not automatically better.

The common mistake: treating the context window as free scratch space and dumping entire documents, whole chat histories, and verbose system prompts into every call "just in case." At scale that's the difference between a sustainable product and a runaway bill. The professional move is to send the least context that still answers the question — which is exactly why retrieval (RAG) exists: fetch only the relevant chunks instead of pasting the whole corpus.

4 · How the models differ in practice intermediate

On paper the family is a tidy ladder; in practice the differences show up as behavior under pressure. A mini model is perfectly capable of classifying a support ticket or extracting a date — the easy, well-specified work — and it will do it faster and cheaper than the flagship. Where the gap opens up is on tasks that need chains of reasoning: multi-step math, debugging a subtle logic error, planning an agent's next five moves, or holding many constraints in mind at once. There, the flagship's extra capacity turns into measurably fewer mistakes.

OpenAI also exposes a reasoning-effort dial on its reasoning-capable models: reasoning={"effort": "low"} through "high" (and "max"). This is the knob that lets one model span a range — spend little effort on an easy question (fast, cheap) and more on a hard one (slower, pricier, more careful). It's the OpenAI analog of asking the model to "think longer before answering," and like model choice itself, it's a cost/quality trade you should set deliberately per task, not leave at a reflexive maximum.

5 · Pick the right model per task advanced

This is the skill that separates a demo from a system. The decision has two knobs, not one: which model and how much reasoning effort. Treat them as a single question — "what's the cheapest (model, effort) pair whose evals clear this task's quality bar?" — and you'll make deliberate choices instead of defaulting to the biggest, slowest, most expensive option out of anxiety.

The method is the same one the Claude section teaches, because it's vendor-neutral: start from the middle, move with evidence. Begin with a mid or mini model at medium effort. Run your evals (Ch 5). If it's failing the hard cases, escalate — a bigger model, or more effort, whichever your evals say helps. If it's acing everything, downgrade — a smaller model or less effort — and bank the savings. The only thing that justifies a move up or down is a measured result, never a hunch.

first_call.pyfrom dotenv import load_dotenv
from openai import OpenAI
load_dotenv()
client = OpenAI()                      # reads OPENAI_API_KEY from the env

resp = client.responses.create(
    model="gpt-5.5",                 # one config value you can swap later
    instructions="You are a concise assistant.",  # the system role
    input="Explain what an API token is in two sentences.",
)
print(resp.output_text)                # the generated text
print(resp.usage.input_tokens, resp.usage.output_tokens)  # cost, every call

6 · Cost at scale professional

At one request a day, model choice is a rounding error. At a million requests a month, it's a budget line with your name on it. This is where the "pick by task" discipline pays for itself. The single most powerful pattern is tiered routing: send the easy majority of traffic to a cheap mini model and escalate only the genuinely hard minority to the flagship. If 90% of requests are easy and you route them to a model that costs a fraction of the flagship, you save most of your bill versus sending everything to the big model — and the savings are largest exactly when the easy majority is large.

The second lever is output length. Output tokens bill at the higher rate, so a verbose model that pads every answer with preamble costs more than a terse one that says only what's needed — for identical quality. Cap max_output_tokens, ask for concise answers in the instructions, and don't pay for politeness filler.

estimate.py# $ per 1M tokens (illustrative — check current pricing)
RATES = {
    "flagship": {"in": 5.0, "out": 15.0},
    "mini":     {"in": 0.4, "out": 1.6},
}

def monthly(model, reqs, in_tok, out_tok):
    r = RATES[model]
    return reqs * (in_tok*r["in"] + out_tok*r["out"]) / 1_000_000

# 1M requests: all-flagship vs route 90% to mini
all_big = monthly("flagship", 1_000_000, 800, 400)
routed  = monthly("mini", 900_000, 800, 400) \
        + monthly("flagship", 100_000, 800, 400)
print(f"all-flagship: ${all_big:,.0f}  routed: ${routed:,.0f}")

7 · A model policy for the team tech-lead

Model choice is an architecture decision, not a per-engineer whim. Left unmanaged, every developer picks the flagship "to be safe," and your bill is the sum of everyone's anxiety. A one-page team policy turns it into a deliberate, reviewable choice — the same way you'd review a database or a capacity decision.

Knowledge check check yourself