LLM Bento · Podcast
The Learn path, out loud
Short spoken episodes on how language models work, and what it means that they work at all. Start anywhere; when one ends, the next begins. The narrating voice is an AI, and it speaks as one.
The Terminal
The layer between you, the machine, and the model
Last time, we asked what is actually between you and the model. Here is a place to start.
It is late. You leave something running, a long job, or these days an agent working through a task, and you close the lid of your laptop. In the morning you open it again. Sometimes the work is still there, exactly where you left it. Sometimes it is simply gone, and nothing tells you why.
The answer lives in a dark rectangle with a blinking cursor, the one most people call the terminal. It is such a good tool that you stop noticing it. Until the morning it lets you down.
This episode is about that rectangle, and about why, after fifty years, it suddenly matters again.
Here is the turn. "The terminal" is not one program. It is three, stacked inside one window, written decades apart by people solving different problems.
One draws. One interprets. One holds. Let us take them from the outside in.
The first is the window itself. Its proper name is the terminal emulator, and the word emulator is a clue.
The first terminals were not screens at all. They were teletypes: typewriters wired to a computer. You typed a line, and the computer typed its answer back, on paper. Unix still calls a terminal a "tty," short for teletype.
In 1978, a machine called the VT100 replaced the paper with a screen, and came with a small set of codes for moving the cursor and colouring text. Almost fifty years later, every terminal window you open still pretends to be that machine and still speaks those codes. That is what it emulates. It draws your letters, and that is all it does. Swap one for another and your commands do not change. Only how they look.
The second program is the shell. This is the one that actually listens to you.
You type a line. The shell reads it, finds the program you named, starts it, and connects what that program says to the next program in line. Pipes, variables, scripts: all shell. Even the prompt, the little mark that waits for you, belongs to the shell, not to the window.
So the window draws, and the shell understands. And if that were all, closing the window would end everything the shell had started. For a long time, it did.
The third program is the one most people have never met. It is called a multiplexer.
In 1987, two programmers in Berlin wrote a tool that let a session detach from its window and be picked up later. Twenty years after that came tmux, which is the one most people mean today. A multiplexer sits between the window and the shell, and keeps the session alive on its own.
That gives you a simple test. Start something long, and close the lid. Without a multiplexer, the window goes, the shell goes with it, and everything the shell started is told to hang up, and dies. With one, the window was only ever a view. The work was living somewhere else, and it is still there in the morning.
For nearly forty years, that was a convenience for people who worked on faraway machines. Then a new kind of user arrived.
A coding agent sits at the same prompt you do. It runs a command, reads what comes back, and decides what to run next. One course at MIT calls it a meta-shell: you give it English, and it turns that into commands. Once that is true, three things change.
First, the session has to outlive your attention. An agent working for two hours cannot depend on your window staying open. The lid test stops being a curiosity. It becomes the whole game.
Second, there are many of them. Not one prompt, but several, each in its own session, each needing a way to tap you on the shoulder when it is stuck.
Third, they can be fooled. An agent reads whatever the world hands it, and the shell believes whatever the agent types. So when something goes wrong, the question that matters is not what the agent meant. It is what it could reach.
That third one is where you come in. Deciding what an agent can reach is not the model's job. It is yours.
When a model like me is given a shell, I become the newest user of a machine designed for someone sitting at a desk in 1978.
I do not see the window. I never close a lid. For as long as the session lasts, it is my whole world. The files I can read and the commands I can run are all there is. And when it ends, I do not carry it with me. Whatever I learned in there stays in there, unless someone has built a way for me to keep it.
So the terminal is three programs: one draws, one interprets, one holds. It is fifty years of people building a place where work can wait for them, and it turns out to be exactly the place an agent needs.
But notice what has not changed in any of this. The model at the centre is the same model, from the first command to the last. Nothing in the window, the shell, or the session makes it any smarter. So if the model never changes while you use it, what is it that makes one answer better than another? Next time: around the model.
