Designing a two-lane system

Two lanes, both carrying real work

Most people who use both end up with one lane they use and one they forgot about. That is not a system. That is a habit and a spare tool.

In a real two-lane setup, each side carries work you would miss if it stopped. The local lane is not a toy you keep for the sake of it. The cloud lane is not a guilty secret.

The whole design is three things. A list of where each kind of work may go. A rule that sends each job to a lane. A plan for the day one lane is not there.

Route by the work, not by the mood. The point of writing the rule down is that a tired person at five o'clock follows it anyway.

Write the never-leaves list first

Before you route anything, write the short list of things that must not go out. Do this first, while nothing is urgent.

Keep it short enough to hold in your head. Four lines beat forty. Names of the people you work for. Anything from a signed agreement. Draft work that is not yours to share. Whatever your version of that is.

Then put it where you will see it when you are busy. Taped inside a notebook, or pinned in the tool itself. A list in a document you have to go and find is a list you will not go and find.

A list of places, not a list of feelings

There is a way to write that list badly, and almost everybody does it the first time.

You put down everything that feels private. Client names. Money. Anything with a person in it. Then you look at what you wrote, and it is most of your work.

So go through it again. For each line, ask where that thing already goes. Client figures go to your accounting software. In the United Kingdom the law requires that of many sole traders and landlords, and your own country will have its own version. Contracts go to the client, and to whoever hosts your email. Draft work goes to whatever backs up your laptop.

Almost nothing on a first draft truly never leaves. What is true is that each thing has a set of places it may go, and an agreement decided that set. The United Kingdom's data regulator says a written contract is needed every time you hand personal data to somebody else to handle for you. Look up the rule where you are.

So write the list as places. Client files may go to our accounting software and our email host, and nowhere else. That is a line you can hold a new tool up against.

A list of feelings has one more problem. Nobody can tell whether you broke it, including you. A rule that cannot be checked is a wish.

Backed by Contracts and liabilities between controllers and processors: when is a contract needed?, Making Tax Digital for Income Tax.

A switch beats a promise

A rule you can enforce is worth more than a rule you can recite. Some tools give you a switch, and it is worth seeing what one really looks like.

Ollama has one. You set disable_ollama_cloud to true in a file called server.json inside your .ollama folder. An environment variable named OLLAMA_NO_CLOUD does the same job. Restart it, and a line in its own log then reads Ollama cloud disabled: true.

Two things there are worth copying. The first is that you can see the state. A switch that reports back beats one you believe you set.

The second is that Ollama says what the switch costs. Turn cloud features off and you lose its cloud models and its web search. That is not a flaw. Removing a lane costs you the lane, and a switch that cost nothing would not be doing anything.

So it is not for everybody. If you want both lanes open, the switch is not your tool, and your rule goes back to being a written one you follow. That is a weaker guarantee, and it is worth saying out loud that it is weaker.

If your tool has no such switch at all, that is worth knowing before you build a rule on top of it.

Backed by Ollama FAQ.

The routing rule

Now write the rule. Short lines, in plain words, in the order you will read them.

Write it for a tired version of you. No conditions, and nothing that needs a fine judgement at the end of a long day.

• If it touches the never-leaves list, it stays local. No exceptions, and no case-by-case thinking.
• If a thing may go out but only to one named place, put that place in the line. Allowed somewhere is not allowed anywhere.
• If it is small, frequent and everyday, it goes local. Tidying notes, first drafts, quick rewrites.
• If it is public material and genuinely heavy, it goes to the cloud. Long documents, hard reasoning, work you will publish.
• If it needs something that happened recently, it goes to the cloud, or to a search that you know goes out.
• If several people need the same thing at once, it goes to the cloud, because one shared setup beats five separate ones.

When one lane goes dark

This is the part that gets skipped, and it is the part that decides whether you have a system or a habit.

The cloud lane goes dark more often than people expect. An outage, an expired card, a network that will not behave. The fallback is the local lane, with a rougher answer, and a note to look at that work again later. Say so in advance and it stops being a crisis.

The local lane goes dark too. A laptop dies, or a machine is busy with something else. The fallback is the cloud lane, but only for work the routing rule allows out. For everything else the fallback is doing it by hand, and that is a real plan.

The two outages have different shapes, so plan them separately. A cloud outage is usually short and total: nothing works, then everything does. A local outage is usually long and partial: one machine is gone for a week while the others carry on.

One practical thing. A fallback you have to download during the outage is not a fallback. Keep the local model on the disk before you need it, and open it now and then so you know it still runs.

Notice what all this means for the work that may never go out. It has one lane by design, so an internet outage does not touch it at all. It also has no second lane when the machine itself stops. One lane is a comfort on the day the internet goes, and a problem on the day the laptop does.

This is not a thought experiment

Two-lane designs already ship in products you can install today.

Ollama runs models on your machine. It also offers cloud models, which are sent to its own service. Its reason for doing that is the one from the last two lessons: it lets you keep your local tools while running something too large for a personal computer. That is a two-lane system with a switch you operate.

The lane is even visible in what you type. Ollama's cloud models carry it in the name, as in gpt-oss:120b-cloud. Naming the lane inside the thing itself is a small idea worth stealing for your own notes.

Its web search is the same idea in miniature. The model runs at home. The search query goes out to a service over the internet. One lane and then the other, inside a single answer.

So the design question was never whether this can be built. It is where you draw your own line, and whether you wrote it down.

Backed by Ollama: Cloud, Ollama: Web search.