Rohit has been switching between coding agents frequently this month. When Claude Code hit its session limit, he switched to Codex, pasted three hours of context into a blank window, and acted like nothing had changed. He says what you lose isn't chat history—it's decisions.

He calls this cost the "reset tax". It's not just the time spent writing a handoff summary; it also includes re-reading the repository, re-making decisions, repeating tool calls, missing constraints, and going through another round of human correction. When the previous agent already confirmed that a certain interface can't be modified, a certain approach has already failed, and a certain test is the acceptance threshold, the new agent starts from scratch and does it all over again.

Rohit's solution: give all coding agents the same audited task contract. It's not about sharing a brain. The core idea is to preserve the native session of each harness while sharing a single verified task state. You can think of it as a machine-readable handoff document: it only records verified conclusions, not casual chat or intermediate processes.

## Route models and harnesses separately

Models handle reasoning, harnesses govern tool loops: system prompts, tool definitions, repository discovery, permissions, context ordering. The same model behaves differently in different harnesses.

The differences are concrete. Claude Code loads CLAUDE.md from the directory hierarchy, and discovers the file when entering a subdirectory; Codex looks for project instructions starting from the project root, with a default merge cap of 32 KiB; Zed finds the first matching project instruction file in document order; pi only exposes four tools by default: read, write, edit, bash. These differences change the prompt prefix, available actions, and execution boundaries—they are not just surface-level differences.

So routing has two independent choices: pick a model, pick a harness. Kimi K3 and DeepSeek-V4-Pro are candidate models; pi, OpenCode, Codex CLI, and Claude Code are candidate harnesses. Rohit reminds us not to treat any single combination as "the best on the internet"—model releases and harness behaviors change too fast, you should test on your own repository.

## Copying the entire session is the wrong abstraction

The most obvious design people think of is putting all content every agent has seen into a shared database. Rohit says this has three problems.

**Context isn't free.** A 2026 study evaluated repository-level context files, finding that LLM-generated context files do not produce a statistically significant improvement in solve rate, and increase average cost by about 20% on SWE-bench and about 23% on CTXbench. The only information worth sharing is that which costs a lot to rediscover: approved decisions, clear constraints, evidence of failure, current artifacts, acceptance results.

**Native sessions are not an interoperability layer.** Different harnesses have different persistence formats. Codex can import part of the chat history from Claude Code or Cursor, but /import can't be used mid-task. This is not a standard for real-time execution state.

**Unverified memory amplifies errors.** Rohit cites research from AgentPoison: just a small number of malicious memory entries can mislead downstream agents, while aggregate performance barely changes. So retrieved memory must be treated as untrusted input, and only enter the shared state after verification.

## Task contract: small and versioned

Rohit recommends that the shared object is not a full transcript. It is a small, versioned "task contract" that contains:

- Original objective and non-negotiable constraints

- Machine-checkable acceptance criteria

- Scope of files, commands, network access, and permissions

- Accepted commits and related artifacts

- Decisions with source, scope of applicability, and re-verification rules

- Failed attempts and evidence of failure

- Current blockers and dependencies

- Current phase and assigned model-harness route

- Monotonically increasing state version

The contract explicitly excludes every line of content from the previous round of conversation. The next executor doesn't need the conversation history, only the verified results of the conversation.

Example JSON:

```json

{

"task_id": "auth-refactor-2026-08-19",

"state_version": 12,

"objective": "Replace server-side sessions with signed access tokens",

"acceptance": [

{"id": "A1", "check": "pytest tests/auth", "required": true}

],

"scope": {

"write_paths": ["src/auth/**"],

"forbidden_paths": ["src/billing/**"]

},

"accepted_commit": "a91f3c2",

"decisions": [],

"failed_approaches": [],

"phase": "implementation",

"blockers": ["Refresh-token rotation policy is unresolved"],

"route": {

"model": "

"harness": "

}

}

```

## Control plane: plan, execute, audit, commit

There are four roles in the architecture:

- Planner: Propose the next bounded work unit based on the objective and current state

