Introduction to Claude & the Anthropic Model Family

1 · What Claude is essential

Here's a mistake almost everyone makes on day one. They open the docs, copy the first messages.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 perfectly 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: Claude 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. Everything Claude 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 racist joke, or make up a citation because made-up citations look like real ones. So Anthropic does a second stage of training called alignment that reshapes which continuations the model prefers, steering it toward answers that are helpful, harmless, and honest (Anthropic's stated goal for Claude). 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 Claude "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 Claude stops being mysterious.

Now the precise version, which will land because you have the intuition. Claude is a family of large language models from Anthropic: trained on vast text to predict the next token, then aligned to be helpful, harmless, and honest. You interact with it as a conversation — a list of user/assistant messages — and it responds. Everything in this course is built on that simple loop.

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 single time "to be safe" — that's slow, clumsy, and wears the battery down for no reason. They match the tool to the task. Anthropic ships Claude the same way: not one model, but a family of tiers, and your job is to grab the right one.

The three names to know are Opus, Sonnet, and Haiku — and there's a lovely mnemonic buried in them. A haiku is the shortest poem, a sonnet is medium-length, and an opus is a grand full-length work; the model names track exactly that size and depth ordering. Haiku is the fastest and cheapest (the precision driver), Opus is the most capable and most expensive (the heavy drill), and Sonnet sits in the middle as the balanced workhorse (the everyday screwdriver you'll reach for most). Within each family there's also a version — this course uses claude-opus-4-8, claude-sonnet-4-5, and claude-haiku-4-5 — so the full ID pins down both which tier and which generation you're calling.

Why does having tiers matter, 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, the quickest, and the most fuel-efficient. The tiers exist precisely so you can pick your point on that triangle per task.

The common mistake — and it's the expensive one this whole chapter is built to cure — is defaulting to Opus for everything because it's "the best." At the volume of a real production system that habit can multiply your bill by 10–20x for tasks a smaller model handles identically. The professional instinct is the opposite: pick by the task, not by habit, start from the middle, and justify every move up or down. The table below is your starting map; the rest of the chapter turns it into a repeatable decision.

Claude comes in tiers trading capability for speed/cost. Pick by the task, not by habit.

3 · Tokens & the context window essential

A story that has surprised more than one engineer at the end of the month. You build a slick feature that pastes a whole PDF into the prompt "for context," ship it, and it works beautifully in the demo. Then the invoice lands and it's ten times what you budgeted — because you were paying for that entire PDF, in full, on every single request. Nothing was broken. You just never learned the two ideas in this section, and they are the ideas that quietly control both what the model can see and what it costs you.

Start with the token. The model doesn't read letters or whole words — it reads tokens, which are chunks of text roughly ¾ of a word long (common words are one token; longer or rarer words split into several). The mental picture: text is chopped into LEGO bricks before the model ever sees it, and it thinks, bills, and remembers in bricks, not in words. A handy rule of thumb is that 1,000 tokens is about 750 English words — a couple of paragraphs.

