How LLMs
really work

An LLM is a function. Text goes in; out comes a probability for every possible next token — every word-fragment it could emit. That is the whole interface. It was built by reading a huge slice of the internet and being scored on one task and one task only: predict what comes next.

Everything you have ever seen an LLM do — hold a conversation, write code, "reason" through a problem, apologise for a mistake — is that single function called in a loop. Predict a token, append it to the input, feed the whole thing back in, predict again. Nothing else happens.

And there is no conversation inside the machine. This one is load-bearing, so take it at the surface: your client formats the whole exchange into a single long text transcript — system rules at the top, each turn fenced by special marker tokens — and hands it over. The model continues the document. The helpful assistant you are talking to is a character the transcript establishes, played by a text-continuer that has read a great many documents in which helpful assistants appear. Level 3 explains how it learned the part; its widget makes it visceral.

"Autocomplete on steroids" — honest, and where it breaks. Honest: the training objective is mechanically identical to your phone keyboard's suggestion strip. Where it breaks is scale. Predicting the next token extremely well across all of internet text is not a shallow trick — it requires internalising grammar, facts, idioms, code semantics, the shape of an argument, because all of those are statistical regularities of text. Prediction pressure at sufficient scale forces something that behaves like understanding.

Note the phrasing: behaves like. That is a claim about observable behaviour, not a metaphysical position, and this guide will not smuggle in a stronger one. The abyss brings actual evidence from interpretability research and gives the open question a fair hearing in both directions.

Here is the loop with the real vocabulary attached:

1. Your prompt is split into tokens — chunks averaging about four characters, roughly three-quarters of an English word. The vocabulary is a fixed list, typically 50,000–200,000 entries, decided before training and frozen forever after.
2. One forward pass through the network produces a raw score — a logit — for every token in that vocabulary. softmax turns those scores into a probability distribution that sums to 1.
3. A sampler picks one token from the distribution. temperature and its friends decide how adventurously.
4. The chosen token is appended to the input and the loop repeats — until a special stop token is the one that gets picked.

while not done:                          // this loop is the entire product
    logits = model(tokens)               // ONE forward pass → a score for EVERY token in the vocab
    probs  = softmax(logits / T)         // T = temperature: reshape the distribution, don't re-rank it
    tok    = sample(probs)               // pick one — the only randomness in the whole system
    tokens.append(tok)                   // the output becomes part of the next input
    done   = (tok == STOP)               // a special token ends the turn

// no draft, no hidden state between calls. that's the machine.

That is worth doing rather than reading. Below is the loop as a sandbox: two prompts, the live distribution over candidate tokens, and a temperature slider. Sample your way to a sentence, then do it again and watch a different one come out of the identical machine.

Five consequences fall straight out of those four steps, and each one shows up in your work:

Tokens, not letters. The model cannot see the individual characters inside a token — a token arrives as one indivisible vector. That is why counting the r's in "strawberry" is famously hard, why billing is per-token, and why the same paragraph in a language the tokenizer handles badly can cost several times more to process. (The full story is the tokens & embeddings dive, next in this series.)

The weights are frozen. Nothing about your conversation trains the model. When it "remembers what you said earlier," the transcript containing what you said was re-read from the top on this call. Re-reading is not learning.

The context window is the entire working memory. Everything the model knows about you, your codebase, or this conversation must be physically present in the window on every single call. Outside the window there is no cache, no summary, no residue. There is nothing.

Temperature is why the same question gets different answers. Sampling is deliberate randomness. Turn temperature down toward zero and step 3 degenerates to "always take the top token" — near-deterministic. Turn it up and long shots get through. So "it's random" and "it's deterministic" are both half-true, and you now know which half you're holding.

One forward pass per token. A long answer costs proportionally more time than a short one, and responses stream in word by word because that is the generation cadence. Streaming is the machine's heartbeat, not a UI affectation. (→ the inference dive.)

