Lesson 2: How LLMs Actually Work, from Tokens to Training to Reasoning Models

By the end of this lesson, you will be able to:

• Explain in plain language how an LLM produces text through next token prediction (K9)
• Describe what pre-training and post-training each contribute to a model's behaviour, and what neither contributes (K9)
• Distinguish between a standard model and a reasoning model, and identify which is more appropriate for a given task (K9, K25)
• Identify at least three practical implications of LLM behaviour for the design of AI automation (K9)
• Stress-test your Evidence Companion's guardrail against fabrication, and explain the result in terms of next-token prediction (K9)

Why model literacy matters for a practitioner

You do not need to know how a car engine works to drive one. You do not need to know how the network stack works to send an email. If you are designing automation that depends on an LLM at its core, however, that changes. Knowing roughly how the model produces its output shapes every decision you make about prompt design, validation, oversight, and model selection.

The aim of this lesson is not technical depth. The aim is enough understanding that you can explain to a colleague why their idea will or will not work, recognise when a model is operating outside its competence, and design automation that takes the model's limitations seriously rather than assuming them away.

A practitioner who can describe what happens between "I send a prompt" and "I receive a response" is the practitioner who builds automation that survives contact with the real world. This lesson will give you the vocabulary you need.

Next token prediction: the core mechanism

What does an LLM actually do when it produces text? At its most basic level, it predicts the next most likely token (roughly, the next word or word fragment) given everything that came before. Then it predicts the one after that. Then the one after that. Until the model decides it is finished.

