---
title: "Rohit on X: Coding Agents and Semantic State Management"
url: https://stacklist.com/card/ee0e8b2d-5e78-4028-ae9a-c42f4505d890
source_url: "https://x.com/rohit4verse/status/2090135919714324876?s=12"
stack: https://stacklist.com/c/technology/stack/1659549d-373d-4391-ba12-5a14d40c19ed
summary: "Rohit4Verse discusses the reset tax problem when switching between coding agents mid-task and proposes maintaining shared semantic state across different model-harness pairs. The solution involves routing appropriate models and harnesses together while preserving verified task state without requiring a universal transcript."
tags: "coding-agents, semantic-state, model-routing, task-continuity, harness-architecture, ai-engineering"
key_entities: "Rohit (person), Claude Code (technology), Codex (technology), Zed (technology), pi harness (technology), Kimi K3 (technology), DeepSeek-V4-Pro (technology), OpenCode (technology), reset tax (concept), semantic-state-preservation (concept)"
classification: "analysis"
content_hash: "sha256:69cb7264aa0de2381297888e68eedae5aeaace7efb2dabb24cf88a906da0025d"
acp_version: "0.2"
token_counts_approximate: 4456
visibility: public
agent_accessible: true
status: "final"
---

# Rohit on X: Coding Agents and Semantic State Management