Stage 1 — pretraining, where everything it knows comes from. Next-token prediction over trillions of tokens of web text, books and code, for months, across thousands of GPUs. (Llama 3's corpus, one of the few public figures, was around 15 trillion tokens.) This is the overwhelming majority of the cost and the only source of raw capability — every fact, every idiom, every API signature the model appears to know was pressed into the weights here.

What comes out is a base model: a pure text-continuer with no chat instinct whatsoever. Hand one the prompt What is the capital of France? and a perfectly likely continuation is more exam questions — because documents containing that line tend to be quizzes, and the model is doing exactly what it was trained to do. Base models are alien: erudite, capable, and utterly unhelpful.

The law that built the industry. Before the assistant story, one detour, because it answers "why did this get good so fast after 2020" better than anything else. Make the model bigger, feed it more data, spend more compute, and prediction loss falls along a smooth, boringly predictable power law — no architectural cleverness required. Kaplan et al. measured it in 2020; the Chinchilla work (Hoffmann et al., 2022) refined it, showing that for a fixed compute budget there is an optimal balance between parameters and data — roughly 20 training tokens per parameter, far more data per parameter than the field had been using.

The consequence is economic, and it is the whole story. Capability became forecastable before the money was spent. A lab could price a target loss in dollars and compute, which turned training runs from research gambles into budgetable engineering bets — at budgets public estimates put in the nine figures for frontier runs — and set off the scale race. Two honest caveats: the law predicts loss, and specific abilities sometimes appear jumpily even as loss falls smoothly (the "emergence" debate — Wei et al., 2022 for the claim, Schaeffer et al., 2023 for the argument that it is a measurement artifact; genuinely unsettled). And why power laws hold at all remains an open research question. Nobody planned this. It was measured. (Data curves and compute-optimality in full: the training dive, later in this series.)

Stage 2 — SFT, teaching the costume. Supervised fine-tuning continues training on a comparatively tiny, curated set of transcripts in chat format: a prompt, then a good assistant response. This teaches the format — turn-taking, the assistant persona, answering rather than continuing. It teaches almost no new knowledge; the knowledge was already in the weights. SFT just tells the predictor which of the many characters it can imitate is the one to play here.

Stage 3 — preference tuning, teaching taste. Sample several candidate responses to the same prompt, have humans (or AI raters standing in for them) rank them, and optimise the model toward the preferred ones — either through a learned reward model plus reinforcement learning (classic RLHF, as in InstructGPT, Ouyang et al., 2022) or directly against the preference pairs (DPO, Rafailov et al., 2023). This is where tone, helpfulness, refusals and "the vibe" come from.

Hold one thought from that paragraph, because the next level is built on it: optimising for human approval is, in part, optimising for agreement.

// what you send — a structured array of messages
messages = [
  { "role": "system",    "content": "You are a helpful travel assistant." },
  { "role": "user",      "content": "Capital of France?" },
  { "role": "assistant", "content": "Paris, of course." },
  { "role": "user",      "content": "And of Japan?" }
]

// what the model sees — ONE flat string, re-sent from token zero on every call
<|system|>You are a helpful travel assistant.<|end|>
<|user|>Capital of France?<|end|>
<|assistant|>Paris, of course.<|end|>
<|user|>And of Japan?<|end|>
<|assistant|>                       // ← the model's whole job: continue from here
                                    //   (exact marker syntax varies per model family)

Step through it and watch the document grow — including the moment the second call re-sends everything:

The stateless replay. Every API call replays the entire conversation from token zero. The model is a pure function of the transcript: same transcript in, same distribution out, with no server-side memory of the last call. Readers of the event sourcing guide will feel the déjà vu immediately — the conversation is an event log, and the reply is a projection folded from it. Same architecture, different industry.

That also quietly explains two things people find mysterious. Long chats get slow and expensive because every turn re-pays for the whole history. And "the model forgot what I told it" almost always means the window filled up and the client trimmed the oldest turns — the transcript lost them, so they stopped existing.

This is the level that makes the difference between using these systems and being effective with them. Each failure below gets its derivation, because a failure you can derive is a failure you can plan around.

1 · Hallucination is the default, not a malfunction. The machine's contract is "emit plausible next tokens," always. There is no null, no NotFoundException, no branch where the loop declines to produce a distribution. Plausible and true correlate strongly — that correlation is the entire reason the thing is useful — but they are not the same quantity, and wherever the weights hold no strong signal, plausibility runs unopposed.

Post-training makes it worse before it makes it better. Rating regimes have historically rewarded confident answers over abstention: a well-calibrated hedge often scores worse with human raters than a fluent guess, so the optimisation pressure points away from "I don't know." The consequence for you is blunt: treat unverified output as a draft, never a source. And prefer grounding — putting the actual facts into the context window — over instructing the model to "be accurate," which asks the wrong layer to fix the problem.

2 · Fluency is uniform; confidence carries no signal. The prose reads equally assured whether the distribution underneath it was a 98% spike or a coin flip, because confident prose is what training text looks like. Nothing in the loop converts a flat distribution into hedged wording unless post-training specifically taught that, and it is hard to teach well. Consequence: tone tells you nothing. Allocate your verification effort by the stakes of being wrong, never by how sure the answer sounds.

3 · Sycophancy. This one is a direct derivation from stage 3. The model was optimised on human approval, and approval correlates with agreement. Push back on a correct answer and watch it fold — not because you were right, but because folding is what scored well. (Anthropic's Sharma et al. measured the effect across several assistants in 2023.) Consequence: "the model agreed with my design" is not validation. Ask for the strongest case against your plan, or give it an explicit critic role. Handing it your preferred answer and asking what it thinks is asking a trained approval-maximiser to approve.

4 · Prompt injection — the security consequence of Level 1. There is exactly one channel into the machine: tokens. Instructions and data travel in the same stream, and the role markers that appear to separate them are learned convention, not enforced mechanism. Nothing in the architecture makes "text to obey" and "text to merely read" different kinds of thing — they are the same kind of thing, differing only in how reliably training taught the model to treat them differently. (Simon Willison named the problem in 2022; it has resisted a clean fix ever since.)

Four smaller myths, each dissolved by the same mechanics:

Thinking models — the scratchpad, institutionalised. That last clause deserves its own treatment, because it is the mechanism behind an entire product category.

Start with the constraint. Beyond one fixed-size forward pass, generated tokens are the only working memory the model has. There is no scratch register that persists between passes and no place to stash an intermediate result. So making the model write its intermediate steps out loud literally buys it two things: more total compute (many passes instead of one) and a scratchpad it can read back (the tokens are now in the context). That — not any kind of exhortation — is the entire trick behind "think step by step."

A thinking model is that trick trained in rather than prompted. The model generates a long thinking phase first — drafting, checking, visibly backtracking, all in ordinary text — and only then the answer. It learned the habit through reinforcement learning on problems with mechanically checkable answers, mostly maths and code: whatever scratchpad behaviour led to correct answers got reinforced. OpenAI's o1 (September 2024) and DeepSeek-R1 (January 2025) are the public exemplars, and R1's paper is notable for documenting the behaviour emerging from the RL rather than being scripted in. The framing that matters: same loop, same tokens. A thinking model is not a different kind of machine; it is the same predictor with a trained pre-answer phase.

For you that is a new knob — test-time compute. You can trade latency and token spend for accuracy on a per-request basis, and trade back for cheap requests. It pays on multi-step problems and barely moves single-hop lookups, so routing matters. One honest caveat: the visible thoughts are generated text, not a guaranteed readout of the underlying computation. Models can reach an answer by one route and narrate another — the chain-of-thought faithfulness problem (Turpin et al., 2023, and a live research area since). Read the thinking as a useful artifact, not a log. (The training recipe in full: the training dive. The cost model in full: the inference dive.)

Pods 1–4 are the rest of this series: one dive per component of the machine. Pods 5 and 6 are complete in themselves — the engineering disciplines that grew above the model, and what has actually been found inside it.