Part 5 of 5

Capabilities, and where they fray

What models can be driven to do — and the edge each capability carries.

What models can be driven to do

A model's whole engine is still next-token prediction — but post-training and careful prompting turn that one ability into a practical toolkit.None of these are separate "modes" wired in beside the model. They are all the same next-token engine from Part 1, coaxed into useful shapes by how it was trained and how you prompt it. It can reason through a problem step by step, call external tools, return data in a fixed shape, and follow standing instructions. Each of these is genuinely useful, and each frays at a predictable edge.

The explorer pairs every capability with the failure mode you have to design around. Select one to see what it does and where it breaks.

Every capability has an edge

The flexibility that makes these models useful is exactly what makes their limits easy to miss. A capable model will attempt almost anything you ask, fluently, whether or not it can actually do it well — so the failure modes rarely announce themselves. Two of the capabilities above deserve a closer look, because their mechanism explains both their power and their edge.

Test-time compute — why "reasoning" models think before answering

A reasoning model is trained to produce a stretch of intermediate "thinking" tokens before its final answer. Those tokens are real generation — they cost time and money — but they let the model break a hard problem into smaller steps it can each get right, rather than committing to an answer in a single shot. The trade is direct: more thinking time tends to raise accuracy on hard problems, while raising latency and cost on every problem. It is not a guarantee of truth — a model can reason at length down a confident, wrong path — but on problems with a checkable structure, spending compute at answer time often beats a snap reply.

The tool-call loop — how a model uses the outside world

Tool use turns a one-shot predictor into something that can act. The loop: the model emits a structured call — a tool name plus JSON arguments — instead of a normal reply; your application runs that tool; the result is fed back into the context as a new message; and the model continues, now able to see what happened. Repeat, and the model can search, fetch, calculate, or edit files across many turns. This loop is the heart of an agent — the applied part, Running one for real, follows it through a working coding agent. The edge: the model can only call tools as well as you describe them, and a result it cannot interpret is a dead end.

From "what" to "how well"

Knowing what a model can do is half the picture. Whether it does any of it well enough on your machine — fast enough, in the memory you have, at a quality you can trust — is a separate, measurable question.

Where this leads

Every capability here costs memory, time, and careful prompting. The next leg, Running one for real, puts a concrete local model on a real machine and measures exactly what those costs are — and how to choose a model that pays them.

← Part 4

Attention

Back to the start

The next-token machine →