How a model turns your words into an answer
By the end of this you will know what a language model receives, what it hands back, and why that one shape explains nearly everything people find strange about these systems.
Twenty figures carry most of the argument, so let one finish a cycle before moving on. Each says on its own face whether its numbers were chosen to show a shape or calculated in front of you. The main thread needs no mathematics; the folds marked Deeper are optional.
A model only ever answers one question
Everything a language model does is a single operation, run over and over.
Put any text in front of a language model and it does one thing. It reads the text and produces a guess at what comes next. Not a sentence, not a paragraph, not an answer. One piece of text, usually shorter than a word.
That guess is stuck onto the end of the text, and the whole thing goes back in. The model reads the longer text and guesses again. A few hundred of those in a row is the reply you see appear.
Drawn as a line it looks like a sequence of events. It is closer to a wheel, and the wheel is why one model can write code, summarise a contract and translate Portuguese without anyone having built three systems. Those are not three features. They are the same turn of the same wheel, on text that happens to look like code, a contract, or Portuguese.
The model works out its answer, then writes it down.
There is no plan sitting anywhere. At the moment a model produces the word "three" in "there are three reasons", nothing in it has committed to what those three reasons will be. They get worked out on later passes, from the text, because the text is all there is.
That cuts both ways, and usefully. It is why asking a model to work through something on the page changes its answers rather than just their length. The working becomes text, and the text is read on the next pass. Writing is the only scratchpad it has.
Deeper: the models that think before they answer
Some models now produce a long stretch of working before showing you anything. That is not a different mechanism. The working is tokens, generated by the same loop, and the product simply does not display them. The scratchpad is still text; it is text you were not shown.
There is real machinery that stops the model recomputing the entire sequence on every pass, usually called a key value cache. It is an optimisation over the same arithmetic and it does not give the model a plan that survives outside the text.
A language model predicts one token at a time, and every prediction is made by reading the whole text again from the start.
Text arrives in pieces, and the pieces are not words
Before anything else happens, your sentence is cut up and turned into numbers.
A model cannot receive letters. Your sentence has to become numbers first, and the step that does it is called tokenisation. It cuts the text into pieces somewhere between a letter and a word, drawn from a fixed list built once before training and never changed afterwards.
This is where a whole family of failures comes from, the ones that look like stupidity and are not.
The other consequence is money. Tokens are the unit everything is priced and rate limited in, and the same meaning does not cost everybody the same number of them.
Deeper: why a fixed vocabulary, and why it cannot be changed later
Byte pair encoding starts from single bytes and repeatedly merges the most frequent adjacent pair until the list reaches its target size. Frequency buys brevity, and that is the whole of the cost difference above: the merges were learned from a corpus, so text resembling that corpus compresses better.
It is also why the vocabulary cannot be swapped after training. Every entry is bound to a row of learned weights, so changing the list means training the model again.
The model receives numbered pieces of text, never letters, and which pieces exist was decided before training began.
Each piece starts as a point, and the sentence moves it
Where meaning actually lives, and where it does not.
Every entry in the vocabulary owns a list of numbers learned during training. A few thousand of them, in most models, and not one of them means anything on its own.
But the row for "bank" is one row. It is identical whether you are talking about a river or a mortgage, because it was fixed long before your sentence existed. What changes with your sentence is what the model builds on top of it as the text passes up through the layers.
What does the pulling is the rest of the sentence, and not evenly. Most words barely matter and one or two decide the whole reading.
Deeper: cosine similarity, and the arithmetic people quote
The closeness in figure 3.1 is cosine similarity, the angle between two rows rather than the gap between them, which is why a rare word and a common one can still come out close.
The famous trick where king minus man plus woman lands near queen came out of older word vector work and holds only loosely, on carefully chosen examples. Take it as a sign that the space has structure, not as an operation you can build on.
A token's starting vector is fixed. Its meaning in your sentence is built above it, out of the tokens around it.
The output is a whole distribution, not a word
The most useful thing about a model's answer is something you are never shown.
When a pass finishes, what comes out is not a word. It is a score for every single entry in the vocabulary, all of them, every time, squeezed into probabilities that add up to one.
Eight bars is how this always gets drawn, and it is quietly misleading. The list is the whole vocabulary, and the part nobody draws is the part that decides what happens when there is no obvious answer.
And this happens again for every token, not once per answer.
Deeper: logits, softmax, and what a probability is not
The raw scores are called logits and they are unbounded, positive or negative. Softmax exponentiates each one and divides by the total, which turns any set of scores into a distribution that sums to one while keeping their order.
A high probability means the model found that continuation likely given its training. It is not a claim that the statement is true. Most APIs will return these numbers if you ask, and for classification work, reading the probability of each label directly is usually better than parsing a sentence the model wrote about its choice.
Every pass produces a probability for every token the model knows. A peaked distribution and a flat one are indistinguishable in the reply you actually read.
Choosing from the list is a separate decision, and it is yours
The setting that most people never touch and most often need.
The model produces the distribution. Something else picks a token out of it, and that something else is not the model. It is a short piece of code with settings on it, and the settings are usually yours to change.
Take the highest number every time and the same prompt returns the same answer forever. Draw at random instead, weighted by the probabilities, and you get variety. Temperature is the dial deciding how faithfully that draw follows the numbers.
The second dial is usually called top-p, and it does something different enough that confusing the two will cost you an afternoon.
Between them, these two settings account for most of what gets attributed to a model having a personality, or to having had a bad day.
Deeper: why identical settings can still give different answers
Temperature zero is not a guarantee of identical output in practice. Floating point addition is not associative, so the way a server batches your request alongside other people's can shift the last digits of a score, and two options that were nearly tied can swap places.
Models that route each token to a subset of their own components can be sensitive to what else is in the batch for the same reason. If you need reproducibility, you need it stated by the provider rather than inferred from a setting.
The model hands you a distribution. Temperature and top-p decide how that becomes a word, and they are settings rather than personality.
It only knows what is in front of it
There is no memory. There is a window, and it is re-sent in full every turn.
A model has no memory of you between requests. None at all. Every conversation that appears to remember what you said ten minutes ago works by sending all of it again, invisibly, as part of the text.
The frame has a size, called the context window and measured in tokens, and you are not the only claimant on it.
When a conversation outgrows the window something has to go, and different products choose very differently: drop the oldest turns, replace them with a summary, or keep a running set of extracted facts.
It remembers our earlier conversations.
Unless a product has explicitly built a memory feature, which stores things somewhere and pastes them back into later conversations on your behalf, a new chat starts with a model that has never encountered you. The sense of continuity is a file being sent again.
Talking to it does not change its weights. Nothing you say is learned by the model during your conversation, whatever else a provider may or may not do with the transcript afterwards.
Deeper: why a long window is not free
In the standard arrangement, every token is compared against every other token, so that part of the work grows with the square of the length. Doubling the text roughly quadruples it. A great deal of engineering now softens this, but the shape of the cost is why a very long window is an achievement rather than a number somebody chose.
Recall across a long window is also uneven. Published work has repeatedly found that material at the very start and the very end of a long context is used more reliably than material buried in the middle, so filling a window is not the same as being understood.
There is no memory. There is a window, it is re-sent in full every turn, and what falls out of it is your application's decision.
Why it invents things, stated precisely
The behaviour people complain about most is the behaviour the first six lessons predict.
The model produces a distribution and something draws from it. For a fact it met thousands of times in training, the distribution is a spike and the draw lands on the right token. For a fact it met twice, or never, the distribution is flat across a handful of plausible looking options, and the draw lands on one of them anyway. There is no branch in the code that checks whether it knows.
The obvious next question is whether the model can tell. Partly, and less than you would want.
So the dependable fix is not a better instruction, because an instruction cannot create knowledge that was never there. It is putting the material into the request.
Deeper: what confidence is actually worth
The probability on the chosen token carries real information, and low probability answers are wrong more often, so a system that can read those numbers can act on them. There is also published work showing that a model's internal activations separate true statements from false ones better than its own stated confidence does.
But a model asked how sure it is produces that reply the same way it produces everything else, by predicting likely text, and training on human feedback rewards answers that sound confident. So its stated confidence is worth considerably less than its measured confidence, and neither is a guarantee.
A confident sentence about something the model never learned looks exactly like a confident sentence about something it did. The difference lives in a distribution you were never shown.
Test yourself
10 questions, and 70 percent passes. The score stays in this browser and goes nowhere else, so there is no account to make and nothing at stake in getting one wrong.
Attention, and how a model decides what matters
Course one treated the model as a box that turns text into a distribution. This one opens the box. What a layer does, why every token gets to look at every other token, and how a pronoun four hundred words later still lands on the right name. It is also where the costs come from, so it explains why context windows are expensive rather than just large.
In production. The track page has the full plan.