What happens when a program runs?

Claude Code can run models other than Claude. People point it at Kimi or GPT and it carries on working, which makes plain what it is: not the model, but the program round the model, the harness⁰³. That raises the question this note follows down. If the harness isn't the clever part, what does it actually do? And when you type claude, what runs, where, and on what?

It builds on How does my terminal find a tool?, which covers how the shell finds the word you typed, and What actually runs my code?, which sets out engine, harness and environment.

A language model does one thing: it reads text and writes text. It can't open a file, run a command or decide to stop, because it has no way to touch anything. The harness is the part with hands. It sends the model the conversation, reads what comes back, and acts on it.

That works because what comes back is structured. When the model wants something done, it writes a tool call⁴¹: not a vague request, but data in an agreed shape, such as which tool, which file, which text to replace with which. From there the harness needs no intelligence at all. It is ordinary code: does that text appear in the file exactly once? Then replace it and write the file; if not, say why. The loop round it is just as plain. Send the conversation, get a reply; if the reply contains a tool call, run it, add the result to the conversation and go again; if it doesn't, the turn is over.

• The model decides: which file matters, what to change, whether the work is finished.
• The harness does: checks the change applies, writes it to disk, runs the command, enforces limits on time and steps, and chooses what the model is shown in the first place, since a whole codebase never fits.

Without a model, the harness can load its settings and wait. It can carry out a tool call, but it can never decide to make one. And because its code doesn't depend on whose model answers, it can talk to any model that accepts the same request shape and replies with tool calls it can read; Claude Code reads an environment variable for the address it sends requests to. A different model may still stumble in it, because the harness was tuned against Claude's habits.

The model proposes in text. The harness turns text into consequences.

The harness runs on your machine. It is a program like any other, loaded into your memory as a process¹⁰. The model doesn't: it is far too large for a laptop and needs racks of GPUs, so it stays loaded on the provider's servers, answering huge numbers of conversations at once. The API is neither of them. It is the wire between: a request carrying the conversation goes out over the internet, a reply comes back.

So the harness is in your memory, the model is in someone else's, and the API joins the two. It is also why the program feels the same on a cheap laptop as an expensive one: the heavy work never happens on your machine. Where it runs follows the same request from the server's side.

~/.local/bin/claude is a symlink²⁵, and the real program is elsewhere, in ~/.local/share/claude. That split is on purpose. ~/.local/bin is a shared shelf on PATH²⁴ where many tools put a small entry, so the shell only has to look in one place; each tool keeps its real files in a folder of its own. (/usr/local/bin is the same idea for every account on the machine; ~/.local/bin is for yours alone.)

Following the link isn't the shell's job. The shell asks the kernel²⁹ to run a path, and the kernel resolves links as it opens any file, for any program. From there it does the same for every program, whether it was typed or double-clicked.

A program file is bytes: instructions for the processor, and data. Running it means the kernel sets up a new process with its own private memory and a number, its PID, maps the file into RAM⁴² so its bytes can be read at memory speed, and points a processor core at the first instruction. A program with windows goes through the same steps; it just has more code once it's running, an event loop waiting for clicks. And one process starts another: the terminal starts the shell, /bin/zsh, and the shell starts claude. Activity Monitor, or ps and top in a terminal, lists them all with their PIDs.

Every open program holds a share of RAM until it quits, and RAM has a fixed size. When it fills, the system doesn't refuse. macOS first squeezes memory that hasn't been touched lately, then moves some of it out to the disk, into swap⁴³, to make room. The disk is far slower than RAM, so a machine that keeps moving memory in and out of it slows to a crawl. That is the usual cause of everything freezing with too much open.

The other cause is the processor itself: too many programs wanting to compute at the same moment, so they wait their turn. That is the subject of the next section, and it shows as stutter rather than a freeze.

A core⁴⁴ is the part of the processor that executes instructions: fetch one, carry it out, fetch the next, billions of times a second. One core follows one stream of instructions at a time. Those streams are threads¹¹: every process has at least one, and many have dozens.

There are always far more threads than cores. The system gives each runnable thread a few milliseconds on a core, then takes it off and puts another on, so quickly it looks simultaneous. Each swap is a context switch⁴⁵, and it isn't free. More cores means more threads truly running at once; it doesn't end the taking of turns.

