Every AI assistant you have used runs on the same basic machine: a model that predicts the next piece of text. Once that one idea is clear, the fluency, the confidence, the hallucinations and the price all stop being mysterious. This course is about the machine, not about any one brand of it.
⏱ 6 min read
A large language model is a program trained to do one thing: given a stretch of text, predict what comes next. That is the whole job. Everything else — answering questions, writing code, summarizing a contract, holding a conversation — is that single capability pointed at different inputs.
The "large" part refers to two things. The model has a very large number of parameters, the internal numbers it adjusts during training, now commonly in the hundreds of billions. And it was trained on a very large amount of text, typically a substantial fraction of the public internet plus books, code and licensed material.
The response you read one word at a time was genuinely produced one piece at a time. There was no plan drafted first and no sentence held in mind. The apparent coherence comes from each prediction being conditioned on everything before it.
It is not a database. Nothing is stored and looked up. Facts that appear reliably do so because they appeared consistently in training, which is why common knowledge is solid and obscure detail is shaky.
It is not a search engine, unless it has been given one as a tool. On its own it is working from patterns learned months or years ago, not from the live web.
It is not a mind. It has no goals, no memory between conversations, and no awareness of being right or wrong. Useful metaphors — "it understands", "it thinks" — are shorthand, and leaning on them too hard is what leads people to trust output they should have checked.
Every assistant you have used — the chat box, the coding helper, the summarize button in your email client — is a product wrapped around this loop. The wrapper does real work: it holds the conversation history, injects a hidden system prompt setting the rules, sometimes searches the web and pastes results in, and formats what comes back.
That distinction is worth holding onto, because it explains why the same underlying model can feel markedly different in two products, and why "the AI can't do X" is often a statement about the wrapper rather than the model. It also means the skills in this course transfer. Learn how the machine behaves and you are not learning one vendor's interface.
⏱ 5 min read
Three pieces of vocabulary carry most of the practical consequences — what things cost, how much you can paste in, and why a long conversation starts to drift.
Models do not read characters or words. Text is split into tokens: common words are usually one token, longer or rarer words break into several, and punctuation and spaces count. For ordinary English, a useful rule of thumb is about four characters per token, or roughly 0.75 words per token.
This matters because tokens are the unit of billing and the unit of capacity. Every API price is quoted per million tokens, and every limit is counted in tokens.
Each token is converted into an embedding — a long list of numbers representing position in a space of meaning. Tokens used in similar contexts land near each other, so "invoice" sits closer to "billing" than to "bicycle". The model never manipulates words; it manipulates these coordinates. That is why it handles paraphrase and synonyms gracefully, and why it is weak at tasks that depend on the literal letters, like counting characters or reversing a word.
The context window is how much text the model can consider at once, measured in tokens. It is working memory, not storage, and it has to hold everything: the system instructions, the whole conversation so far, any documents you pasted, and the answer being generated.
Windows have grown enormously — from a few thousand tokens in early models to hundreds of thousands or more — but three consequences remain true at any size.
Each turn re-reads everything. The model is stateless between calls. A long chat is re-sent in full every time you press enter, which is why a long conversation gets slower and more expensive as it goes.
Overflow means loss. When a conversation exceeds the window, something has to go — usually the oldest messages. That is the real reason a model "forgets" what you agreed twenty minutes ago.
Big windows are not the same as good recall. Models reliably use material at the start and end of a long context, and are measurably weaker on detail buried in the middle. Pasting a 300-page document is not the same as the model having read it carefully.
Tokenizers are trained on text, and they are most efficient on what they saw most — which is overwhelmingly English prose. The same sentence in a less-represented language can take two or three times as many tokens, and so cost two or three times as much. Code, JSON and tables also run high because punctuation and indentation each consume tokens.
Practically: if you are processing documents at volume, measure the real token count rather than estimating from word count, and strip boilerplate before sending. Removing navigation, footers and repeated headers from scraped pages is often the single biggest cost reduction available in a document pipeline, and it improves the output too, because there is less noise competing for the model's attention.
⏱ 6 min read
Training happens in stages, and each stage produces a different part of the behavior you see.
The model is shown enormous quantities of text and repeatedly asked to predict the next token. Each miss nudges the parameters. Run that across trillions of tokens and the model is forced, as a side effect of getting better at prediction, to encode grammar, facts, style, reasoning patterns and a great deal of world knowledge.
This stage is where the cost sits: months of compute on large clusters, at a price only a handful of organizations can absorb. It is also where the knowledge cutoff comes from. A model knows about the world as of the date its training data ends, and nothing after that unless it is given a search tool or you paste it in.
A raw pretrained model is not yet useful. Ask it a question and it may continue with more questions, because that is a plausible continuation of a document containing a question.
The model is then trained on examples of instructions paired with good responses, which teaches the format of being an assistant: answer the question, follow the instruction, stop when done. This is fine-tuning — further training on a narrower, curated dataset. It is much cheaper than pretraining and it changes behavior far more than it adds knowledge.
Finally, human preferences are used to shape the model's responses. In the common approach, people compare pairs of answers, a reward model learns to predict those preferences, and the language model is optimized against it. This is where helpfulness, tone, refusal of harmful requests and a great deal of the assistant's personality are set.
Two useful things follow. First, much of what feels like the model's character is a training decision, not an emergent property. Second, alignment is also where some failure modes are introduced — notably a tendency toward agreeable, confident-sounding answers, because people rate those highly.
Deep Dive into LLMs like ChatGPT — Andrej Karpathy. A long, careful walk through pretraining, fine-tuning and alignment from a former Tesla AI director and OpenAI founding member. Worth the time if you want the full picture. Open on YouTube ↗
A closed model is reachable only through its vendor's API or app. An open-weight model has its trained parameters published, so you can download it, run it on your own hardware, and fine-tune it. Open weights are not the same as open source — the training data and code usually remain private — but they do mean no per-token fee, no data leaving your environment, and no vendor deprecating the model out from under you. The trade is that you supply the hardware, the operations and the expertise.
Labs rarely release one model. They release a family — a large flagship, plus smaller, faster, cheaper siblings. The small ones are usually produced through distillation: the large model generates training data that teaches a smaller model to imitate its behavior. The result is a model that handles most ordinary tasks nearly as well at a fraction of the cost and latency.
This is why "which model is best" is the wrong question for most work. On classification, extraction, summarizing and routine drafting, a small model is frequently indistinguishable from the flagship and an order of magnitude cheaper. Save the expensive one for work that genuinely needs it.
⏱ 5 min read
Nearly every model in current use is built on the transformer, an architecture introduced in a 2017 paper memorably titled "Attention Is All You Need". You do not need the mathematics, but the central idea explains a lot.
Earlier language models read text strictly in order, one word at a time, carrying forward a summary of what they had seen. Two problems: the summary degraded over long passages, and the strict ordering made training impossible to parallelize, which capped how big models could get.
Attention lets every token look at every other token and decide which ones matter for interpreting it. In "the invoice the client disputed was paid late", attention is what connects "paid" back to "invoice" rather than to "client", across the intervening words.
Crucially, this happens for all positions at once rather than in sequence. That made training parallelizable across thousands of chips, which is precisely what allowed models to grow to the scale that produced the current generation.
Attention in transformers, visually explained — 3Blue1Brown. The clearest visual explanation of the attention mechanism available. Twenty-six minutes, no mathematics background assumed. Open on YouTube ↗
Through the late 2010s and early 2020s researchers found consistent scaling laws: increase parameters, data and compute together, and performance improves predictably. That reliability is why so much money went into ever-larger training runs. It also produced the surprise of the era — capabilities nobody trained for, like translation or basic arithmetic, appearing once models passed certain sizes.
That curve has flattened. Simply making models bigger now yields less than it did, which is why recent gains have come from better data, better post-training, and from letting models spend more effort at the moment you ask rather than at training time. That last shift is the subject of module six.
Attention compares tokens against one another, so the work grows faster than the length of the input — roughly with its square in the basic form. A great deal of engineering has gone into softening that, but it is the structural reason long contexts are expensive and slower, and why "just paste everything in" has a real price attached.
Two design choices matter alongside raw size. Mixture of experts splits a model into many specialized sub-networks and activates only a few per token, so a model can hold an enormous number of total parameters while doing far less work on any single prediction — which is how several large models stay affordable to run.
Multimodality extends the same machinery beyond text: images, audio and video are converted into tokens too, letting one model read a screenshot, a chart or a scanned invoice. It is the same next-token prediction underneath, which means the same caveats apply. A model reading a photograph of a table can misread a figure as confidently as it can invent one.
No persistent memory between conversations, unless the product adds one by storing notes and re-injecting them. No ability to inspect its own weights or explain why it produced something — a stated explanation is itself generated text, not a readout. And no internal fact-checker. Those are product features or they are absent.
⏱ 6 min read
A hallucination is output that is fluent, confident and wrong: an invented statistic, a plausible citation to a paper that does not exist, a function in a library that was never written. It is the single most important failure mode to understand, because it does not look like a failure.
Go back to module one. The model produces a probability distribution over next tokens and samples from it. Nothing in that process checks anything against the world. The objective is a plausible continuation, and a confident fabrication is an extremely plausible continuation of a question.
When a model has seen a fact thousands of times, the path to the right token is heavily reinforced and the answer is reliable. When it has seen something once, or never, there is still a next token with the highest probability — and the model emits it in exactly the same tone.
There is also a training-side contributor. Research from OpenAI in 2025 argued that standard evaluation practice rewards guessing: a benchmark that scores answers as right or wrong gives zero for "I don't know" and a chance of points for a guess, so models are effectively trained to guess rather than abstain. The confident tone is not a bug in the model so much as a learned optimal strategy under how we grade them.
What does not work is asking the model whether it is sure. It will produce a plausible answer to that question too, and its stated confidence is only loosely related to whether it is right.
Alignment training rewards answers people rate highly, and people rate agreement highly. The predictable result is sycophancy: push back on a correct answer and the model will often fold, apologize and produce a worse one. Tell it your preferred conclusion and it will frequently find support for it.
This is dangerous precisely where you most want a second opinion. If you ask "is this contract clause a problem?" after signalling that you think it is fine, you have contaminated the answer. Two habits help: ask neutrally, without telegraphing what you want to hear, and when you disagree, ask it to make the strongest case for the opposite position rather than simply asserting it is wrong. Treating it as an adversary you are stress-testing an idea against, rather than an assistant you are seeking agreement from, consistently produces more useful answers.
⏱ 5 min read
The most consequential change of the last two years is not bigger models. It is models that do more work before answering, and models that can act rather than only write.
A standard model starts generating its answer immediately. A reasoning model first produces an extended internal chain of working — breaking the problem down, trying approaches, checking itself — and only then writes the response. You are usually shown a summary of this, or nothing at all.
This is test-time compute: spending more computation at the moment of the request rather than during training. On hard problems with verifiable answers — mathematics, competitive programming, multi-step logic — it produces large, real improvements.
The costs are equally real. Those hidden thinking tokens are billed like any other, so a reasoning answer can cost several times a standard one and take much longer. For summarizing an email, it is pure waste. The practical rule: reach for reasoning when the problem has a right answer and multiple steps, and for a standard model when it does not.
On its own a model can only produce text. Tool use (also called function calling) changes that: the model is given a list of available functions — search the web, run code, query a database, send an email — and instead of answering, it can emit a structured request to call one. Your software runs it and hands back the result, which the model then uses.
This is how an assistant cites today's news, does arithmetic reliably, or reads your calendar. It also neatly patches two of the weaknesses in this course: the knowledge cutoff and arithmetic. A model that can run a calculation does not need to predict the answer.
An agent is a model in a loop: plan, call a tool, look at the result, decide what to do next, repeat until the task is done or it gives up. This is what sits behind the current generation of coding assistants and the "do this task for me" products.
Agents are where the technology is most impressive and least reliable. Each step carries a chance of error, and errors compound across a long chain. They also act in the world, so a mistake can send an email or change a file rather than just produce a bad paragraph. The practical guidance is unglamorous: keep the loop short, make destructive actions require confirmation, log what it did, and run it against a copy before the real thing.
One underrated capability makes most automation possible: models can be constrained to return valid JSON matching a schema you define. Instead of prose you have to parse, you get fields you can drop straight into a database, a spreadsheet or the next step of a workflow.
If you are building anything that runs without a human reading each result — classifying support tickets, extracting fields from invoices, tagging content — specify the exact output shape rather than asking for a description and parsing it afterwards. Parsing free text is where homemade AI pipelines break, and it is entirely avoidable.
The useful question is not whether to involve a person but where. Put the checkpoint immediately before anything irreversible or externally visible: before an email sends, before a record is written, before a file is deleted. Everything upstream of that line can run unattended.
⏱ 6 min read
Prompting attracted an enormous amount of folklore, most of it wrong. There are no magic words. What there is, is context: the model can only work with what is in front of it, and most disappointing output traces back to a request that assumed knowledge the model did not have.
| Part | What it does | Example |
|---|---|---|
| Role | Sets vocabulary and depth | "You are reviewing this as a bookkeeper." |
| Task | One clear instruction | "Find anything that looks mis-categorized." |
| Context | The material and the situation | "Here is the transaction list. We are a 6-person web agency." |
| Format | The shape of the answer | "A table: date, amount, current category, suggested category, why." |
| Constraints | The guardrails | "Flag only items over $200. If unsure, say so rather than guessing." |
Show examples. Two or three samples of input paired with the output you want (known as few-shot prompting) teach format far better than describing it. If you want your tone, paste something you wrote.
Ask for the work on hard problems. "Work through this step by step" improves accuracy on multi-step questions with standard models. Reasoning models do this internally, so the instruction adds little there.
Split big jobs. One prompt per stage — extract, then analyze, then write — beats one prompt asking for all three, and you can see which stage went wrong.
Iterate. Treat the first output as a draft and say what to change. Refining in conversation is usually faster than rewriting the prompt from scratch.
Flattery, threats, offers of payment, and stacked superlatives ("you are a world-class expert genius"). Politeness is fine and costs nothing, but it is not a performance lever. Neither is any particular incantation you read about: if a phrase seems to help, test it twice before believing it, because run-to-run variation is large enough to invent evidence for almost anything.
Most tools distinguish a system prompt — standing instructions that apply to the whole conversation — from the message you type each turn. Anywhere you can set one, put the durable material there: who the assistant is for, house style, what it must never do, the vocabulary of your business. You then stop re-explaining your context in every message.
Once a prompt works, save it. A plain document of ten or fifteen tested prompts, each with a line on what it is for, is more valuable than any amount of prompt-engineering theory, and it is the thing that lets someone else on the team get the same result you did.
Diagnose before rewriting. Wrong facts usually means missing context, so supply the source. Wrong format usually means no example, so give one. Too generic usually means the request was generic. Confidently wrong on something specific means you are at the edge of what it knows — that is a verification problem, not a prompting one.
⏱ 5 min read
A model knows what was in its training data. It does not know your prices, your policies, your client history or anything published after its cutoff. There are three ways to fix that, and choosing correctly saves a great deal of money.
| Approach | How it works | Best for | Cost |
|---|---|---|---|
| Put it in the prompt | Paste the material with your question | One-off tasks, a handful of documents | Tokens only |
| Retrieval (RAG) | Search your documents, insert the relevant pieces automatically | A knowledge base that changes | Setup plus storage |
| Fine-tuning | Further training on your examples | Consistent format, style or classification | Training runs plus data prep |
RAG sounds technical and is simple in outline. Your documents are chopped into passages and each is converted into an embedding — those coordinates in meaning-space from module two — and stored. When a question arrives, it is embedded the same way, the closest passages are retrieved, and they are pasted into the prompt along with the question and an instruction to answer only from the supplied material.
The model is not trained on anything. It is simply handed the right pages at the right moment. That is why RAG is the default answer for company knowledge: documents update instantly with no retraining, you can show which source an answer came from, and it is the most effective hallucination control available, because the model has the real text in front of it.
Where it goes wrong is almost always retrieval rather than generation. If the search returns the wrong passages, the model answers confidently from the wrong passages. Debugging RAG means looking at what got retrieved before blaming the model.
Fine-tuning teaches behavior, not facts. It is the right tool when you need output in a very specific format every time, a consistent house voice, or reliable classification into your own categories — and when you have enough examples, typically hundreds rather than dozens.
It is the wrong tool for keeping a model current on facts, because every update means another training run. A common and expensive mistake is fine-tuning a model on company documents in the hope it will "learn the business". It will pick up the vocabulary and still get the details wrong.
Start by pasting the material into a prompt and see whether the output is good enough. Most business problems stop there. If you need it repeatedly, across many documents, build retrieval. Only reach for fine-tuning when prompting and retrieval both work and the remaining problem is consistency of form.
Most RAG disappointments trace to three fixable things. Chunk size: passages that are too small lose the context that made them meaningful, and ones that are too large dilute the match — a few hundred words with some overlap is a sane starting point. Metadata: storing the document title, date and section alongside each passage lets you filter before searching and show a proper citation afterwards. Messy sources: if your documents are inconsistent, contradictory or years out of date, retrieval surfaces exactly that, confidently.
Test it the honest way: take twenty real questions people actually ask, run them, and look at the passages that came back before you look at the answers. If the right passage was not retrieved, no amount of prompt tuning will save the response.
⏱ 5 min read
New models arrive constantly, each with a chart showing it in front. Knowing how to read those charts is the difference between choosing on evidence and choosing on marketing.
Static benchmarks are fixed question sets with known answers — graduate-level knowledge tests, science questions written to resist simple lookup, exam-style reasoning sets. They are repeatable and comparable, which is their strength, and they go stale, which is their weakness.
Arena rankings put two anonymous models against the same prompt and let people vote, then convert those votes into a rating with the same family of statistics used for chess. They capture something benchmarks miss — which answer a human actually preferred — and they carry known biases: longer, confidently formatted answers tend to win, and the voter pool is not a cross-section of your customers.
Agentic suites score models on realistic multi-step work, such as resolving real issues in real codebases or completing tasks in a simulated computer. These are the closest proxy for the work people now actually delegate.
Triangulate across a static benchmark, an arena ranking and an agentic suite; agreement across all three is a real signal, and a model leading only one is a marketing claim. Then add the two things leaderboards never show: what it costs at your volume, and how it performs on your own tasks.
Because the ordering changes every few weeks, the useful habit is checking a tracker rather than memorizing a winner. LLM1.com maintains a running leaderboard of which model currently leads, broken out by category, so you can see both the current ranking and how it has moved. The companion LLM research directory indexes the underlying papers if you want to go past the scoreboard.
When a new model is announced, the accompanying benchmark chart is marketing material produced by the party being measured. That does not make it false, but it does mean the selection is not neutral. Three questions strip most of the spin: which benchmarks were chosen, and which comparable ones were left out? Was the comparison run against competitors' best configurations or their defaults? And is the harness described well enough that somebody else could reproduce it?
Independent replication, when it arrives a week or two later, is worth more than the launch chart. The habit of waiting a fortnight before switching anything costs you nothing and spares you most of the churn.
⏱ 5 min read
The last module is the one that decides whether any of this survives contact with a real business.
API pricing is per token, quoted per million, and split into input (what you send) and output (what comes back), with output typically several times more expensive. Reasoning tokens are billed as output even when hidden. A consumer subscription bundles this into a flat monthly fee, which is why it is usually the cheaper way to start.
Four levers control cost, in order of effect: use a smaller model for easy tasks, send less context, cache or reuse repeated prompt prefixes where the provider supports it, and do not use a reasoning model where a standard one would do. The gap between a careless implementation and a careful one is routinely an order of magnitude.
Whatever you paste into a prompt leaves your computer and is processed by someone else's. The questions that matter are whether the provider trains on your inputs, how long they retain them, and what your own contracts say about where client material may go. Consumer tiers and business or enterprise tiers often differ sharply on exactly these points, and the terms are published — read them for the tier you are actually on, not the one you remember reading about.
Models learn from human text and reproduce the patterns in it, including unflattering ones. That matters most when output touches people — screening applicants, scoring customers, writing anything about an individual. Keep a human deciding, and check outcomes across groups rather than assuming neutrality.
On disclosure, norms are still forming and the defensible position is simple: do not pass off generated work as something it is not when the distinction would matter to the person receiving it. And whatever the tool produced, the accountability is yours. "The AI wrote it" has never once been an adequate answer to a client whose page went out wrong.
The easiest mistake is assuming the tool helped because it felt fast. Before rolling anything out, write down the number it is supposed to move: hours saved on a specific task, tickets resolved without escalation, drafts that ship without a rewrite. Then check it a month later.
Two patterns show up repeatedly in small businesses. Work genuinely disappears — the first draft, the summary, the boilerplate — and the time saved is real. Or review and correction quietly consume the time that generation saved, in which case the task was a poor fit and the honest move is to stop, rather than to keep tuning prompts on something that was never going to pay.
⏱ ~6 min
Answer all ten, then score yourself. Explanations appear after scoring.
All consulted October 2026. Search, AI and platform products change fast — check the primary documentation before acting on anything time-sensitive.
We build with these every week — automations, content pipelines, site search, internal tools — and we start by picking the right model for the job rather than the one in the headlines.
Bring us a workflow you think could be automated and we will tell you honestly whether an LLM is the right tool. We set this up in days, not weeks.
CLIKT.com: Northeast Ohio web, SEO & AI since 1996.