Modelbound

Nobody starts work. You resume it.

You sit down and before you can do the thing, you have to rebuild the situation you left. The draft tells you what you wrote but not what you ruled out. The folder tells you where the file is but not why there are three of them. So you go looking — through yesterday's messages, your own notes, the tabs you left open as a message to yourself. By the time the picture is whole again the morning is mostly gone.

That's the real cost of working on a computer. Not the typing. The reassembly.

Leisure software doesn't have this problem. A feed is built for arrival. It asks nothing of yesterday and it's right not to. But work is all yesterday, and it gets handed the same greeting — a launcher, a home screen, a blank document, none of which have any idea what you were in the middle of.

So the scarce thing was never compute. It was context. It just lived inside your head, where nobody ever had to price it.

Agents don't fix this. They make it louder. An agent without your context is a contractor you brief from scratch every morning, and the brief usually costs more than the job. That's why assistants feel amazing in a demo and tiring by Wednesday. Demos have no history. Work is nothing but history.

Which gets me to the thing I keep running into, that doesn't have a name.

Definition

Modelbound (adjective) /ˈmɑːdəlˌbaʊnd/

Depending on a particular model for the parts of a system that should outlive it.

Describing work, software, or state whose continuity is tied to a vendor's context window, memory, or session rather than to something the person actually owns.

Examples

• The workflow was modelbound, so the deprecation took the project with it.
• Their assistant was great until the context reset, which is what modelbound feels like.
• Good agent design uses the model without becoming modelbound.

Related: vendor lock-in, session-scoped, ephemeral

Opposite: durable, portable, yours

Being modelbound is easy, because it's the default. The model is the smartest thing in the stack, so it gets handed everything — your files, your history, your permissions, your decisions. It feels like progress. It's mostly renting.

And models get swapped, deprecated, repriced and rate-limited every few months. Your project runs for years. Anything that matters and lives inside the model leaves when the model does.

This is also why I keep bouncing off Karpathy's LLM OS picture, even though I love it. He draws the model as the kernel — context window as RAM, retrieval as the filesystem, tools as peripherals, other models as the network. It's the clearest map anyone has made of this era. It also hands the least predictable part of the stack the most trusted job in computing.

A kernel isn't defined by being smart. It's defined by enforcement. What can read what. What survives a crash. What's allowed to cross a boundary. Places where probably isn't an answer.

Models are useful because they're flexible, and they're flexible because they're stochastic, uneven, and persuadable by whatever they happen to read. Karpathy says this himself, better than I would — jagged intelligence, fallible savants, people spirits. Great qualities in a collaborator. Bad qualities in a kernel.

So flip it. The model proposes and the system disposes. An app doesn't get to decide it can read your files or reach the network. It asks, you decide, the system records it and enforces it. Being able to see something is not the same as being allowed to touch it.

Here's the part I didn't expect. Once the system holds your context, it necessarily holds access to everything your context points at. Memory and permission turn out to be the same thing seen from two sides. That's not a safety feature bolted on afterward. That's the whole shape of the layer.

None of this is a brake on Software 3.0. It's what makes Software 3.0 worth keeping.

If English is a programming language, then apps get soft — describe it, look at it, change it, keep it. But that only works if what you shape stays shaped. Negotiable software needs non-negotiable ground underneath it. Files you can find outside the app that made them. Permissions you can read and revoke. History you can walk back into.

Do that and something good happens. A better model shows up and doesn't start from zero. It walks into a situation that's already there, the way a new hire reads the project folder instead of interviewing you for a week.

The personal computer of this era isn't personal inference. It's personal state.

P.S. Decent test: if your favorite model vanished tomorrow, how much of your work vanishes with it? However you answer, that's how modelbound you are.