What it is actually doing when it answers you

The only operation there is

A large language model does one thing. Given a stretch of text, it works out a probability for every possible next fragment, picks one, adds it to the end, and runs the whole calculation again. That loop, a few hundred times over, is the letter it drafted for you.

Nothing else is happening. There is no separate part that checks facts, no lookup step, no moment where it decides whether it knows. Understanding this is not academic curiosity. It tells you precisely which mistakes to expect, and it is the difference between a person who is surprised every week and a person who is never surprised.

It does not see letters

The model does not read characters. Text is first cut into tokens — common fragments learned from the training data. In English, a token averages about four characters, so 1,000 tokens is roughly 750 words. Common words are single tokens; unusual ones split. "Unhelpfulness" is likely three or four pieces.

Two consequences you will meet.

The first is the counting failure. Ask how many times the letter "r" appears in "strawberry" and a capable model may say two. It is not being careless. The word arrived as two or three opaque fragments, and the letters inside them were never separately visible. The same model can analyse a lease correctly and miscount a word, because those are different kinds of task on different objects.

The second matters more for cost. Tokenisers were fitted mostly on English text. The same sentence in Hindi, Tamil, Arabic or Amharic can consume two to four times as many tokens as its English translation, because the script fragments into smaller pieces. Since you are billed per token and the context limit is counted in tokens, working in your own language can cost several times more and fill the window several times faster for identical meaning. This is a real inequity, it is rarely mentioned, and it is worth knowing before you conclude that the tool is worse in your language than in English.

No memory, no clock, no calculator

Three absences follow directly from the mechanism.

No memory. Each conversation begins with nothing. When a product appears to remember you, a separate system has saved notes and is quietly pasting them back in at the top of every conversation. That is a feature bolted on, not a property of the model, and it can be switched off — which is worth knowing when the notes contain a client's name.

No clock. It has no access to the time unless the date is written into the hidden instructions the product sends with your message. Most consumer products do send it. Many do not. If you ask "is this contract still within its notice period" without stating today's date, you may be getting arithmetic based on a date it guessed.

No calculator. Arithmetic is produced the same way as prose — by completion. Small sums it has effectively memorised. Multiply two seven-digit numbers and accuracy collapses, in the same confident tone. Modern products often detect a sum and hand it to a real calculator or a snippet of code, which fixes it. Whether yours does is something you should test with a multiplication you can verify, not assume.

Where its knowledge sits

What the model knows is stored in its weights — billions of numbers fixed at the end of training. It is not a database. There is no row to inspect, no source to click, no field that says "confidence". You cannot ask it what it does not know, because there is no register of that anywhere in the system.

This is why the honest instruction throughout this course is that facts you did not supply are unverified. Not usually wrong. Unverified, which is a different and more useful category.

The same question, a different answer

Ask the same question twice and you often get two different replies. That is sampling: it is drawing from a distribution rather than reading out a stored answer. Some tools let you set a "temperature" of zero to take the most likely fragment every time, which reduces variation but does not eliminate it — the hardware itself is not perfectly reproducible when work is batched across users.

You can turn this into a tool rather than an annoyance, and a later lesson does exactly that: where two runs disagree is where the model is least certain, and that is where you look.

Watch it happen, for nothing

The clearest way to internalise all of this is to run a small model yourself. Ollama (free, Windows, macOS, Linux) will install and run a two- or three-billion-parameter model on an ordinary laptop with 8 GB of memory. llama.cpp does the same with less software around it. Hugging Face hosts free tokeniser demos in the browser, where you can paste a sentence and watch it cut into pieces — try one line of English and the same line in your own language, and read the two counts.

A small model fails in the same ways as a large one, only more often and more visibly. An hour with one teaches more about the shape of the failures than a month of reading about them.