Now the context window: the maximum number of tokens the model can hold in its head at once — and, crucially, that budget covers both your prompt and its reply. The analogy that makes it click is a whiteboard of fixed size. Everything for this turn has to fit on the board: the system instructions, the conversation history, the documents you pasted, and the space left over for the answer. When the board is full, something has to be erased — which is why long agent conversations eventually need trimming or summarizing (you'll use a deque(maxlen=N) for exactly this in Ch 4). The window is not memory that persists between calls; it's a fresh whiteboard you re-fill on every request.

Here's why the two ideas fuse into one that matters: you are billed per token, so tokens are literally money, and input and output are usually priced differently (output tokens tend to cost several times more than input). That reframes prompt design as budgeting. The common mistake is treating context as free and stuffing it with "just in case" material — every extra token in that PDF is a tax you pay on every call, forever. The professional habit is the opposite: estimate before you build. The tiny lab below does exactly that, turning a fuzzy "is this affordable?" into arithmetic you can put in a design doc.

tokens.pydef estimate(words, out_words, in_per_mtok, out_per_mtok):
    # rough: 1 token ~= 0.75 words -> words / 0.75 tokens
    in_tok = words / 0.75
    out_tok = out_words / 0.75
    cost = in_tok/1e6*in_per_mtok + out_tok/1e6*out_per_mtok
    return round(in_tok), round(out_tok), round(cost, 4)

# a 2000-word RAG prompt, 300-word answer (illustrative prices)
print("Sonnet:", estimate(2000, 300, in_per_mtok=3, out_per_mtok=15))
print("Haiku: ", estimate(2000, 300, in_per_mtok=1, out_per_mtok=5))

Sonnet: (2667, 400, 0.014)
Haiku:  (2667, 400, 0.0047)

4 · Intermediate — how the models differ in practice intermediate

Imagine two chess players. One is a strong club player; the other is a grandmaster. Set them a simple three-move puzzle and they both solve it instantly — you genuinely cannot tell them apart. Now set them a subtle, twenty-move endgame where one wrong step loses, and the gap becomes enormous: the grandmaster sees the whole line, the club player goes astray somewhere in the middle. That is exactly the relationship between a small Claude and a large one, and internalizing it is what separates people who choose models well from people who guess.

Where does the difference actually come from? A bigger model has more capacity to reason over many steps without losing the thread, to follow complicated multi-part instructions reliably, and to stay grounded instead of hallucinating when a problem is genuinely hard. The intuition: on a hard task there are many places to take a wrong turn, and the larger model's extra "headroom" is what keeps it on the path. The flip side of that headroom is the bill and the clock — more capability means more cost per token and a little more latency.

The point that turns this into a design principle is the shape of the gap. It is not a constant. On easy work — classify this sentiment, extract this field, is this spam — a small, cheap model is often indistinguishable from the giant, just as both chess players ace the trivial puzzle. The capability gap only opens up as the task gets hard. So paying for the big model on easy tasks buys you nothing you can measure while charging you a premium on every call.

The common mistake here is assuming quality scales smoothly with price — that a 10x pricier model is "10x better" everywhere, so you should buy as much as you can afford. It doesn't work like that. On the easy majority the curve is flat; on the hard tail it's steep. The right question is never "which model is best?" but "where does this task sit on the difficulty curve, and is that where the models actually diverge?" That reframing is what the model selector in the next section makes concrete.

5 · Advanced — pick the right model per task advanced

Think about how a good triage nurse works. A patient walks in and the nurse doesn't agonize or ask the whole team — they run a fast, consistent checklist (how urgent, how complex, how busy are we) and route the person to the right level of care in seconds. The magic isn't genius per case; it's that the rule is written down, so every patient gets a defensible, repeatable decision. Choosing a Claude model deserves the same treatment — and if you leave it to individual taste, you get the opposite: everyone quietly picks Opus "to be safe" and the bill balloons.

So instead of deciding by vibes, we encode the decision as a function. The three inputs are the ones that actually move the answer: task hardness (how much reasoning does this genuinely need?), volume (how many times a day will this run?), and latency sensitivity (does a human sit waiting for the reply?). Feed those in, get a model out. The value isn't that the function is clever — it's that it's consistent: the same task always gets the same, explainable answer, and you can review the rule instead of arguing case by case.

There's one subtlety worth flagging before you read the code, because it's the thing interviewers probe and the thing that bites in practice: the rules are checked top to bottom, and it returns at the first match. That short-circuit means rule order is a design decision, not a formatting detail. A medium-hardness task can be caught by an earlier rule before the latency check is ever reached — so "why didn't my latency flag change the answer?" is almost always an ordering question. Read the checks in the exact sequence written, and stop at the first that fires; whatever sits below simply never runs for that input.

The common mistake a selector like this guards against is optimizing one axis in isolation — picking purely for capability and ignoring that the task runs a million times a day, or picking purely for cost on the one workload where a wrong answer is catastrophic. A deliberate choice weighs capability need vs volume vs latency budget together. Model the decision.

pick_model.pydef pick_model(task_hardness, volume_per_day, latency_sensitive):
    """hardness 1-5; returns the cheapest model that meets the need."""
    if task_hardness >= 4:
        return "opus"                          # hard reasoning worth the cost
    if task_hardness >= 2 or latency_sensitive is False:
        return "sonnet"                        # the workhorse default
    return "haiku"                             # simple + high-volume + latency-sensitive

print("complex agent:      ", pick_model(5, 1000, False))
print("prod RAG:           ", pick_model(3, 50000, False))
print("high-volume routing:", pick_model(1, 1_000_000, True))

complex agent:       opus
prod RAG:            sonnet
high-volume routing: haiku

6 · Professional — cost at scale professional

Here's the number that reframes everything. A choice that costs a fraction of a cent per request feels free when you're testing with fifty calls — the difference between models is rounding-error money. Now multiply by a million requests a day. Suddenly that "free" per-call difference is a line item a finance team will ask you about by name. This is the moment model choice stops being a technical preference and becomes a budget decision, and the engineers who understand that are the ones trusted to run systems at scale.

The everyday analogy is a delivery fleet. You wouldn't send a fully-loaded semi-truck to drop off a single envelope — you'd use a bike courier, and save the truck for the pallet that actually needs it. Sending every request to Opus is exactly that mistake: a semi-truck for the envelopes. A task that's fine on Haiku but run on Opus can cost 10–20x more for no quality gain — you're paying premium capability the task never uses.

The fix is tiered routing: look at each request, send the easy majority to the cheap fast model, and escalate only the genuinely hard minority to the expensive one. Because real workloads are usually mostly-easy — think 90% routine, 10% hard — the cheap model absorbs the bulk of the traffic and the pricey model only touches the slice that needs it. The savings can be dramatic, and the lab below shows precisely how dramatic, and under what conditions.

The common mistake to watch for is assuming the saving is fixed — that "routing saves ~86%" is a law of nature. It isn't; it's entirely a function of how much of your traffic is actually hard. The saving is really the price gap multiplied by the easy share, so as the hard fraction climbs, the routed bill climbs toward the all-Opus bill and the win erodes. Routing pays off most when the easy majority is large — which is exactly why measuring your traffic mix comes before choosing a routing policy, not after.

routing_cost.pydef routed_cost(total, pct_hard, haiku_cost, opus_cost):
    hard = total * pct_hard
    easy = total - hard
    routed = easy*haiku_cost + hard*opus_cost         # route easy->haiku, hard->opus
    all_opus = total*opus_cost
    return round(routed,2), round(all_opus,2), round(100*(all_opus-routed)/all_opus)

routed, naive, saved = routed_cost(1_000_000, 0.1, 0.001, 0.02)
print(f"tiered routing: ${routed} | all-opus: ${naive} | saved {saved}%")

tiered routing: $2900.0 | all-opus: $20000.0 | saved 86%

7 · Tech-lead — a model policy for the team tech-lead

Watch what happens when there's no policy. Ten engineers each make a locally reasonable model choice. One defaults to Opus because a demo needed it; another copies that config into a high-volume endpoint without thinking; a third picks Haiku for a task that quietly needs more. Every individual decision looked fine. In aggregate you get a spend chart nobody can explain and a quality baseline nobody agreed to. The lesson every lead learns eventually: a decision made ten different ways is not a decision — it's ten accidents.

The remedy isn't heroics, it's a written model policy: one page that makes the team's defaults explicit. Think of it like a coding style guide. Its value isn't that any single rule is brilliant — it's that everyone follows the same rule, so choices become reviewable, teachable, and consistent instead of a per-engineer whim. A good policy states four things: the default tier, the rules for when to escalate up or downgrade down, the cost guardrails (declare expected tokens and volume at design time; alert on deviation), and how model choice gets reviewed — in design, like any capacity decision.

The load-bearing phrase in the whole policy is "with evidence." The point of a default (Sonnet, for this course) isn't that Sonnet is always right — it's that moving off the default requires a reason you can point at: an eval showing Sonnet failing the hard cases (escalate to Opus), or an eval showing a cheaper model is good enough for the volume (downgrade to Haiku). This is the discipline from Ch 5 applied to procurement: measurement sizes the fleet, not opinion.

The common mistake a policy exists to kill is the "to be safe" default — everyone reaching for the biggest model because no one will get blamed for over-provisioning. It feels prudent and it's quietly the most expensive habit a team can have. A lead reframes it: model choice is an architecture decision — which model, where, and how you route between them shapes the cost, latency, and quality of the whole system — so it's measured, budgeted, and revisited, not defaulted. The exercises below have you write exactly this policy for a concrete app.

def estimate(words, out_words, in_per_mtok, out_per_mtok):
    # rough: 1 token ~= 0.75 words -> words / 0.75 tokens
    in_tok = words / 0.75
    out_tok = out_words / 0.75
    cost = in_tok/1e6*in_per_mtok + out_tok/1e6*out_per_mtok
    return round(in_tok), round(out_tok), round(cost, 4)

print("Sonnet:", estimate(2000, 300, in_per_mtok=3, out_per_mtok=15))
print("Haiku: ", estimate(2000, 300, in_per_mtok=1, out_per_mtok=5))

Sonnet: (2667, 400, 0.014)
Haiku:  (2667, 400, 0.0047)

def pick_model(task_hardness, volume_per_day, latency_sensitive):
    """hardness 1-5; returns the cheapest model that meets the need."""
    if task_hardness >= 4:
        return "opus"                          # hard reasoning worth the cost
    if task_hardness >= 2 or latency_sensitive is False:
        return "sonnet"                        # the workhorse default
    return "haiku"                             # simple + high-volume + latency-sensitive

print(pick_model(3, 50000, True))   # -> sonnet

def routed_cost(total, pct_hard, haiku_cost, opus_cost):
    hard = total * pct_hard
    easy = total - hard
    routed = easy*haiku_cost + hard*opus_cost         # route easy->haiku, hard->opus
    all_opus = total*opus_cost
    return round(routed,2), round(all_opus,2), round(100*(all_opus-routed)/all_opus)

print(routed_cost(1_000_000, 0.1, 0.001, 0.02))   # (2900.0, 20000.0, 86)

tiered routing: $2900.0 | all-opus: $20000.0 | saved 86%

def pick_model(task_hardness, volume_per_day, latency_sensitive):
    if task_hardness >= 4:
        return "opus"
    if task_hardness >= 2 or latency_sensitive is False:
        return "sonnet"
    return "haiku"

def estimate(words, out_words, in_per_mtok, out_per_mtok):
    in_tok = words / 0.75
    out_tok = out_words / 0.75
    cost = in_tok/1e6*in_per_mtok + out_tok/1e6*out_per_mtok
    return round(in_tok), round(out_tok), round(cost, 6)

PRICES = {"opus": (15, 75), "sonnet": (3, 15), "haiku": (1, 5)}  # illustrative per-Mtok

workloads = [
    ("planning agent", 5, 1_000,     False, 3000, 800),
    ("RAG endpoint",   3, 50_000,    False, 2000, 300),
    ("classifier",     1, 1_000_000, True,   200,  10),
]
for name, hard, vol, lat, win, wout in workloads:
    m = pick_model(hard, vol, lat)
    tok_in, tok_out, cost = estimate(win, wout, *PRICES[m])
    print(f"{name:16} -> {m:6} ~${cost}/req  x {vol}/day")

Knowledge check check yourself