Moving from Claude Code to an open-source harness
This route is the most thorough and the easiest to get wrong. The failure mode is always the same: pick the tool first, then work out how to move your setup into it. The order that works is the opposite one.
The real work is building the map: take what you accumulated in Claude Code, name the counterpart for each item, and then look at what has no counterpart at all. Rule files and MCP mostly travel; hooks have to be rebuilt; subagents mostly do not exist elsewhere. Build that table first and tool selection turns into an elimination exercise.
Build the map first
This table is ordered by "what you actually take with you". Read the last column carefully: some items do not get renamed on the way out, they simply stop existing.
| What you have in Claude Code | Its counterpart elsewhere | Does it travel? |
|---|---|---|
CLAUDE.md project conventions | AGENTS.md, CONVENTIONS.md, .clinerules-style rule files | Yes, after rewriting the format |
| MCP server configuration | Most mainstream harnesses speak MCP already | Yes, usually as-is |
| File and shell tool set | Every harness ships built-in tools | Yes, with behavioural differences |
| Custom / slash commands | Most support custom commands or script entry points | Yes, one by one |
| Plan mode / read-only planning | Some products have an equivalent | Partly |
| Hooks (run before or after tool calls) | No equivalent mechanism; rebuild with git hooks or wrapper scripts | You build it yourself |
| Subagents (parallel, isolated context) | Mostly nothing; people simulate it by opening several instances | Mostly lost |
| Tuning against a specific model | Does not exist | Lost by definition |
The seven-step migration
- Take inventory. Walk
~/.claudeand every project's.claudedirectory and list what you actually use: which commands, which hooks, which rule files. Most people find that only a handful of them matter. - Sort. Put each item into one of the three columns above: travels directly, needs rewriting, has no counterpart. The third column determines the real cost of this migration.
- Choose. Use columns two and three as the filter, not benchmark scores. You are not looking for the strongest harness; you are looking for the one that makes you lose the least.
- Move the rule files. Rewrite
CLAUDE.mdinto the target format. This pays off immediately because it is the main source of context quality. - Rebuild the hooks. Use git hooks (a pre-commit formatter, for instance) or wrapper scripts. Do not try to reach parity in one sitting — rebuild the one that hurts most and stop.
- Run one real task. Take a task you did last week and do it again on both sides. Compare steps taken, manual interventions, and whether rework was needed. That is more reliable than any impression.
- Keep a way back. Do not delete the old environment. Back up configuration, credentials and rule files, and keep both setups alive for at least two weeks.
What you will certainly lose
This section gets its own heading because it is the most consistently under-estimated, and it is what turns into "I wish I had known" two weeks later.
- Context isolation in subagents. Opening several terminals looks similar and behaves differently: whether the main context gets polluted, and whether subtasks can share state, do not come back.
- The enforcement of hooks. A wrapper script you wrote is easy to skip or forget; a built-in hook is nearly impossible to forget to run.
- Stability on long tasks. Running twenty minutes without drifting is engineering accumulated at the harness layer, not something a different model substitutes for.
- One consistent feel. Each harness invokes tools its own way, and your muscle memory will be misaligned for a while.
If you read those four and think "I do not actually use any of that", your pain is somewhere else — most likely model quality or cost. In that case changing only the model is enough, and no migration is needed.
Choosing by situation
No ranking, only filtering logic. The three common situations weight the criteria completely differently:
| Your situation | Weight this most | You can compromise on |
|---|---|---|
| Solo coding, care about feel | Tool-call stability, session recovery | Team features, audit logs |
| Team work, care about rules | Rule files, hook enforcement, auditability | Fancy interaction |
| Batch and automation | Headless mode, concurrency, scriptability | Interactive experience |
Running both in parallel
The least stressful migration is not a switch, it is a division of labour. Give it two to four weeks with both setups alive:
- Week one: the new harness only takes low-risk work — documentation, missing tests, small bug fixes. The goal is familiarity, not output.
- Week two: give it one complete small requirement, from reading the code to running it. Count how many times you intervened by hand.
- Week three: hand it the kind of task you dislike most — refactors, cross-file renames. Those expose stability problems fastest.
- Week four: decide. Either widen the share, or accept that it does not fit and fall back to changing only the model.
The point of the pace is that, whatever happens, you never risked a capacity cliff on a live project. And "it did not fit, I rolled back" is a legitimate result — migration is not a position to defend.
What is the biggest cost of migrating?
Not installation. It is rebuilding the conventions and workflows that grew on Claude Code. Rule files carry over after a format rewrite, hooks must be rebuilt with git hooks or wrapper scripts, and subagents mostly have no equivalent. Cost rises roughly linearly with how deeply you used the original.
What carries over completely?
Rule files and MCP connections are the most portable layer, because most mainstream harnesses support an equivalent concept. The first needs reformatting; the second usually reuses the same configuration unchanged.
Do I have to switch all at once?
No, and it is better not to. Split by task type, let the new harness take low-risk work first, and use two to four weeks of parallel running to build confidence before widening the share.