Claude Code, Codex, Pi, and opencode — all four installed, but one did nearly all the work. This is lock-in by habit, not by choice. The solution was a small set of plain-text files, not a framework.

I had four AI coding agents installed on my laptop: Claude Code, Codex, Pi, and opencode. I used one of them for about ninety-five percent of my work. The other three sat there — updated, authenticated, and idle. I told myself that I kept my options open. But I actually built a single point of failure, and I called it a preference.

The uncomfortable part is that none of this concentration was a decision. Claude Code was good, so I reached for it. And each time I reached for it, the next time became more automatic. Everything that made me productive lived inside that one tool. This included the collected context, the session history, and the per-project instructions. All of it sat in a private store, under ~/.claude.

That setup is good until it is not. A tool can become deprecated, or the price can change. A better model can appear somewhere else, and you want to move to it. On that day, you do not only replace a program. You also leave your working memory behind. Then you start cold on every project that you own.

So I gave myself a small engineering project. The goal was to become independent of any single harness. I did not want to hedge. Instead, I wanted to make each switch very cheap. Then I wanted to prove, on a schedule, that the switch still worked.

01 — The requirement

How I found the requirement

My first instinct was to reach for something big. Many “AI operating system” frameworks promise to organize all of your work around an assistant. I looked hard at two of them.

The first was a popular note-and-vault methodology, changed for AI. I rejected it because the complexity was too large for the value in my case. It needed much scaffolding to keep, for structure that I did not need.

The second was more attractive. It personalizes one agent deeply into a life-OS, and the work is truly impressive. But it makes a single tool impossible to replace. This is the exact opposite of what I wanted. If I adopted it, the lock-in became deeper — the same lock-in that I wanted to escape.

Both detours were useful, because they clarified the requirement when I rejected them. This is what I actually needed. I must point any agent at any project with zero cold start. The agent must use portable, plain-text context that I own. And I must keep that independence tested all the time, not only asserted.

That last clause did most of the work. It removed anything clever that can run in only one tool. And it made me rotate between agents, rather than only admire my own optionality.

I built it in four passes, and I examined each pass before the next. First, I did an audit of the actual machine. Second, I consolidated the sprawl. Third, I made one canonical instructions file. Fourth, I moved the work to external files.

The order was important. Because I did the audit first, I built for the setup that I had, not for the setup that I imagined.

02 — The audit

What the audit found

The first pass was pure inventory. For each of the four agents, I found where it keeps config, where it keeps the session history, and how much is there. Claude Code held about sixty project directories. The machine held more than one thousand session transcripts across the tools, and almost all of them were Claude Code’s. The ninety-five percent was not a feeling. It sat there in the file counts.

The audit also found something that I did not look for. About twenty-eight git repositories were quietly inside my cloud-sync folder. Dropbox and a real .git directory both wrote to the same files, and this creates a slow corruption risk. This problem has no relation to AI agents. It is only a result of no earlier audit. It became its own cleanup project.

The thing that you plan to measure is rarely the most useful thing that an audit shows you.

03 — The design

File-owned context, not harness-owned

The core move is simple. Do not let the tool own the context. Let the filesystem own it instead.

Each project gets one canonical instructions file, AGENTS.md, in plain Markdown. It says what the project is, how to build and run it, and its conventions. Codex, opencode, and Pi all read that filename natively.

Claude Code looks for its own CLAUDE.md, so I resolve that name to the same file. Inside git repos I use a symlink. In the places where symlinks do not sync well, such as Dropbox, I use a two-line stub. This gives exactly one source of truth, and no tool keeps a private copy that can drift.

Above the projects, a single identity file sits at the root of my vault. Its name is telos.md. I took the format from Daniel Miessler’s Telos project. It is a durable, human-authored Markdown document. It says who I am, what I want to do, and the goals under the work.

Every AGENTS.md file points at it, and does not explain me again. I do not introduce myself to each new tool. Instead, I point the tool at a file. Because it is only text, any model can read it, and the file is mine.

A launcher that forces rotation. The context ownership makes a switch possible, but it does not make me do the switch. So I use one generic ai launcher, and it picks the harness for me on a deterministic weighted rotation. This is not a coin flip. It is an exact ratio, and I can edit it in one line. The question “how evenly do I rotate” is now a number, not a vague intention.

The launcher also has a force-override. When work is urgent, I pin the tool that I trust, and the exercise never blocks me. Rotation is the whole reason that the independence stays real. If I run the launcher only when it is convenient, I return to ninety-five percent within a month.

External work. The last piece must make the output of each session survive the tool that produced it. Here I split the problem on purpose. That split was the most useful thing that I learned in the build.

The agent captures meaning from the inside. While a session is loaded, the agent is the cheapest and best-informed summarizer that I will ever have on that work. So the agent writes the real decisions as it makes them — the context, the choice, and the reason — into .agent/decisions.md in the project.

A scheduled job captures the mechanical facts from the outside. A launchd job runs every five minutes. It copies the full session transcripts from each tool’s private store into a local-only sidecar at ~/.agent-history, and it organizes them by project. An opt-in, GPG-encrypted backup holds the off-machine copy. A one-line .agent/log.md file holds the per-session metadata.

The agent is good at meaning, but it does not remember the housekeeping tasks. A scheduled job is the reverse. Use each one for its strength.

The principle under all of this has a name that I now use: file over AI. When a tool dies, the durable work must survive as plain files that you can open with any program. It must not survive only as rows in a vendor’s database that you can no longer reach. For this reason, the code now lives in real git repositories under ~/Code. I keep it out of the cloud-sync folder completely. The context files stay as Markdown, and they sync everywhere.

04 — What it buys

The benefits, concretely

The headline benefit is resilience. A tool can become deprecated, or it can change its price, or it can become worse than a better model. On that day I move, and I move without a loss of context, because the context was never inside the tool. My working memory is portable plain text that I own.

Independence here is not a claim in a README. The rotation exercises it, so I find friction on an ordinary Tuesday, and not during an emergency. The external transcripts and decisions become a durable, searchable record of the true history of a project. Before, this knowledge disappeared at the moment when a session closed.

The privacy posture is cleaner than I expected. The conversation content stays local-first. The sidecar never leaves the machine, and the only copies that leave are encrypted.

The cost to run this system is close to nothing. Claude Code runs on my existing Claude Max subscription, and Codex runs on ChatGPT Plus, which I already pay for. The open tools, Pi and opencode, use a bring-your-own-key setup. I point them at a Fireworks API key that I already had. They can also point at OpenRouter, or at a local model through LM Studio, for routine work. A second and third tool cost me no new subscription.

05 — The lesson

Own your context. Treat the agent as replaceable.

I think again and again about the small size of the successful move. I looked for a framework. Instead, I found a small set of plain-text conventions and one launcher.

The set is simple. It has one AGENTS.md per project, and one telos.md for identity. It has one .agent/ folder for the durable output. It has one scheduled copy of the transcripts, and one ai command for a fixed-ratio rotation of the harness. This needs no new platform, and no part works inside only one vendor’s walls.

The tools will always improve, and they will always churn. This is the good news, not the threat. The only thing worth protection is the collected context of your work. You protect it in one reliable way. You keep it in files that you control. And you prove, on a regular schedule, that more than one tool can load it and run.

Maybe you default to one agent, but you never chose this. Then ask what leaves with the agent on the day when you switch. For me, the answer was once “almost everything.” Now the answer is “a habit,” and habits are cheap to change.

Written from my own engineering notebook. — Venki