Week 1: How Claude & LLMs Actually Work

Before you write a single prompt, get the mental model right — because "it's a search engine that talks back" and "it's basically magic" are both wrong in ways that will bite you later. This week covers what a large language model is actually doing when it answers you, why context windows and tokens matter to how you work, which Claude model to reach for, and which of the three surfaces — claude.ai, the API, or Claude Code — fits the job in front of you.

Module 1 of 14 Week 1 of 14 ~2 Hours Hands-on Exercise Included

By the end of this week, you'll be able to

  • Explain what a token is and why context windows have a size limit
  • Pick between Opus, Sonnet & Haiku for a given task, and explain why
  • Choose the right surface — claude.ai, the API, or Claude Code — for a task

1. What a Large Language Model Is Actually Doing

Strip away the branding and Claude is a very large neural network trained to do one thing: given some text, predict what text comes next. That's it. Every reply you've ever seen from any chat-style AI — the explanations, the code, the jokes — is the product of that single mechanism applied over and over, one small chunk of text at a time, until the model decides it's done.

the loop, conceptually
prompt: "The capital of France is"
model predicts the single most-likely next chunk: " Paris"
new text: "The capital of France is Paris"
model predicts the next chunk given ALL of the text so far: "."
new text: "The capital of France is Paris."
model predicts a special "stop" signal → done

What makes this useful instead of a party trick is scale: the model was trained on an enormous amount of text, so "predict what comes next" ends up requiring it to have internalized grammar, facts, reasoning patterns, code syntax and a rough model of what a helpful answer looks like — not because anyone hand-coded those things in, but because getting next-token prediction right at that scale basically requires it.

This is also why it hallucinates

A model that's fundamentally predicting "plausible next text" has no built-in mechanism that distinguishes "this is true" from "this reads like something true would read like." It's usually right, because true things tend to look true — but that's a correlation, not a guarantee, which is exactly why Week 3 spends real time on reducing hallucination.

2. Tokens & Context Windows

Models don't read text character by character or word by word — they read tokens, chunks that are usually a bit smaller than a word ("token", "iz", "ing" might be three tokens for "tokenizing"). Every word you type, every line of code you paste, and every word Claude writes back costs tokens, and that matters because of the context window: the maximum number of tokens a model can "see" at once, covering your entire conversation, any files you've attached, and the response it's generating.

rough intuition, not exact numbers
1 token           =~ 4 characters of English text, on average
1,000 tokens      =~ 750 words =~ 1.5 pages of a book
Claude's context  =  large enough for entire codebases and long documents,
                     but NOT infinite — it's a hard ceiling, not a soft one

Once a conversation's total tokens (everything said so far, plus what's about to be generated) would exceed the context window, something has to give — usually the oldest messages get dropped or the request fails outright. This is the single most common reason a long chat session starts "forgetting" something you told it early on: it's not that the model got worse, it's that the early text fell out of the window.

Why this matters practically

If Claude seems to have "forgotten" a detail from earlier in a very long session, that's a context-window symptom, not a memory bug — the fix is usually to re-state the important detail, start a fresh conversation, or (in Claude Code and Projects) rely on a persistent file like CLAUDE.md instead of chat history. More on that in Weeks 4 and 10.

3. The Claude Model Family: Opus, Sonnet & Haiku

Anthropic ships Claude as a family of models trading off capability, speed and cost against each other, so you pick the smallest model that reliably does the job rather than always reaching for the biggest one.

rough mental model — check current docs for exact specs
Opus    # the most capable — hardest reasoning, highest-stakes work, slower & pricier
Sonnet  # the default workhorse — strong reasoning at a much better speed/cost balance
Haiku   # the fastest & cheapest — great for high-volume, low-complexity tasks

A useful way to decide: if a smart, careful junior colleague could do the task correctly on the first try without much thought, that's a Haiku-shaped task (classifying support tickets, extracting a field from text, simple rewrites). If it needs solid reasoning but isn't pushing the frontier of difficulty, that's Sonnet's job — most everyday coding, writing and analysis lands here, which is why it's the default across claude.ai and Claude Code. Reach for Opus when the cost of a wrong answer is high and the problem genuinely needs the deepest reasoning available — gnarly architecture decisions, subtle bugs, high-stakes analysis.

