The next-token machine

Each word in large language model contributes something useful:

• Model means a mathematical system that represents patterns learned from examples. It is not a database of approved answers.
• Language model means its central task is assigning probabilities to sequences of tokens: which continuations fit the preceding context?
• Large usually refers to scale: many adjustable numerical parameters, substantial training data, and significant computation. “Large” has no single permanent cutoff.

The model receives text as tokens, converts those tokens into numerical representations, processes relationships among them, and produces scores for possible next tokens. During ordinary generation, its weights are fixed. It uses what training placed in those weights, plus the current prompt and conversation context.

Calling the system a “model” matters. A map models a city without containing the city. In the same way, an LLM captures useful regularities in language without containing a neat copy of every source used during training.

Suppose the prompt is:

The opposite of hot is

The model might assign high probability to cold, lower probability to cool, and tiny probabilities to many other tokens. If it chooses cold, the context becomes:

The opposite of hot is cold

It then predicts again. A period may now be likely. After choosing the period, it predicts what follows that. Generation ends when the model produces a stopping token or reaches a configured limit.

One prediction may look trivial. Thousands of linked predictions can form a structured answer because each new choice is conditioned on everything still available in the context. Headings make later headings likely; an opening quotation mark affects where a closing one belongs; a function signature constrains likely code inside the function.

A token is a chunk the model processes. A common word may be one token, while a rare word may split into several. Punctuation, spaces, and parts of code can also be tokens. The exact split depends on the model’s tokenizer.

For illustration only, a tokenizer might divide:

unbelievable! → un + believ + able + !

This helps explain several practical facts:

• Model limits are measured in tokens, not pages.
• A short-looking code sample may use many tokens.
• Spelling and character-count tasks can be awkward because the model usually operates on chunks, not individual letters.
• Pricing for hosted models is often based on input and output token counts.

Tokens are a representation choice, not little ideas. A token does not carry one fixed meaning by itself; its useful representation depends on surrounding tokens.

Compare these prompts:

1. “Write about bats.”
2. “For a biology class, write about bats.”
3. “For a baseball beginner, explain how to hold bats.”

The word bats alone is ambiguous. Nearby instructions shift the likely continuation toward animals, sports equipment, or a clarification. The model’s context includes the current prompt, relevant earlier messages, and sometimes system-provided instructions or retrieved material.

Context is temporary working material. It does not automatically become a permanent memory, and it does not change the model’s weights during a normal request. A later lesson will separate context, training, and external retrieval more carefully.

To predict text well across many domains, a model must capture a great deal of structure: grammar, style, common facts, relationships between concepts, code patterns, and conventions for following instructions. A recipe continues differently from a legal clause. A Python error message suggests different next steps from a poem.

These learned patterns can support behavior that looks like classification, translation, explanation, or planning. Yet the mechanism gives no guarantee that an answer is true. A false statement can be a statistically plausible continuation. Fluency is evidence that the model learned language patterns, not proof that it checked the world.

It is useful to say an LLM “answers” or “reasons” as shorthand for observable behavior. It is unsafe to jump from that shorthand to claims about human-like understanding or consciousness. The system produces outputs from numerical computation over tokens; questions about subjective experience are separate and unresolved.

Keep this four-part loop:

1. Turn the available text into tokens.
2. Compute a probability-like distribution over possible next tokens.
3. Choose one token using a decoding rule.
4. Append it and repeat.

Real systems add instruction tuning, safety controls, tools, retrieval, and interfaces. Those layers matter, but they do not replace the basic generation loop. When an answer surprises you, ask: “What context made this continuation likely, and what evidence—if any—was available to keep it accurate?”