Rohit @rohit4verse switch from claude code to codex mid-task and lose nothing. move semantic state, never KV state How to give every coding agent the same second brain Use the right coding agent for every task without losing the decisions, constraints, and progress already made. 1. The reset tax One coding agent may be excellent at exploring an unfamiliar repository. Another may be faster at a bounded migration. A lightweight harness may be enough for a five-line patch, while a long debugging session may justify a more capable model and a richer tool loop. The problem begins when the task moves between them. Suppose one agent has already established three facts: an interface cannot change, a failed approach must not be repeated, and a particular test is the acceptance gate. When a second agent starts from a fresh session, those facts are not automatically available. It rereads the repository, reconstructs the plan, and may reopen decisions that were already settled. Switching back creates the same problem in reverse. This is the reset tax. It is not only the time spent writing a handoff summary. It includes repeated repository exploration, contradictory decisions, duplicated tool calls, missed constraints, and another round of human correction. The usual response is to choose one coding agent and keep the entire task inside it. That preserves continuity, but it also forces one model-harness pair to handle every phase of the job. There is a better target: keep each harness's native session, but give all of them access to the same verified task state. The shared object should not be a universal transcript or an unrestricted memory database. It should be a small, versioned contract that records what the task is, what has been verified, what remains, and what the next agent is allowed to do. 2. Route the model and the harness together A model and a coding harness are different parts of the system. The model supplies inference. The harness determines the agent loop around it: system instructions, tool definitions, repository discovery, permissions, compaction, retries, and the order in which context reaches the model. The same model can therefore behave differently when its tools and context are assembled by different harnesses. The differences are concrete. Claude Code loads applicable CLAUDE.md and CLAUDE.local.md files from the directory hierarchy and discovers files below the working directory when it enters those subtrees. Codex discovers project instructions from the project root down to the working directory, includes at most one applicable file per directory, and uses a 32 KiB combined limit by default. Zed uses the first matching project-instruction filename from its documented list. The deliberately minimal pi harness exposes four tools by default: read, write, edit, and bash. (Claude Code, Codex, Zed, pi) These are not cosmetic differences. They change the prompt prefix, available actions, enforcement surface, and amount of context competing for attention. That gives the router two independent choices: Which model is appropriate for the task's difficulty, risk, latency target, and budget? Which harness provides the right tools, permissions, repository behaviour, and execution loop? A lightweight model-harness pair may be the right route for a small, well-specified change. A more capable pair may be justified for architecture, ambiguous debugging, or a high-risk migration. Those mappings should be treated as local hypotheses, not universal rankings. Model releases and harness behaviour change too quickly for a static internet leaderboard to decide the policy for your repository. This also keeps product categories honest. Kimi K3 and DeepSeek-V4-Pro are model candidates; pi, OpenCode, Codex CLI, and Claude Code are harness candidates. A policy may evaluate combinations such as a lower-cost reasoning model behind a minimal harness or a higher-budget model behind a tool-rich harness. The pairing becomes a routing option only after it is tested on representative work, not because one configuration is declared universally "best." 3. Why copying the whole session is the wrong abstraction The most obvious design is a shared database containing everything every agent has seen. Each harness reads the same history and appends its own observations. That design creates three problems. Context is not free A 2026 study evaluated repository-level context files across SWE-bench and CTXbench. LLM-generated context files produced no statistically significant improvement in resolution rate in the reported experiments, while average cost increased by roughly 20% on SWE-bench and 23% on CTXbench. Developer-written context performed somewhat better, but its average improvement was also not statistically significant. The useful conclusion is narrow: broad repository summaries that duplicate information already available in the code can consume tokens without improving outcomes. (Evaluating AGENTS.md) That result does not show that persistent task state is useless. It shows why the shared state should contain information that is expensive or dangerous to rediscover: approved decisions, explicit constraints, observed failures, current artifacts, and acceptance evidence. Native sessions are not an interoperability layer Coding harnesses persist conversations, tool calls, and internal state in different formats. Some migration paths exist. For example, Codex can import selected recent chats and configuration from Claude Code or Cursor, but its /importcommand is unavailable during a running task. That is useful migration support, not a standard for transferring a live execution state between arbitrary harnesses. (Codex import documentation) Trying to normalize every provider's full session would couple the system to private schemas and implementation details. A portable task contract is smaller and more stable. Unverified memory compounds mistakes If every executor can directly write durable memory, a mistaken inference can become input to every later agent. Retrieval-memory poisoning research has shown that a very small proportion of malicious entries can steer downstream agents while leaving aggregate benign performance nearly unchanged in the studied settings. The experiments covered driving, question answering, and healthcare agents rather than coding harnesses, so they do not measure this architecture directly. They still establish the relevant security principle: retrieved memory must be treated as untrusted input until it is verified. (AgentPoison) The goal is therefore not shared consciousness. It is shared, audited state. 4. The portable unit: an audited task contract The contract separates information into three classes. The distinction between authoritative and untrusted data matters. An executor can report that it completed a migration, but that report is only a claim. The auditor must inspect the resulting environment, diff, tests, and artifacts before the controller promotes the claim into canonical state. A useful contract contains: the original objective and non-negotiable constraints; machine-checkable acceptance criteria where possible; the file, command, network, and permission scope; the accepted repository commit and relevant artifacts; decisions with provenance, applicability, and revalidation rules; failed approaches with evidence explaining why they failed; current blockers and dependencies; the current phase and assigned model-harness route; a monotonically increasing state version. It deliberately excludes material that is expensive, sensitive, or likely to bias the next agent. The next executor does not need every line of the previous conversation. It needs the verified result of that conversation. 5. The control plane: plan, execute, audit, commit The architecture has four responsibilities. Planner. Proposes the next bounded work unit from the original goal and current task state. This can be an LLM, but its proposal is not automatically authoritative. Controller. Deterministic code that owns canonical state. It validates the proposed scope, enforces budgets and permissions, creates isolated worktrees, checks state versions, and atomically accepts or rejects audited changes. Executor. A selected model-harness pair operating inside a bounded environment. It may change the candidate worktree and return an execution report, but it cannot write canonical state. Auditor. A fresh-context agent that inspects the candidate environment against the contract. It may run tests in a disposable copy because tests can write files. Its authority over canonical state remains read-only. This design builds on the Manage-Execute-Audit pattern described by LongHorizon-Harness. That work keeps task state outside execution, gives the executor a bounded subtask, and advances state only after an auditor independently inspects the environment. Its matched-model experiments report improvements from 51.8% to 80.7% on WeaveBench and from 69.7% to 77.2% on Terminal-Bench 2.1. Those are results from a recent preprint, not independent proof of cross-vendor routing. They support the narrower claim that explicit, audited task state can improve long-horizon execution with the same underlying model. (LongHorizon-Harness) The deterministic controller is an additional enforcement layer. A separate 2026 control-plane proposal makes the underlying argument directly: governance checks such as hashes, state transitions, and permission rules should live in ordinary testable code rather than being delegated to another nondeterministic model. (A Deterministic Control Plane for LLM Coding Agents) The operational rule is simple: The planner proposes. The executor changes a candidate environment. The auditor verifies. Only the controller commits. 6. What the state and adapter actually look like The canonical state can live in a controller-owned sidecar store or database. Executors should receive a read-only projection of it rather than write access to the source of truth. Every supported harness then implements the same small adapter boundary: The adapter does not replace the harness's native loop. It translates a stable control-plane contract into that harness's invocation format and normalizes observable results back out. The controller can then run one round without trusting any model to enforce the boundary: Compare-and-swap on state_version prevents a stale round from overwriting newer state. If parallel executors are allowed later, each runs from the same declared base commit and must pass conflict resolution plus a fresh audit before promotion. 7. Route phases, not turns The first router should be a versioned policy, not another unconstrained agent. The model and harness names should come from your own evaluations. A belief such as “a minimal harness with a cheaper reasoning model is enough for bounded changes” belongs in the policy as a hypothesis until telemetry supports it. Three routing rules matter most: Route before a phase begins. Do not switch models every few turns. Keep session affinity. Stay with the selected pair until the phase finishes, fails, or crosses a risk threshold. Switch only at a verified checkpoint. The receiving pair starts from an accepted commit and audited contract, not a half-finished narrative. The switch function also needs one common unit. Tokens, cache-hit ratios, latency, and failure probabilities cannot be added directly. Convert them into expected monetary or task-value terms, with explicit weights, before comparing routes. 8. Treat the KV cache as non-portable There are two related concepts that are easy to mix together. Raw KV state consists of model-internal attention tensors produced during prefill. It depends on the model architecture and the exact processed prefix. Hosted APIs generally do not expose it as a portable artifact. Prompt caching is a provider feature that reuses eligible matching prompt prefixes. OpenAI documents that cache hits require exact prefix matches and recommends placing stable instructions and examples first while appending variable content later. Images and tool definitions must also match. (OpenAI prompt caching) Changing harnesses often changes system instructions, tool schemas, ordering, or other prefix content. Even when both harnesses call the same model, those differences can prevent prompt-cache reuse. That is a cache-affinity problem, not proof that one harness literally exported and lost a raw KV tensor. Research has demonstrated cross-model KV-cache mapping within model families, but the cited work explicitly restricts itself to within-family transfer and assumes access to raw caches plus a mapping between source and target representations. It is not a general solution for switching between ordinary hosted coding agents. (Cross-Model KV Cache Transfer) Design around that boundary: keep the static contract prefix stable within each route; append changing task state after static instructions; pin a phase to one model-harness pair; estimate the cold-start cost before switching; switch only from an audited checkpoint; transfer semantic state, never depend on transferring KV state. The second brain carries meaning, not model internals. 9. Boundaries that must remain code The orchestration layer should assume that every model output can be wrong, including outputs from the planner and auditor. Canonical-state ownership. The state store is controller-owned. Executors receive a projection and return candidate artifacts. Filesystem scope. Validate changed paths after execution, not only before it. Tool hooks are useful for early interception, but Codex documentation explicitly describes hooks as a guardrail rather than a complete enforcement boundary. Combine them with sandboxing, operating-system permissions, and isolated worktrees. (Codex hooks) Audit independence. Fresh context and independent evidence are required. A different model or harness can be selected for high-risk review, but diversity is a policy choice, not a prerequisite for every audit. Concurrent updates. Use state versions and atomic promotion. Worktrees isolate repository files; they do not automatically isolate ports, databases, external services, or shared caches. Secrets. Do not place credentials, raw environment dumps, or unrestricted tool output in the portable contract. Pass secret references through the execution environment and keep their values outside model-visible state wherever possible. Human authority. Permission expansion, destructive operations, production access, and irreversible migrations should stop at an explicit approval gate. 10. How to test whether routing is worth it Audited state and cross-harness routing are separate ideas. Evaluate them separately. Use at least three arms: A: fixed pair, native session. One model-harness pair completes each task without the external control plane. B: fixed pair, audited state. The same pair runs behind the planner-controller-executor-auditor loop. C: routed executors. Keep the controller, planner, and auditor configuration from B, but allow the executor pair to change by task phase. D, optional: diverse audit. Repeat C with a different model or harness for selected high-risk audits. Holding the auditor fixed between B and C isolates the value of executor routing. D then measures whether auditor diversity adds anything. Use tasks representative of the work you actually perform, supplemented by public benchmark subsets where appropriate. Hold permissions, timeouts, acceptance tests, and dollar ceilings constant. Cross-provider token counts are not directly comparable because tokenization and pricing differ, so report model-specific token usage alongside normalized dollar cost. Measure: task success and acceptance-test pass rate; cost per accepted task; wall-clock time; number of harness switches; time spent reconstructing context; audit rejection and useful-intervention rates; scope violations and human escalations; cache-hit data when providers expose it. Treat a small run as a pilot. Use repeated trials and task-level confidence intervals before claiming a general improvement. Report the quality-cost-latency frontier rather than selecting one arbitrary threshold. The architecture is useful only if it beats the reset tax it introduces. If the controller, audits, and cold starts cost more than the routing saves, the fixed pair should remain the default. 11. One shared contract, not one shared consciousness The best coding agent changes with the work. The state that matters should not. Do not attempt to merge every transcript, tool trace, prompt, and cache into one universal session. Preserve each harness's native strengths and place a narrow control plane above them. The durable layer is an audited task contract: objective, acceptance criteria, scope, verified decisions, accepted artifacts, failed approaches, blockers, and evidence. A planner proposes the next unit. A selected executor works inside a bounded environment. A fresh-context auditor checks the result. Deterministic code decides what becomes canonical. Harnesses keep their native sessions. They share verified state. Sources Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks A Deterministic Control Plane for LLM Coding Agents Cross-Model KV Cache Transfer in LLM Families AgentPoison: Red-teaming LLM Agents via Poisoning Memory or Knowledge Bases OpenAI prompt caching Claude Code project memory Codex project instructions Codex import from another agent Codex hooks Zed project instructions pi coding-agent documentation Kimi K3 documentation DeepSeek-V4-Pro announcement 5:56 PM · Aug 19, 2026 285.4K Views 39 28 244 713