If you have spent any time near the local AI world, you have heard the names: LM Studio, Ollama, llama-server. People say they "run models at home" with these programs, which is true and also skips the interesting part. After four parts of this series you know about the file, the engine, the transcript trick, and the template. Some piece of software has to hold all of that together. These programs are that piece.

A service, not a chatbot

The piece has a name: a model server. A server, stripped of mystique, is a program that sits running, listens for requests from other programs, and answers them. A model server wraps the inference engine from Part 2 and turns the whole apparatus into a service. The crucial sentence of this part: apps never talk to the model. They talk to the server.

And "server" does not mean "somewhere on the internet". A model server can run entirely inside your own computer, listening only to apps on the same machine. One laptop can be the restaurant and the diner at once.

Here is the server's job description, and notice how many earlier parts of this series it quietly employs. It loads model files into memory and unloads them. It listens for requests from apps. It applies the chat template, which means Part 4's script rewrite happens here, by the server, on the model's behalf. It runs the engine. It streams the answer back word-chunk by word-chunk. It enforces the settings, the temperature, the size of the desk. And it can do all of this for several apps at once, a chat window and a coding assistant and a writing tool all served from one loaded model, like tables sharing a kitchen.

chat app the dining room writing app another table code editor a third table order tickets model server the waiter applies the template (Part 4) engine the kitchen weights the book the answer streams back up, token by token
One waiter, many tables. Every app speaks to the server in the same ticket format, and the server does the rest.

Three waiters and a corporation

The programs people actually use are personalities on top of this one job. LM Studio is the friendly one: a full app with buttons, a built-in model browser, and a bundled engine, so the whole restaurant arrives in one download. llama-server is the expert's tool, part of the llama.cpp project itself: no buttons, no hand-holding, every dial exposed. Ollama sits between them, run from the command line with one-word commands and sensible defaults.

And the cloud services, the OpenAI and Anthropic APIs behind most AI products, are the same idea in someone else's building. When an app calls a cloud AI, it is talking to a very large, very engineered waiter standing in front of racks of kitchens. Different scale, same job description. Nothing conceptually new happens when you swap your laptop's server for a datacentre's, which is precisely why the swap is so easy to make.

The universal plug

Easy because of one quiet miracle of standardisation. Nearly every model server, local or cloud, accepts requests in the same format, universally called the OpenAI-compatible API after the company whose version everyone copied. An API is nothing exotic: an agreed format in which one program asks another to do something. This one is like the USB plug. Any app can talk to any model, local or cloud, because the plug shape is standard, and this single boring fact is why the whole ecosystem works: a thousand apps and a thousand models, and any pair can be connected without either having heard of the other.

This series promised exactly one piece of code, and here it is: the order ticket itself, six lines, annotated in plain words. This is what an app actually sends the waiter when you press send on our Paris question.

{
  "model": "example-31b",        <- which recipe book to load
  "messages": [ ... ],           <- the whole role-tagged conversation, Parts 3 and 4
  "temperature": 0.7,            <- the creativity dial from Part 1
  "tools": [ ... ],              <- actions the app is offering to perform (Part 7!)
  "stream": true                 <- send the reply live, token by token
}

Every layer of the series so far is sitting in that ticket. The transcript trick is the messages list. The briefing is its first entry. The template is what the server will do to it. And one line, tools, is a door we have not opened yet.

Local or cloud, same restaurant

Because the layers are identical, the local-versus-cloud choice becomes clear-eyed rather than tribal. Run the restaurant in your own house and you get privacy, nothing you type leaves the building, plus control of every dial, in exchange for your own electricity and models capped by what your graphics card can hold. Use the cloud and you get models too large to ever run at home with zero setup, in exchange for your conversations passing through someone else's computers under a policy you clicked past. Neither is virtue. They are the same machine with a different landlord, and now that you can see the machine, you can pick per task instead of per ideology.

One analogy break before moving on, because the restaurant has served this series well and deserves an honest audit: a real waiter carries your order to the kitchen verbatim. This one rewrites it into the kitchen's private shorthand on the way (Part 4's template), and no restaurant on earth does that. Otherwise the picture holds: recipe book, kitchen, waiter, order tickets, dining room.

Our Paris message is now fully in motion: dressed, ticketed, rewritten, and computed. But the ticket had that one unexplained line, and it changes the kind of conversation you can have. Some tickets ask the model not for an answer but for a decision, and some conversations run the model in a loop until a job is done. Same brain, different protocols. Those protocols are the last stretch of this series.

Next: Thinking Mode and the Fate of the Thoughts: the private scratchpad some models write before answering, why you pay for words you never see, and the question almost nobody answers about where the thoughts go.