- Controller: Deterministic code that owns the canonical state, verifies scope, permissions and versions, creates isolated worktrees, and atomically accepts or rejects changes

- Executor: The selected model-harness combination, modifies code in the candidate environment, cannot write to the canonical state

- Auditor: An auditor with a fresh context, checks the candidate environment against the contract, can run tests, and has read-only access to the canonical state

The operational rule is: planner proposes, executor modifies the candidate environment, auditor verifies, and only the controller can commit.

Rohit notes this design is based on the Manage-Execute-Audit pattern from LongHorizon-Harness. Same-model experiments improved accuracy from 51.8% to 80.7% on WeaveBench, and from 69.7% to 77.2% on Terminal-Bench 2.1. This is a preprint, and cannot be taken as independent evidence for cross-vendor routing, but it supports the narrower conclusion: explicit, audited task state improves long-horizon execution.

## You can't move KV cache—what you move is semantic state

Many people think of "model routing" as taking the KV cache with you. Rohit says this isn't possible. The raw KV state is the model's internal attention tensor, which depends on the model architecture and the exact prefix, and hosted APIs generally don't expose it as a portable object. Prompt caching also requires an exact prefix match. Switching harness changes system instructions, tool schemas, and order—even for the same model, the cache will likely miss.

Research on cross-model KV cache mapping is limited to within model families, and requires the original cache plus a mapping table—it's not a general solution.

So the design acknowledges this boundary:

- Static contract prefixes remain stable within a single route

- Changing task state is placed after the static instructions

- One phase uses a fixed model-harness pair

- Estimate cold start cost before switching

- Only switch from audited checkpoints

- Pass semantic state, don't depend on KV state

Rohit added a note in a reply: even if you only use Claude Code, changing the effort level will alter the KV cache. Model routing tools can't solve this—the only solution is semantic memory plus a routing system.

## Boundaries must be defined in code

Rohit's default assumption is: all model outputs can be wrong, including outputs from the planner and auditor. So boundaries are drawn with deterministic code:

- State storage is owned by the controller, the executor only gets a read-only projection

- Verify change paths after execution, don't just verify before execution

- Auditors need independent context and independent evidence

- Concurrent updates use state versioning and atomic commits

- Secrets are not put into the contract, they are passed by reference via the execution environment

- Permission expansions, destructive operations, production access, and irreversible migrations require manual approval

Codex documentation also describes hooks as guardrails, not a complete execution boundary. worktree can isolate repository files, but it can't isolate ports, databases, external services, or shared caches.

## You have to test separately whether routing is worth it

Rohit recommends testing with at least three control groups:

- A: Fixed combination, native session, no external control plane

- B: Fixed combination, add audited state

- C: Routing executor, switch combinations by phase

- D (optional): Use a different model or harness for high-risk audits

Test with the actual tasks you work on, control for permissions, timeouts, acceptance tests, and dollar caps. Record task success rate, per-task cost, wall-clock time, number of switches, time spent rebuilding context, audit rejection rate, scope violations, and human escalations. Token counts across providers can't be compared directly, since tokenization and pricing differ—you need to report both model-specific token usage and normalized dollar cost.

If the cost of the control plane, auditing, and cold start is higher than the savings from routing, a fixed combination should be the default. This architecture is only useful when it beats the reset tax it introduces.

## One shared contract, not shared consciousness

Rohit's conclusion: don't try to merge all transcripts, tool calls, prompts, and caches into a single generic session. Preserve the native advantages of each harness, and put a narrow control plane on top of them. Harnesses keep their own native sessions, what's shared is the verified state.

He wrote in the tweet: `switch from claude code to codex mid-task and lose nothing. move semantic state, never KV state`.

Sources:

- Rohit's original article: https://x.com/i/article/2083341896789995520

- Other citations: Evaluating AGENTS.md, LongHorizon-Harness, A Deterministic Control Plane for LLM Coding Agents, Cross-Model KV Cache Transfer, AgentPoison, OpenAI prompt caching, Codex import/hooks documentation