You'll revisit this decision with real numbers

This is a qualitative gut-check for now. Week 9 comes back to this with actual token pricing, latency tradeoffs and the batch API, once you've built things worth optimizing.

4. Three Surfaces, One Model

"Using Claude" can mean three quite different things, and this course covers all three because they solve different problems:

pick the surface for the job
claude.ai    # a chat interface + Projects/Artifacts — writing, research, analysis,
             # no code required. Covered in Weeks 2-5.

The API      # the Messages API + SDKs — build Claude into your OWN application,
             # with full control over prompts, tools & behavior. Weeks 6-9.

Claude Code  # an agentic CLI that reads, edits & runs code in YOUR repo, with
             # your permission at each step. Weeks 10-12.

They're not competing products — they're the same underlying model wired into three different feedback loops. claude.ai is optimized for a human having a conversation. The API is optimized for your code calling Claude programmatically, with no chat UI in the loop at all. Claude Code is optimized for an agentic loop over a codebase: Claude proposes an edit or a command, you (or your configured permissions) approve it, and the loop continues. Picking the wrong surface for a task is a common source of frustration — trying to do agentic multi-file refactoring through claude.ai's chat box is possible but painful; that's what Claude Code is for.

A simple rule of thumb for this course

If a human is driving and it's mostly text in, text out — claude.ai. If your own software needs to call Claude and act on the response — the API. If you want Claude working directly inside your codebase, running commands and editing files — Claude Code.

5. Hands-on Exercise

Hands-on

Feel a context window fill up, and compare models on the same task

You've read about tokens and model tiers — now go make them visible with a free claude.ai account.

Part 1 — Watch the context window in action:

  1. Start a new chat and paste in a long article or a few chapters of a public-domain book (2,000+ words).
  2. Ask Claude to summarize it in three bullet points, then ask three follow-up questions about specific details near the very start of the text.
  3. Keep the conversation going with unrelated follow-ups for 15-20 more turns, then ask about that same early detail again. Note whether the answer is still as sharp — and why that would or wouldn't surprise you now.
Hint

Claude's actual context window is large enough that a single article rarely pushes it out — this exercise is about building intuition for the mechanism, not necessarily triggering a failure. If you want to see a harder limit, try pasting something much longer, like an entire novel.

Part 2 — Compare model tiers on the same prompt:

If your account gives you a model picker, run the exact same prompt against two different tiers and compare.

  1. Pick a moderately hard task — e.g., "review this paragraph of code for bugs" or "explain the tradeoffs between two architecture options" — something with real substance.
  2. Run it once on the fastest/cheapest tier available to you, and once on the most capable tier, with the exact same wording.
  3. Compare depth, correctness and how each handles edge cases. Write one sentence on where the gap actually showed up (or didn't).

6. Knowledge Check

Four quick questions. Expand each to check your answer.

Q1

At its core, what is a large language model doing when it generates a response?

It's repeatedly predicting the most likely next chunk of text (token), given everything written so far, and appending it — one token at a time until it produces a stop signal. Complex-seeming behavior emerges from that simple loop applied at massive scale.

Q2

What is a context window, and what happens when a conversation exceeds it?

The context window is the maximum number of tokens a model can process at once (conversation history + attachments + the response being generated). Once you exceed it, older content typically has to be dropped or the request fails — this is why long chats can seem to "forget" early details.

Q3

You need to classify 50,000 short support tickets into five categories, cheaply and fast. Which Claude tier fits best, and why?

Haiku. It's a high-volume, low-complexity task — a smart junior colleague could do it correctly without much thought — so the fastest, cheapest tier is the right fit rather than paying for reasoning capability the task doesn't need.

Q4

You want Claude to refactor a function across 12 files in your repo, running tests as it goes. Which surface — claude.ai, the API, or Claude Code — fits, and why?

Claude Code. It's an agentic, multi-file, run-commands-and-verify task against a real codebase — exactly the loop Claude Code is built for (read, edit, run, verify), versus claude.ai's single-conversation chat loop or the API's build-your-own-application role.