LLM course · astronomy department
How LLMs
…and how to actually work with them
Carson Davis
Three hours. First half: what these things actually are, built from scratch. Second half (next session): the agentic workflows. You all already use Claude Code — the goal is that you walk out able to judge any model yourself, including in six months when everything I name today is obsolete.
"cat" and "kitten" share zero letters.
How is a machine supposed to know
Everything in this talk grows out of that question.
Where I like to start is embeddings, and I start with cat and kitten. Two words that mean almost the same thing — and they don't share any letters. So how is a computer supposed to know they're related?
The arc
ACT I How LLMs actually work hand-built meaning → embeddings → transformers → the naked model
ACT II Working with basic LLMs tokens, context, style, grounding, tools, code, model literacy, chain of thought
ACT III The agentic half agents, skills, project context windows — next session
every beat leaves behind a key idea — they all come back as one fact sheet at the end
Act I builds one mental model: an LLM is a statistical next-word predictor with no facts of its own. Act II is workarounds for the two limitations that model has. Each beat ends with its key idea on screen — at the very end they consolidate into a single fact sheet you can take with you.
ACT I
How LLMs actually work
embeddings → next-word prediction → the naked model
The job of Act I: build, from scratch, one mental model — an LLM is a statistical next-word predictor with no facts of its own. Every beat leaves a specific limitation in your head, and everything in Act II is a workaround for one of them.
Act I · 010
Meaning, by hand
the 80s–90s move: fake dictionary definitions as a matrix
word is-animal? is-small? is-alive? is-…?? cat 1 1 1 ? kitten 1 1 1 ? rock 0 0 0 ? volcano 0 0 0 ? …449,996 more words ? ? ? ?
which dimensions? · consistent across the whole language? · who finishes this?
key idea You cannot hand-write the meaning of every word as a matrix of yes/no features.
Back in the 80s and 90s people manufactured fake dictionary definitions as matrices: is it an animal, yes or no; is it small, yes or no. Write those columns out for the whole English language. The problem shows up the moment you try — choosing what the dimensions even are is brutally hard, being consistent across the entire language is harder, and nobody has the manpower to finish. Limited success — and that limited success is the wall this whole story starts against.
Act I · 020
Old-school NLP got real work done
stock traders, scraping tweets, keyword sentiment dictionaries
"I really like Apple, they're high-performing ."
+1 ✓
"Apple's not as high-performing as they used to be."
+1 ✗
same keywords · opposite meaning · the definitions weren't the problem
key idea A keyword dictionary can have every word's definition right and still miss the meaning of the sentence.
People did get real work done pre-embeddings — traders scraped huge piles of tweets to sense when sentiment on Apple was turning. Build a rough dictionary of positive words: "like," "high-performing." First sentence scores positive, great. Then someone writes the second one — same words, and your system falls right over. That's the tell: the definitions were all correct; the sentence structure was the problem. [Carson flagged this beat as a cut/compress candidate — it's rendered lean.]
Act I · 030
Meaning, learned from data
the quick cat sat on the mat today …
a window slides over every sentence in every book
predictive · local
word2vec — 2013
train a shallow net to predict a word from its neighbors (or the neighbors from the word)
no matrix — the embeddings are the network's weights
count-based · global
GloVe — 2014
tally a giant co-occurrence matrix over the whole corpus, then factorize it
vector dot products ≈ log co-occurrence counts
…and they turned out to be mathematically almost the same trick
key idea A word's meaning is captured by the company it keeps — either camp gives every word a vector of ~300 numbers.
The landmark was word2vec in 2013. There were two camps. word2vec: slide a small window along the text and train a shallow network to predict a word from its neighbors — no explicit matrix, the embeddings ARE the weights. GloVe, a year later: first count how often every word co-occurs with every other word into one big matrix, then factorize it. And the punchline for this room: skip-gram was later shown to be an implicit factorization of a co-occurrence matrix — predict-the-neighbors and factorize-the-counts are two roads to nearly the same place. Early research questions: how big a window? strip "a"/"the"? collapse want/wanting/wanted to one stem? Hold onto that stemming instinct — it comes back as tokens.
Act I · 040
Meaning becomes geometry
man
king
woman
queen
same offset
cat · kitten · jaguar
king − man + woman ≈ queen
subtract the vectors, cosine-match the vocabulary — queen pops out
search leaps too:hurricane ≈ tropical cyclone cat food ≈ kitten food
key idea Meaning becomes geometry — related words cluster, and you can do math on meaning.
Two remarkable things fell out. Synonyms: cat and kitten started as nothing to a computer; now each is ~300 numbers and you can just subtract them and see they're close — cat, kitten, tiger, liger, panther, jaguar all land nearby. And actual math on meaning: king minus man plus woman, cosine similarity against the whole vocabulary, and the closest word is queen. It paid off everywhere: sentiment got much better, and search took a leap — search "hurricane" and it can hand you "tropical cyclone."
Act I · 050
One word, one vector — the ceiling
I'm banking on getting to the bank before it closes — I drove down by the riverbank and the car banked hard to the left…
reliance
money
river edge
tilt
[ 0.21, −0.77, 0.05, … ]
one averaged embedding
key idea A single embedding per word can't tell the riverbank from the bank where you withdraw money.
The limitation: you only get a word's meaning on average, because training saw it in every context and blended them. I just used "bank" four completely different ways. Riverbank should have a wildly different embedding than the financial institution — but a static embedding gives it exactly one. A clear, obvious problem — and the wall the next architecture had to break through. The audience should be asking: how do we make a word mean different things in different sentences?
Act I · 060
Attention → next-word prediction
"Attention Is All You Need" — 2017
The
cat
sat
on
the
___
every word looks at every other word
mat 0.6
rug 0.2
floor 0.1
…
a distribution over the next word
static vectors word2vec / GloVe · '13–'14
→
ELMo contextual, via LSTM · early 2018
→
BERT contextual, via transformer · late 2018
→
GPT just predict the next token
contextual embeddings fixed "bank" — the transformer is what made them cheap at scale
key idea Attention lets words look at each other; next-word prediction turns that into a text generator — an autocomplete.
The next landmark: transformers — "Attention Is All You Need," 2017. Once words could pay attention to each other, a word's representation could finally depend on its sentence. Precision for this room: what fixed the bank problem was CONTEXTUAL embeddings — and the first one that mattered, ELMo in early 2018, was an LSTM, not a transformer. BERT later in 2018 did it with a transformer and made it dominant. The transformer's real win is that it made contextual representation cheap and scalable. Then the reframe that defines everything downstream: train by hiding a word and predicting it. What you've built is autocomplete — predict the next word, then the next — and out comes coherent text.
Act I · 070
The scaling bet
OpenAI's wager: same architecture, more text, better model
GPT-1 2018 · kind of terrible
+ more data →
GPT-2 2019 · way better
+ more data →
GPT-3 2020 · actually good
hold onto this — the free lunch runs out later
key idea Pour enough text into next-word prediction and it becomes shockingly capable.
This is where OpenAI got their start: bet big that enough text data in this architecture would be amazing. GPT-1 — honestly kind of terrible. Fine, more data: GPT-2, way better. More again: GPT-3, actually pretty good. Same idea, more scale, each jump a genuine leap. Hold onto this — much later we hit the moment the scaling free lunch runs out, and I want you to feel that turn.
Act I · 080
Post-training: autocomplete → assistant
base model — next-word predictorcontinues your text; doesn't answer it
+
post-training — teach it to answer~10³–10⁴ hand-written ideal answers (SFT) + reinforcement from human preference rankings (RLHF)
=
a thing that talks to you InstructGPT recipe → GPT-3.5 → ChatGPT
a knob the company controls — remember that for style, and for tools
key idea Post-training turns "continue the text" into "answer the question."
A raw next-word predictor just continues text. To make it answer you, add a post-training layer. The InstructGPT recipe (2022, the ancestor of GPT-3.5/ChatGPT): about 13,000 hand-written ideal answers for supervised fine-tuning — "on the order of ten-thousand hand-written examples" — then a reward model trained on humans ranking outputs, then reinforcement learning against it. That layer is the entire difference between autocomplete and a thing that feels like it's talking to you. And it's a knob the company controls — that matters twice more: style control, and the orchestrator variants.
Act I · 090
Statistical truth, not knowledge
"The capital of Australia is ___"
Sydney 0.58 ✗ wrong
Canberra 0.31 ✓
Melbourne 0.09
if the corpus repeats the wrong thing, the wrong thing is the likely token
not confidently wrong —because it was never confidently right
key idea A naked LLM has no facts — it's truthful only because most of its training text was.
do Distrust unsourced factual claims from a bare model. Drop the word "hallucination."
The thesis of the whole course. Nothing in this training makes the model correct about anything — it's trained to speak English the way it's seen English spoken. The magic is that most of that text is factually true about the basics, so speaking good English tends to produce true things. It's fragile: if the most-repeated version of something is wrong, the wrong thing is the most likely token. This is why I don't like "hallucination" — it implies the model is normally right and occasionally slips. Raw, naked LLMs don't know anything. When one tells you something confidently wrong, it isn't confidently wrong — it was never confidently right. There are no facts in there.
Act I · 100
Temperature
"my dad went to the store to buy ___ and he never came back"
low T — sharpened
milk beer cigarettes eggs longsword volcano → "milk", every time
the model's distribution
milk .50
beer .15
cigarettes .12
eggs .08
longsword .004
volcano .001
high T — flattened
milk beer cigarettes eggs longsword volcano → "a miniature volcano"
softmax(logits / T) — one distribution, reshaped · it's literally Boltzmann
key idea Output varies because you sample from a distribution that temperature stretches or squashes.
do Raise temperature for novelty; lower it for the single most-likely, near-deterministic answer.
In the corpus the likely fills are milk, beer, cigarettes — a whole distribution. If the model always grabbed the top word it'd say the same thing every time. Temperature is one knob that divides the logits before the softmax — it doesn't add a second distribution on top, it reshapes the one distribution the model already produced. Low T: mass piles onto the top token — deterministic, safe. High T: long shots become reachable — dad buys a miniature volcano. For this room: it's literally the temperature in a Boltzmann distribution — low T freezes into the ground state, high T populates excited states. [Creativity depth (jaguar laps the milk) is the cut candidate — carry it verbally if time allows: the model can say "jaguar" where the corpus only ever said "cat," because jaguar's vector sits next to cat's. Structured novelty, not random noise.]
Act I · 110
The naked model
launch-day ChatGPT = next-word predictor + post-training. That's it.
amazing
✓ perfect, coherent English
✓ writes you anything — a poem, on demand
✓ a computer that talks back
frustrating
✗ states things that are just not true
✗ falls apart on complex instructions
✗ …and now you know exactly why
key idea The naked model is fluent and coherent, but has no facts and struggles with multi-part instructions.
That's the naked model — my name for it — and it's where we all were when ChatGPT launched. Remember how that felt: absolutely amazing — say something to a computer and it answers in perfect English, writes you a poem. And genuinely frustrating — it states things that are just not true, or falls apart on a complicated instruction. Hopefully it's now obvious why both are true.
Coherent. Confident.Untrue — and it drops your instructions.
Everything from here is the workaround .
The hinge. Two frustrations — it says untrue things, and it drops complex instructions. Those two lines are the to-do list for the entire rest of this talk.
ACT II
Working with basic LLMs
tokens → context → grounding → tools → judging models
Act II answers Act I's two frustrations with practical technique. The through-line is: context is everything. Nearly every fix is "put the right tokens in the window." Plumbing first (tokens, conversation, context window), then acting on it (style, grounding, tools, code), then judging the tools themselves (model literacy, chain of thought).
Act II · 120
Tokens, not words
geology
→
geo logy
("something like" — every model's split differs)
same instinct as stemming: want / wanting / wanted → want
≈ 4 characters per token(English)
learned per model , bottom-up, by merging frequent pairs (BPE)
key idea A token is a learned, semantically meaningful chunk of text — not necessarily a whole word.
do Estimate tokens as characters ÷ 4; expect the count to differ per model.
What actually goes into a model isn't words, it's tokens — meaningful breakdowns of words. Remember the stemming instinct from word2vec — stripping "-ing" so want/wanting/wanted collapse together? Tokens encapsulate that kind of semantic chunk. "Geology" splits into something like geo + logy — the exact split depends on the tokenizer, because every model learns its own via byte-pair encoding. Rule of thumb: about 4 characters per token in English — divide your character count by four and that's your token count. This is the unit for everything that follows: context limits, and pricing.
Act II · 130
The conversation illusion
turn 1
A →
fresh model
→
B
turn 2
A B C →
fresh model
→
D
turn 3
A B C D E →
fresh model
→
F
an hour in: the entire transcript , replayed every turn, into a model with no memory
100,000 tokens of the old idea
50 of your new one
key idea Every turn re-feeds the whole transcript to a stateless model — there is no memory.
do To unstick a model, don't argue at the end of a long thread — reset or prune the history.
The thing that matters most in Act II. The model is not having a conversation with a memory. Everything you've said gets said fresh to a brand-new model every single turn: you say A, it answers B; you say C, and A-B-C go in together to produce D; then the whole stack goes in to get the next one. An hour of talking means the entire hour goes in, every turn, into a model that has never seen a single word before. (Token caching is a real nuance — ignore it; the stateless model is the useful one.) And it instantly explains why models get hung up on something you said an hour ago: 100,000 tokens of one idea versus 50 tokens of your new idea — a next-word predictor is swamped by the 100,000.
Act II · 140
Context window & context rot
the cap: 8k tokens (2022) → 1M+ (now) — an economics limit, not a law of math
"lost in the middle" — position
recall dips in the middle
start
end of window
recall
"context rot" — total input
well before the limit
accuracy
input tokens →
every frontier model degrades as input grows (Chroma, 2025) — more tokens = more distractors
key idea A bigger window is not uniformly good context — performance sags as it fills.
do Keep the window lean and relevant. Don't dump everything in.
Every LLM caps how many tokens fit — the context window. For LLMs it's a soft limit: attention cost grows quadratically and quality falls off past the trained length, so providers cap where compute and quality stop being worth it — that's why 8k in 2022 became 1M+ now. (Embedding models are different — genuinely hard caps.) But a million tokens isn't a million equal tokens. Two distinct effects: "lost in the middle" — bury a fact mid-window and recall dips (the U-curve, 2023). And "context rot" — the 2025 Chroma result: all 18 frontier models tested degrade as input grows, dropping 30–50% well before the advertised limit. More tokens means more distractors competing for attention. This is the master lever of the whole act: protect the window.
Act II · 150
Steering style
few-shot prompting = in-context learning — "Language Models are Few-Shot Learners," 2020
pretraining whatever text it happened to see
post-training the company's "be concise" layer
the window yours — it's still a next-word predictor
want Shakespeare? spend 300,000 tokens on the actual works of Shakespeare
want your voice? paste three of your own posts in front of the ask
weak/local model? decompose: style-guide template → fill it from your sample → write to it
key idea Style lives in the weights and the window — and you can override the weights from the window.
do Paste 3+ samples of the target voice before asking for a draft.
We can all spot LLM voice instantly. But models aren't stuck writing that way — party trick: hand it code, ask for iambic pentameter with a heavy Southern accent. Three places style comes from: pretraining data, the post-training layer, and — the one people overlook — in-context examples, because it's still a next-word predictor. The term: few-shot prompting, a.k.a. in-context learning, from the 2020 GPT-3 paper — adapting from examples in the prompt with zero weight updates. You've got a million tokens; spend 300k on Shakespeare and it's suddenly very good at Shakespeare. My actual practice: shove three of my own blog posts at the start instead of letting Claude write in that way everyone can spot. For a weaker or local model, decompose: have it produce a style-guide template (it's seen tens of thousands), fill the template from your sample, then write to the filled guide. Don't bet on the weights delivering — break it into easy steps.
Act II · 160
Grounding facts
ask the weights
"tell me the value from this paper"
one paper among tens of thousands, drowned out
hope & pray ✗
put it in the window
paste the paper , then ask about that
the fact is now in front of the model, not buried in it
grounded ✓
context is everything.
key idea Supply the source instead of hoping the weights memorized it.
do Paste the paper / the data and ask about that — never ask the model from memory.
Revisit the thing people call hallucination and I call being statistical. How do you make an LLM tell you true things? The trivial way: ask and cross your fingers that the true fact happened to be the most statistically likely output. If you're doing science, that should not be your style. The better way: find the true fact and put it in the window. Want a fact from a research paper? It's somewhere in the training data — one of tens of thousands, drowned out. Download it, paste it, ask about THAT. You are infinitely more likely to get a good result by pasting the damn paper than by hoping the weights have your back. This is the core concept of the whole course: context is everything. The context you build is what you live or die on.
Act II · 170
Tool calling & the orchestrator
you
14.7 ÷ 16.9 ?
next-word predictor
naked LLM
feed it straight in…
"≈ 0.92, probably" ✗
never seen this exact string
ORCHESTRATOR
sits in the middle
1
hijacks the request
tool
calculator
2
extract the math
0.8698
3
question + 0.8698
→ into the context window
reply
14.7 ÷ 16.9 ≈ 0.870 ✓
4
phrases the answer
key idea naked LLM + tool + orchestrator — the architecture of every assistant you actually use.
do Think in terms of routing work to tools, not doing everything inside the chat window.
Naked models are bad at things that aren't talking — like math. "2 + 2" is memorized; 14.7 ÷ 16.9 it has probably never seen, and knowing what words mean doesn't mean it has ever conceptualized arithmetic. The fix: your input contains a math question; instead of feeding it straight to the next-word predictor, something hijacks it, extracts the math, hands it to a calculator, then feeds the original question plus the calculator's answer into the model to phrase the reply. Three concepts: the naked LLM. The tool. And the orchestrator — whatever sits in the middle, hijacking requests and handing pieces to tools.
Act II · 170
Flavors of orchestrator
same LLM, retrained post-trained to pick tools instead of answering
tiny specialist a much smaller model that only routes
just prompted an ordinary model told to orchestrate
Windsurf ran its own in-house coding orchestrator — until the big-boy models outran it
key idea The orchestrator is a design choice — retrained, tiny, or just prompted — each with tradeoffs.
Several flavors of orchestrator: the same LLM but post-trained to select tools instead of answering; a much tinier LLM specialized just for orchestration; or an ordinary model with no special training that you just prompt into the role — each with pros and cons. Windsurf, back in the day, had their own orchestration model for coding, but the big companies got so much better that the in-house model couldn't keep up. [This slide is the first cut if 170 runs long.]
Act II · 180
Search — the killer tool
"what pickups are in my bass?"
orchestrator "this needs a real fact"
→
search tool manufactures queries, runs them
→
the real page the maker's spec sheet
→
context window question + page summary
→
tool calling's double power: better abilities and a better context window, built for you
RAG — retrieval-augmented generation
later: your own RAG over your own scientific documents
key idea Retrieval augments generation — pull the real source into the window at question time.
do Route questions that need a live or authoritative source through search / retrieval.
Connect tool calling back to the truth problem. I play bass; I ask about my specific bass. The info might be buried in the training data — or the orchestrator notices this is about a product, decides to ground it, reaches for the search tool: manufactures queries, runs them, finds the page where my bass is listed, pulls the content, and puts my original question plus a summary of that page into the context window before answering. That's the double power of tool calling: access to better things, AND a better context window built automatically. The word is RAG — retrieval-augmented generation — I want you to recognize it. When we talk about serious work on scientific data, this is exactly what you'll build locally over your own documents.
Act II · 190
Why code beats prose
count in its head
"how many R's in strawberry?"
"2" ✗
it's predicting tokens, not counting letters
ask for the program
"write a letter-counter, run it on strawberry"
>>> "strawberry".count("r")
33 ✓
English: ~450,000 words , infinite phrasing · Python: ~1,000 core things , brutally constrained — and the training data pairs code with what it does
key idea Code is tiny, constrained, and functional — models are simply more capable in code than in prose.
do For counting, math, parsing: ask the model to write and run the program, not to do it in its head.
Why are models so good at code, and why does code matter more than words? English is impossibly broad — hundreds of thousands of words, a million phrasings. Python is maybe a thousand core things, insanely constrained, and deeply functional: in the training data the code sits right next to what the code does. So you get better outputs AND the model is genuinely more capable there. The classic: "how many R's in strawberry?" — it used to confidently get it wrong, and even spelling it out it'd still miss, because it doesn't know things, it predicts tokens. You could paste the count into context — fixes one case. The better move: "write me a program that counts letters, then use it on strawberry." Still using the LLM, still not doing the work yourself — but now the answer is infinitely better. A big part of your job is recognizing when to reach for code.
Act II · 200
Reading a model card: size
"3B · 7B · 36B · 70B" = billions of parameters · memory = params × bytes per param
FP32 4 bytes / param 70B → ~280 GB research artifact FP16 / BF16 2 bytes / param 70B → ~140 GB the native footprint INT8 1 byte / param 70B → ~70 GB 4-bit ~0.5 byte / param 70B → ~40 GB the local sweet spot
and it wants to sit in GPU memory — spill to RAM and the bus speed throttles you
key idea Parameters × precision ≈ GB — a 70B model is ~140 GB native (FP16), ~40 GB at 4-bit.
I can't tell you what model to use in six months — so learn to eyeball any model. On Hugging Face: 3B, 7B, 36B, 70B — billions of parameters. Memory is parameters times bytes per parameter, so it depends entirely on precision: 70B is ~280 GB at FP32, ~140 GB at FP16/BF16 — and THAT's the honest native number, models ship and train in half precision — ~70 GB at 8-bit, ~40 GB at 4-bit. (Plus ~10-15 GB of KV-cache at inference.) And you want it in GPU memory: spill to system RAM and you're throttled by the bus between where the memory lives and where the compute happens — it's not just how much memory, it's how fat the pipe is.
Act II · 200
Quantization is lossy compression
semantic info isn't linear in precision — you save more size than you lose quality
you all know PCA : squeeze the space, keep the signal — same idea
Q4_K_M keeps roughly 92–95% of full-precision quality
rule of thumb, not a law — 2–3-bit breaks models
quality at the same footprint
36B
120B
36 GB
120B crushed to fit — loses
36B lightly quantized — wins
memory footprint →
benchmark quality
key idea Quantization trades precision for size with sub-linear quality loss — PCA for weights.
do Check size and quant level, then read the published accuracy stats — decide from the benchmarks.
How do people run a 70B model on a 36 GB laptop? Quantization. The embedding numbers carry ~32 bits of precision, but the semantic information isn't linear in that precision — lossy compression saves noticeably more size than it costs performance. You all know PCA: squeeze a big vector space down while keeping most of the signal — same idea. FP32 to FP16 down to 4-bit, and a good scheme like Q4_K_M keeps roughly 92-95% of quality. So a lightly-quantized 36B can beat a 120B crushed down to the same footprint — but that's a rule of thumb, not a law, and the whole point is: go read the actual published accuracy stats on the model card and decide for yourself.
Act II · 210
The scaling era ends
GPT-1 2018
GPT-2 2019
GPT-3 2020
GPT-4 2023
GPT-4.5 2025
OpenAI itself: "not a frontier model"
"we only have one internet" — data is the fossil fuel of AI (Sutskever, NeurIPS 2024)
curate filter the junk out
synthesize generate targeted training data
hire humans pay for new data
worry: the new internet is LLM output — recursive training collapses models (Nature, 2024) · mixture of experts: the words exist; that's all we have time for
key idea More-data-forever broke — gains now come from better data, not more of it.
do Don't assume each new model is a leap from scale alone; weigh the data and technique behind it.
Back to how models get better. For a while the lever was more data, and the dream was riding that to AGI. 1→2 phenomenal, 2→3 phenomenal, 3→4 still big — then GPT-4.5, February 2025: OpenAI's largest-ever pretrained model, and OpenAI itself declined to call it a frontier model. That's the poster child for diminishing returns. Why? We basically ran out of data — Sutskever at NeurIPS 2024: data is the fossil fuel of AI, we only have one internet, "pre-training as we know it will end." So you get smarter about which data: filter junk, generate synthetic data on subjects that help, pay humans to make more. And the much-discussed worry — the new internet is itself polluted with LLM output; the Nature 2024 result shows models trained recursively on their own output collapse. Mixture of experts: the words exist, and that's all three hours allows.
Act II · 220
Chain of thought
"5 blue houses and a red one. Jill's in the yellow house, Bob's in the green one. Which house does Sam live in?"
thinking… five blue + one red = six houses on the street … but Jill is in a yellow house — so Jill's house isn't one of the six? … same for Bob's green … so the named houses are elsewhere; the question never places Sam … wait — re-read the puzzle … the puzzle doesn't determine Sam's house …
→ "There isn't enough information to say which house Sam lives in."
the model writes out reasoning tokens before the answer — one continuous generation
each reasoning step is still next-word prediction — but the chain reaches answers a single pass can't
the "thinking…" spinner is literally these tokens streaming out
key idea Chain of thought = the model generating its reasoning as tokens before answering — not chopping up your input.
The last big piece. Chain of thought is NOT slicing your input into chunks and re-feeding them — it's the model generating intermediate reasoning tokens, working out loud, before emitting the final answer, all as one continuous generation. Started as a prompting trick in 2022 ("let's think step by step"), now baked into reasoning models trained by RL to produce long internal reasoning first. Mechanically it's still just next-word prediction — each reasoning step is predicted like any token — but by spending tokens on scratch work it reaches answers a single pass can't. My trivial example is the house puzzle — the real payoff isn't word puzzles, it's detailed interdependent instructions: break them into a chain and the model can attend to each one and reconsider against the others. When you see "thinking…" churn — that's literally these tokens streaming.
Act II · 220
The cost of thinking
thinking: low ↔ high — a knob you set
thinking tokens are billed as output tokens
a hard problem can emit 5–10× more of them
accuracy ↗ · latency ↗ · cost ↗
the curve you'll be reading for years
the knee — where you want to sit
thinking tokens spent →
performance
key idea Reasoning trades money and latency for accuracy — you pay for the scratch work as output tokens.
do Thinking up for complex interdependent tasks, down for simple ones; judge future models on tokens-vs-performance, not size.
You get a knob: high thinking runs longer chains, low runs shorter. The cost model matters: over an API you pay tokens in and tokens out, and thinking tokens are billed as output tokens — full output price — and a hard problem can emit 5-10x more of them. Better results, more money, more time. That's the tradeoff you'll weigh. And the graphs you'll see for future models are tokens-spent versus performance — that's exactly the curve to read when choosing what to use six months from now. [TODO for the real talk: swap the sketch for a real tokens-vs-performance chart from a model release — source TBD per content doc.] A chain-of-thought-plus-tools system is exactly what Act III's agents are built on — that's next session.
consolidation
The fact sheet so far
010 meaning can't be hand-written as features 020 right definitions can still miss the sentence 030 meaning = the company a word keeps 040 meaning becomes geometry — math on vectors 050 one static vector can't hold four "bank"s 060 attention + next-word prediction = the LLM 070 scale made next-word prediction capable 080 post-training turns autocomplete into an answerer 090 no facts inside — never confidently right · drop "hallucination" 100 temperature reshapes one distribution · dial it deliberately 110 fluent + coherent, untrue + drops instructions
120 tokens ≈ 4 chars, learned per model · chars ÷ 4 130 every turn replays all of it, statelessly · prune, don't argue 140 more context ≠ better context · keep the window lean 150 style lives in weights and window · paste 3 samples 160 context is everything · paste the paper 170 naked LLM + tool + orchestrator · route work to tools 180 RAG = retrieval into the window · search for live facts 190 models are more capable in code · ask for the program 200 params × precision ≈ GB; quantization is lossy PCA · read benchmarks 210 better data now beats more data 220 reasoning = generated tokens, billed as output · read the tokens-vs-perf curve
the full course closes with this sheet completed through Act III
Every key idea and every actionable habit from the first half, on one screen. In the real course this sheet finishes the whole talk, completed with Act III, and ships as a handout with a link to working-with-llms.
End of the first half.
You now hold: a next-word predictor with no facts —
Next session — Act III: agents, skills, and crafting a project's context window
the how-to reference lives at madebycarson.com/working-with-llms
Carson Davis · LLM course, first half
Recap the arc in one breath: meaning as geometry, next-word prediction, the naked model and its two frustrations — and then context, grounding, tools, code, and judgment as the workarounds. Act III builds agents out of exactly these parts.