What only Claude Code does, and what goes away when you leave
The first reaction to a ban is "replace it"; two weeks later many are back. Rarely sentiment: they never worked out which part they relied on, so migration binned the critical part and kept the replaceable one.
Three layers: the agent loop's stability, the extension points (CLAUDE.md, subagents, hooks, MCP), and the client-model tuning. A new harness costs part of the first and third; a new model costs the third. Whether the extension points travel depends on the target harness.
Three things, kept apart
They get mixed into one answer, so the answers never agree:
- The model reasons and sets the ceiling; swapping the backend swaps this layer.
- The harness makes a model into an agent that reads files, edits code and runs commands; it sets the floor and the stability, and swapping the client swaps this layer.
- The conventions:
CLAUDE.md, team norms, hooks, custom commands. Assets that can travel, except every harness has its own format.
Layer one: the agent loop
Hardest to quantify, easiest to underrate. A coding agent's feel depends on how many steps it gets right in a row inside one task: read the file, locate the fault, edit, run the tests, read the error, edit again. One drifted step and the task flies off.
Stability shows up in four places:
- Tool-call format fidelity. Emitted arguments still parse, without drift.
- Self-correction after failure. A command errors; it reads the error and retries differently.
- Context on long runs. Twenty minutes in, does it still remember the opening constraints?
- Hands off untouched code. A wide refactor changes the lines that need changing, not whole files.
None of it improves just because the model is bigger; orchestration and compaction do that work.
Layer two: four extension points
The real moat: it turns individual feel into a team asset.
1. CLAUDE.md: project conventions as executable context
A Markdown file in the repo describing code style, directory conventions, common commands and prohibitions. Its value is not prompting the model but freezing tacit team knowledge into a versioned file: newcomers, CI agents and the next engineer read the same conventions.
Portable: most harnesses support a similar rule file (AGENTS.md). Different format, same idea; the mapping is in the migration guide.
2. Subagents: parallelism and context isolation
Split a large task across sub-agents with separate contexts. The speed-up is nice; the isolation matters more: a sub-task reading five thousand log lines does not pour them into the main context.
The worst-covered capability on open harnesses: most alternatives have no true equivalent, and several terminals by hand is worse, with no shared state.
3. Hooks: pinning the workflow around tool calls
Run your own script on an event: format after an edit, intercept a dangerous command at the permission prompt, notify when the task ends.
It turns "remember to" into "impossible to forget", which is worth a lot on a team, and it is the layer that says this is for engineering teams rather than for a demo.
4. MCP: bringing outside systems in
One protocol for databases, monitoring, internal APIs and ticketing, and the most cross-harness compatible layer: most mainstream alternatives support it, making it the easiest asset to carry across.
Layer three: tuning to the model
An invisible fitting sits between harness and model: system-prompt wording, tool-description grouping, compensations for one model's behaviour.
Swap the model and the fitting shows:
- Prompt-cache hit rate falls. A different backend caches differently, so long context is billed repeatedly.
- Thinking blocks handled inconsistently. Reasoning that does not match the client's expectation is truncated or treated as body text.
- Tool-call style differs. Some models emit several calls at once, others one at a time; a client adapted to one makes the other look stupid.
- Context-window utilisation. Same nominal window, different usable fraction.
Nothing fatal, all discovered after migrating; testing for it is in the gateway guide.
The drawbacks, plainly
An article with only advantages is an advert. The structural drawbacks:
- Terms and region binding. Why this series exists, and the only drawback that can take everything away at once.
- Not cheap. Under heavy use the subscription quota is the real bottleneck.
- Strong lock-in. Conventions, hooks and commands grow on it, so migration cost rises with depth of use.
- One model. Boilerplate and a hard bug get the same one, which is not cost-effective.
That is the best argument for the model-only route: cheap models for bulk work, expensive ones for hard parts.
What you lose: one table
Read this before migrating.
| Capability | What it buys you | What replaces it on an open harness | How much you lose |
|---|---|---|---|
| Agent-loop stability | Multi-step tasks stay on target; failed steps recover | Nothing direct: the target harness's orchestration | May drop, depending on the alternative |
| CLAUDE.md conventions | Team conventions as versioned context for newcomers and CI | A similar rule file such as AGENTS.md | Portable: rewrite the format, keep the content |
| Subagents | Parallelism and isolation, so long logs stay out of main context | Mostly nothing: several terminals, no shared state | The biggest loss; no true equivalent in most |
| Hooks | Format, intercept, notify, with nobody remembering | git hooks or wrapper scripts you write | Rebuild labour; partly reproducible |
| MCP connectors | Databases, monitoring, APIs, ticketing: one protocol | Supported by most mainstream alternatives | Almost nothing; easiest to carry |
| Tuning to the official model | Cache hits, thinking blocks, tool-call style, usable context | None: the new backend has quirks of its own | Lost either way; a swap buys model choice |
| Terms and region risk | Nothing; this is the cost side of the ledger | A non-Anthropic client sits outside the region list | Lifted by a harness switch, not a model swap |
Counter-intuitively, the model-only route keeps the most: everything except the model is still there. The price is that terms risk stays, since the client is still official; the gateway guide weighs that trade.
Who should not migrate
Three questions, in order:
- Is your pain "might get banned" or "already banned"? If it is a worry, do the consistency work first (the checklist) instead of migrating.
- Do you depend on the extension points or the model? If hooks, subagents and team conventions matter most, you care about the harness, and a model swap is the better value.
- How long a dip can the team absorb? Migration usually costs two to four weeks; mid-project, run both setups side by side.
If all three point at the harness, migrate, and expect a fortnight of tuning rather than shipping.
Is Claude Code's advantage the model or the harness?
Separate layers: the model sets the ceiling, the harness sets the floor and stability, and CLAUDE.md conventions are a third asset belonging to neither.
What actually degrades when I move to another harness?
Agent-loop stability, subagents, hooks, and client-model tuning. CLAUDE.md and MCP travel; hooks need rebuilding; subagents mostly have no equivalent.
Does switching only the model keep the extension points?
Yes: the client is unchanged, so CLAUDE.md, subagents, hooks and MCP stay. You lose the tuning and keep the terms exposure.
Who should not migrate?
Anyone whose pain is a fear rather than a ban, anyone mid-project, and any team that cannot absorb two to four weeks of lower output.