Eight cores doesn't mean eight apps. An open app is mostly idle: a chat app waiting for a message, an editor waiting for a key. It is loaded in memory but asks for no core until it has work. On one Mac at a quiet moment, Activity Monitor counted 585 processes and 3,677 threads, with the processor 88% idle. A browser shows the other side: Brave lists a renderer process per site, each with its own PID, so that one crashing page can't take the rest down, and each with twenty-odd threads doing rendering, scripts and network inside it.

Apple's chips also mix two kinds of core. Performance cores are large and fast; efficiency cores are small and frugal, and the system sends background work to them. An M1 Pro has eight or ten cores, two of them efficiency cores.

A CPU core is a generalist, built to follow code full of decisions: if this, do that, remember what happened three steps ago. Each core is large, so a chip has only a handful. A GPU⁴⁶ goes the other way: thousands of small arithmetic units that do little deciding, arranged so that one instruction is carried out on many pieces of data at once. An M1 Pro's GPU has up to 16 cores, and each is a block of many such units.

Brightening a 4K image means multiplying about eight million pixel values by the same number. A CPU works through them a few at a time; a GPU gives each unit a different pixel and does thousands in one step. Running a language model is the same shape of work, mostly multiplying very large tables of numbers, which is why models run on GPUs, and why Why does thinking harder cost more? counts its cost in GPU work.

Machine code⁰⁵ is numbers. On an Intel Mac, the two bytes 10110000 01100001 mean put the number 97 into a register. Apple's own chips use a different instruction set, ARM, where every instruction is 32 bits, but the idea is the same: a bit pattern, and nothing else.

A pattern means something only because the processor was built to react to it. Part of each core, the decoder, is a tree of logic gates⁴⁷ that looks at the opcode⁴⁸ bits and sends a signal down one line out of many: the line that sets the adding circuit going, or the one for moving a value. Change one bit and a different line lights. Nothing is read or interpreted; the meaning was fixed when the chip was designed.

The circuits on those lines are gates too, and gates are switches. A transistor lets current through or doesn't, and Why does thinking harder cost more? shows how a few of them make AND, OR and NOT. Wire an AND and an XOR side by side and you have a half adder, the start of the circuit that adds.

The intelligence isn't in the electricity. It was put into the shape of the wiring, once, and current follows the shape.

Everything that looks like a decision comes down to these. Does claude exist in this folder? Is this file a link? Does this bit pattern match ADD? Each is a yes or a no, a 1 or a 0, and opening a program is millions of them, one after another, too fast to see.

Data is bits too. The letter A is stored as the number 65, 01000001, because the people who drew up ASCII in the 1960s agreed it would be; Unicode kept the same number. That byte is data, not an instruction. To show it, a program runs ordinary instructions that look up 65 in a font, which describes the shape of the letter, and draw that shape. The drawing ends up in a framebuffer⁴⁹, a block of memory holding the colour of every pixel, which the display hardware reads from top to bottom 60 or 120 times a second and turns into light. Nothing decides to show you anything: the screen simply keeps reading that memory.

None of this began with machines. Around 350 BCE, Aristotle noticed that some arguments hold because of their shape, whatever they are about: if all X are Y, and Z is an X, then Z is Y. Logic treated every statement as either true or false, and studied the shapes.

• 1854. George Boole wrote logic as algebra, which is arithmetic with symbols standing for any value: true as 1, false as 0, AND behaving like multiplication. Checking an argument became a calculation. (The word comes from al-jabr, in a book by al-Khwarizmi, whose name also gives us algorithm.)
• 1937. Claude Shannon, in his master's thesis, showed that circuits of switches carry out Boole's algebra exactly: switches in series are AND, in parallel are OR.
• After that, the switch kept shrinking: relays that clicked, vacuum tubes, the transistor in 1947, many transistors on one chip in 1958. An M1 Pro has 33.7 billion.

Each step kept the idea and made the switch smaller. A half adder works the same in relays as in the chip in a laptop.

The shell, itself a program in /bin, finds claude on PATH. The kernel follows the link, maps the program into memory and starts a process. A core runs its instructions, each one a bit pattern lighting one line in the decoder and sending current through gates. The program, the harness, sends your words over the API to a model on someone else's GPUs and acts on the tool calls that come back. When it prints a reply, instructions draw letters into the framebuffer, and the display turns that memory into light.

Every layer is a story told about the one under it. At the bottom, current is let through or stopped, in a pattern someone designed to mean something.