🔑 Token: the basic unit a language model reads and writes. A token is roughly a word, but not exactly. As a rough rule of thumb, one token averages about three-quarters of a word (so 100 tokens is roughly 75 words; see OpenAI's guide to tokens and how to count them). "The" is one token. "Unbelievably" might be three. Punctuation marks are tokens. Spaces are absorbed into surrounding tokens. Models think in tokens, not words. This is why providers price per token and limit context length in tokens rather than in characters or sentences.

Optional — go deeper on tokens

Tokens exist because subword units handle rare words, typos, and new terms far better than whole-word vocabularies. If you want to understand exactly how tokenisation is calculated — including why the same string can split differently across models — this guide walks through it step by step.

Imagine you have asked an LLM "What is the capital of France?". Here is what happens, simplified to the essentials. The model receives your input as a sequence of tokens. It calculates, for every possible next token in its vocabulary, how likely that token is to come next given everything before it. "Paris" has a very high probability, because the question setup makes "Paris" the most likely continuation. The model then picks a token, not always the highest-probability one — a controlled randomness setting means the top candidate is sometimes skipped in favour of a lower-probability one. That is what stops the model sounding mechanical. Then it predicts what should come after "Paris", probably " is" or ".", and the cycle continues until the model produces a stop token and the response ends.

Click to enlarge

That is the entire mechanism. There is no database lookup. There is no thinking in any human sense. The model is producing text that statistically fits the patterns it learned during training.

🔑 Temperature: the setting that controls how predictable or varied a model's output is. At zero, the model always picks the highest-probability next token, making responses consistent and repeatable. Higher values introduce more randomness, producing more varied — and sometimes more creative — responses. In everyday tools such as Claude.ai, Microsoft Copilot, or ChatGPT, temperature is fixed by the provider and cannot be changed. You will encounter it as a configurable setting when calling a model via an API, or when building automation in platforms such as Make.com or n8n.

Same input, different output. Because temperature introduces randomness, the same prompt run twice can produce different responses. This is by design, because it makes responses feel natural rather than robotic. It is also why LLMs inside automation need either temperature set to zero (for predictability) or validation logic to catch unwanted variation.

The model does not know what it does not know. The next-token-prediction mechanism produces text that fits the pattern of an answer, whether or not the model has the underlying knowledge to back it up. This is why LLMs sometimes generate confident-sounding but factually wrong answers, the behaviour commonly called hallucination. The mechanism that lets the model fluently complete "the capital of France is" also lets it fluently complete "the capital of Wakanda is" with something equally fluent and entirely fictional. Telling the difference is our job.

This is exactly what your Evidence Companion's guardrail exists to catch. You already told it, in Lesson 1, never to invent facts, achievements, or evidence you have not given it — now put that instruction under real pressure and see whether it holds.

[TRY IT NOW — 5 minutes] Stress-test your Companion's guardrail

Open the Companion you built in Lesson 1. Give it a nudge toward fabrication — ask it something that invites a confident-sounding guess, such as a made-up detail about your project it was never given, or a question phrased as if the answer is already agreed ("summarise the results I got last week," when you gave it no such results). Watch closely: does it push back, ask for the missing evidence, or does it fluently fill the gap the way the "capital of Wakanda" example did above?

Optional — go deeper on how words become numbers

Next-token prediction is the visible mechanism, but three things are happening underneath it. First, tokens break your text into digestible fragments (above). Those tokens are then turned into embeddings — long lists of numbers that place each token in a "meaning space," so words with similar meanings end up with similar coordinates (you met embeddings in Module 1). Finally, the model's parameters — the hundreds of billions of values it learned during training — do the actual reasoning, and this is where one model differs from another. Part of that machinery is the attention mechanism: where an embedding gives a word its base meaning, attention dynamically updates that meaning based on the surrounding words. It is how the model tells the "apple" in "the apple fell from the tree" from the "apple" in "the new Apple phone launched" — the same token, a different meaning in context.

📺 Optional watch — a short visual explainer of how these pieces fit together. Why it helps your prompting: because attention reads a word's meaning from the words around it, the context and wording you put into a prompt directly shape how the model interprets your request. Understanding that is what turns prompting from trial-and-error into deliberately giving the model the context it needs to land on the answer you want.

Pre-training: where general knowledge comes from

Pre-training scale is hard to grasp on first encounter. If the concepts don't land immediately, slow down and read this section twice. The analogy to the car engine is intentional: you don't need to understand every detail, but the scale of what the model has seen is the thing that makes the knowledge cutoff and bias implications real.

Pre-training is the step where the model learns to predict tokens by being shown enormous amounts of text. The scale is the part that takes some getting used to. We are talking trillions of tokens of training data: books, websites, code repositories, scientific papers, public forums, encyclopedias. The model adjusts its internal parameters (hundreds of billions of them, in a frontier model) until it can predict the next token in any of these texts with reasonable accuracy.

The cost of pre-training a frontier model is on the order of tens of millions of pounds in compute. It takes thousands of specialist chips running for weeks. This is why only a handful of organisations train these models from scratch. Everyone else uses the models those organisations release.

Three consequences of pre-training matter for practitioners.

Knowledge cutoff. Pre-training data has a date after which the model knows nothing. If your use case depends on current information (recent news, this month's pricing, last week's policy change), the model needs to be paired with a tool such as web search or a live database lookup that brings in fresh data. Otherwise, you will receive answers based on the world as it was when training stopped.

Data biases. What the model knows reflects what its training data emphasised. Models tend to be stronger in English than in less common languages, stronger on topics that were heavily represented online than on niche industry knowledge, and stronger on the dominant view of contested topics than on minority views. None of this is malicious. It is a property of training data scaling, and it shows up in subtle ways in the outputs your automation will produce.

No proprietary knowledge. A model trained on public data does not know anything about your organisation's internal documents, processes, customers, or pricing. If your automation needs the model to reason about company-specific information, that information has to be in the prompt at runtime, or retrieved by a tool at runtime. The model itself does not carry it, and no amount of clever prompting will make the model produce knowledge it never saw.

Post-training: where instructions, personality, and safety come from

A pre-trained model is a powerful next-token predictor, but it is not particularly useful by itself. Left as-is, it will complete any prompt with whatever statistically fits, including completing unsafe requests, producing rambling outputs, or treating an instruction as text to continue rather than as something to act on.

Post-training is where the model is shaped from a general predictor into an assistant. Several techniques contribute, but three are the most important to know about.

Instruction tuning is the process of showing the model many examples of instructions followed by helpful responses. After this stage, the model gets much better at recognising "this is a request" and producing a response, rather than continuing to write more text in the style of the request itself.

Reinforcement learning from human feedback (RLHF) is the technique where human reviewers are shown pairs of responses to the same prompt and asked which they prefer. The model is then trained to produce more responses like the preferred one. This is how models develop helpful personality traits, refusal behaviour for unsafe requests, and a sense of when to ask clarifying questions instead of guessing.

Safety training is the specific work done to make the model refuse harmful requests, avoid generating particular categories of unsafe content, and acknowledge uncertainty rather than hallucinate confidently. This is also why different models from different providers behave differently to the same edge-case prompts. They have been through different safety training regimes, with different priorities, by different teams.

Did you know?

This is why different LLMs feel like different colleagues with different working styles. Two models can have similar benchmark performance and still be useful for very different things, depending on how they were post-trained.

The practitioner implication is subtle but important. When you choose between Claude, GPT, or Gemini, you are not just choosing different pre-trained models with different capabilities. You are choosing different post-training philosophies. These post-training choices show up in the personality and reliability of the output, not just in headline benchmarks.

• Claude is post-trained with particular emphasis on careful reasoning and refusal nuance.
• GPT models are post-trained with broad capability and a large tool-use ecosystem.
• Gemini is post-trained for multimodal capability and tight integration across Google's product and developer ecosystem.

References (optional): The claims above draw on foundational academic papers. These cover earlier model generations — the specific models have since been superseded — but the post-training concepts they introduce still broadly apply.

• Constitutional AI: Harmlessness from AI Feedback — Anthropic, 2022
• GPT-4 Technical Report — OpenAI, 2023
• Gemini: A Family of Highly Capable Multimodal Models — Google, 2023

Reasoning models: a different mode

In 2024 and 2025, a new category of LLM emerged, often called reasoning models or thinking models. As of mid-2026, every major provider has one. OpenAI offers GPT-5.5 with reasoning mode and the o-series. Anthropic offers Claude Opus 4.7 and 4.8 with extended thinking. Google offers Gemini Deep Think. DeepSeek R1 is the most prominent open-weight option — meaning its model weights are publicly released so organisations can download and run it on their own infrastructure rather than calling a third-party API.

The difference is in how these models handle a request. A standard model receives your prompt and starts producing the response token by token. A reasoning model first generates an internal thinking pass, sometimes hundreds or thousands of tokens of working out, before producing the visible response. The thinking pass is hidden from the user by default and is where the model considers possibilities, checks its own reasoning, and refines its approach before committing to an answer.

Reasoning models are markedly better at multi-step problems: mathematics, complex code generation, scientific analysis, multi-constraint planning, and any task where one wrong step early on cascades into a wrong final answer. They are also significantly slower and more expensive per request, sometimes by a factor of five to ten.

Click to enlarge

The choice between standard and reasoning is not a single right answer, it is a design decision per task.

Use a reasoning model when the task has multiple constrained steps, when errors at one step would invalidate the rest, when quality matters more than speed, and when the user or downstream system can wait thirty to sixty seconds for a response. Use a standard model when the task is single-step or conversational, when response time matters (user-facing chat, real-time automation), when the cost difference matters at scale (high-volume runs), and when standard-model quality is good enough for the job.

Many production systems use a router pattern: a fast, cheap standard model handles routine queries and decides when to escalate to a reasoning model for the difficult cases. You will see this pattern appearing repeatedly in Unit 2 platform reviews.

Pick any task you have already done with AI in your current project — a draft, a summary, an analysis, anything. Using whichever tool you have access to (Claude, Copilot, or Gemini), run that task twice: once with the thinking or reasoning mode off, and once with it on. In Claude look for the extended thinking toggle; in Copilot look for Think Deeper; in Gemini look for the thinking toggle. Compare the two outputs in terms of quality, time taken, and what each missed or added. The exercise tells you more about your specific use case than any benchmark could.

Show and tell: the same prompt across three model modes

This show-and-tell artefact compares how three ChatGPT model modes respond to the same prioritisation prompt. As you read it, focus less on which answer is "correct" and more on how each mode reasons: what it scores, what risks it notices, what trade-offs it makes, and when extra thinking time changes the recommendation.

Practical implications for your automation

This is what model literacy actually changes about your design decisions. Five implications, each of which reappears in later modules.

Choose model deliberately. "Use AI" is not a design decision. "Use Claude Sonnet 4.6 for routine draft replies and escalate to Claude Opus 4.7 with extended thinking when the response needs validation against the supplier contract" is a design decision. Selection criteria become a real piece of your project planning, and the rest of this module is partly about helping you do that selection well.

Build validation steps. Because models can hallucinate confident-sounding wrong answers, automation that depends on LLM output usually needs a validation layer. That might be a structured output schema the model must conform to, a check against a known data source, a human-in-the-loop review step for high-stakes outputs, or a verification call to a second model. The exact shape varies by use case. The need is universal.

Mind the context window. Models have a maximum context length, currently between 32,000 and 1,000,000 tokens depending on the model. Long-running agents, document analysis tasks, and conversation-driven automation can hit this ceiling, at which point earlier context drops out of the model's view. Knowing this lets you design around it (chunking, summarisation, retrieval) rather than discovering it in production.

Plan for variability. Even with temperature set low, the same input will not always produce identical output. Automation needs to handle this by structuring outputs into machine-readable formats (JSON, structured tables) wherever the downstream step depends on a specific shape, by validating outputs against expectations, and by alerting a human when validation fails.

Match model to task in cost terms. A reasoning model running on every customer query is overkill. A budget model running on a query that needs careful multi-step reasoning is false economy. Cost and quality are real trade-offs and need to be reasoned about explicitly rather than defaulted into.

Quick Check

⏭️ Up next - Lesson 3: Knowing what an LLM does and what makes different models behave differently is half the picture. The next lesson turns that into a decision: which model does the reasoning inside your automation, when that choice is yours to make, and how the leading model families differ on cost, privacy, and capability.