When Coding Agents Drift on Long Tasks: Compiling Subtask Context

In the motivating trace of the Spine preprint, a coding agent inspects 9 source files, its harness replaces the inspection history with a summary, and the agent then re-reads overlapping ranges from 7 of those files, with a later response revisiting 7 again. If your agent behaves like that, or announces completion while subtasks remain open, the fix is not a bigger context window. It is an explicit record of task state. The practical finding from the preprint and the tooling around it: for multi-hour, many-file runs, persist each subtask’s goal, completion status, and verification result somewhere the model will actually see again, and replace a finished subtask’s details with its returned result rather than a flat summary of everything that happened.

The preprint, from Jiahong Xiang, Kunqiu Chen, and Yuqun Zhang at Southern University of Science and Technology and Lingming Zhang at the University of Illinois at Urbana-Champaign, formalizes the idea as a compiled subtask tree inside a single run and benchmarks it: on SWE-Milestone with GPT-5.6 Sol, its SpineCodex integration improves Score by 11.8% over native Codex while cutting total cost by 32.4%, and matches a recursive-subagent baseline’s Score at 73.7% lower cost. Whether the compiled tree beats a plan file on disk is the open question, because none of the paper’s baselines is a plan file.

What drift looks like in a real trace

The preprint’s motivating example is worth reading closely because it is specific rather than impressionistic. An agent inspects nine source files as part of a task. Its harness then compresses the interaction history into a summary to fit the context window. From the paper’s Figure 2(a): “the agent inspects nine source files, and the resulting inspection history is replaced by a summary. The next response rereads overlapping ranges from seven of these files, and a later response revisits seven again.”

Seven of nine files re-read, twice. That is a concrete, countable measure of the behavior engineers colloquially call “losing the plot.” The token cost of re-exploration is the visible part; the subtler cost is that the re-read ranges only overlap with the originals, so the agent is not even reconstructing what it knew. It is re-deriving a similar-but-different picture and making downstream decisions on it.

The paper also documents a second failure mode: premature completion. Summarizing its cited observations (Deng et al., 2026; Young, 2025), it notes that when subtask state “must be recovered from reduced context, the model may lose track of progress, repeat exploration (Deng et al., 2026), or declare completion while work remains unfinished (Young, 2025).” One caveat on sourcing: those two citations are the paper’s own motivating references, so treat them as the preprint’s framing rather than independently verified measurements.

Why compaction loses exactly the wrong things

Compaction itself is not the villain. As the paper puts it, “a harness can compact earlier interactions to keep later inputs within the context window, while the reduced input must retain the information needed to continue unfinished work.” The preprint names Codex, Claude Code, and Pi as examples of coding-agent harnesses and states the compaction capability generically; among the systems it evaluates, Codex’s native context compaction is the documented instance. The problem is what a flat summary preserves: a topical digest of what happened, not a structural record of what is done, what is pending, and where to resume.

The paper is explicit about the gap: “reducing interaction history does not by itself maintain subtask relations, completion status, or where unfinished work should resume.” A summary that says “inspected the parser module and migration scripts” is topically faithful and operationally useless if the agent cannot tell from it that the parser update is half-finished, the migration is blocked on it, and the compilation check already passed.

This also applies to a more structured technique the paper discusses: plan, branch, return workflows such as FoldGRPO (Sun et al., 2025), which replace a completed branch’s intermediate interactions with its returned result. That is closer to the right shape, but the paper’s argument is that branch-level result replacement alone still does not track subtask relations or resumption points across a whole tree of work. Training-time techniques and harness-level compaction both attack the token budget; neither, on its own, maintains the bookkeeping.

What Spine compiles instead

Spine’s mechanism is to treat the subtask tree as a data structure and compile it into the agent’s context, rather than treating the transcript as the record of truth. Per the paper, the approach has the agent “replace completed subtasks’ details with their results while retaining information needed by unfinished parent tasks and leaving the choice of executing agents independent of the boundary.”

Two properties in that sentence deserve attention. First, replacement is per subtask, not per history segment: when the compilation check completes inside the parser update, its result replaces its details, and “the same agent continues the parser update, whose later result returns to the migration with other work still pending.” Finished work collapses to its verified outcome; unfinished work keeps whatever it needs to resume. Second, the boundary is agent-agnostic. Compiling state does not force a choice between one agent doing everything and a tree of subagents; it changes what any of them see.

That second property matters for how you evaluate this against what you already run, because the main alternative architectures isolate work in a different way entirely.

The alternatives are already on your machine

Before weighing a preprint mechanism, it is worth inventorying the state-management options that exist today, because they sit at different layers and are easy to conflate.

Filesystem truth documents. The Context Governance framework has a developer write a root document, PROJECT_BASELINE (“under 100 lines, pure business language, zero technical terms”), with derived tiers below it, so that “every technical standard remains traceable to the same root” and the project survives “session restarts, context compression, switching from one model/tool to another, long-running iterative development.” Its bootstrap script creates the baseline file plus CLAUDE.md / AGENTS.md / GEMINI.md entrypoints, with install guides for Claude Code, Codex, and Gemini CLI. Note the scope: this targets cross-session and cross-model drift, the failure where a new session reads a stale plan and treats it as current truth. That is a real and common failure, but it is a different failure from within-run nested subtask state. These approaches complement each other; neither substitutes for the other.

Recursive subagents. The paper describes this alternative directly: “Recursive subagent delegation instead assigns subtasks to child agents with separate contexts, which can in turn delegate further subtasks and return their results,” with Recursive Agent Harnesses (Lumer et al., 2026b) giving “each child a complete tool-using harness with its own workspace and context.” Isolation by construction: the child’s exploration never enters the parent’s context, only its result does. The tradeoff is coordination overhead and the fact that the parent still has to hold the tree of pending children somewhere.

Harness-managed persisted state. OpenHands Agent Canvas runs multiple agents in parallel, “each isolated in its own git worktree,” and connects to Claude Code, Codex, Gemini CLI, or any ACP-compatible harness (vendor-documented). The vendor page describes the current default as a single agent-server on your laptop, with Docker optional; in the multiple-Docker-sandboxes configuration, per the OpenHands repository, “each container mounts its conversation’s workspace and persisted state,” orchestrated through an Agent Server REST API, and the agent-canvas image referenced in the README there is version 1.34.0. This is workspace isolation and per-conversation persistence, which is genuinely useful for concurrent long-running work, but it is not within-run context management. A single agent in its own worktree still compacts its transcript and can still re-read seven files. And since these runs execute locally, whether via Codex CLI, “a coding agent from OpenAI that runs locally on your computer,” or another harness, the filesystem option is always available: the agent can write its own state files to disk and re-read them cheaply.

What to persist, where, and when it pays off

Pulling the evidence together, the decision decomposes into three questions.

What to persist per subtask. The paper’s failure analysis names exactly the fields that flat summaries lose: the subtask’s goal, its completion status, and where unfinished work should resume. I would add the verification result (which check passed, and how it was run) as a first-class field, because the worked example’s collapsed unit is a verified result, not just a claim of done. A subtask record of {goal, status, verification, resumption point} is the minimal structure that distinguishes “I read about this” from “this is finished and here is the proof.”

Where it lives. Three viable homes, with different reach:

When recompiling pays off. The trigger is measurable re-exploration. The paper’s trace gives you a diagnostic: after a compaction event, count how many files the agent re-reads that it already inspected. If the answer looks anything like seven of nine, the run is paying a re-derivation tax that a persisted subtask record would mostly eliminate. For short runs under an hour with few files, compaction alone is probably fine, and the overhead of maintaining structured state is not justified. The crossover point for your tasks is something only your own logs can establish. The regime the authors care about is marked by FrontierSWE (Chu et al., 2026), a benchmark of open-ended implementation, performance optimization, and research tasks; there, SpineCodex improves Mean@5 on eight of the ten tasks with GPT-5.6 Sol and both Mean@5 and Best@5 on six tasks with Grok 4.6, at a total cost of $802.45 against Codex’s $859.78 under the first model.

What the numbers show, and what they do not

The preprint’s evaluation is broader than its motivating trace suggests: three benchmarks, four models, two harnesses. On SWE-Milestone with GPT-5.6 Sol, SpineCodex resolves 19 of 98 milestones against 14 for native Codex, lifting Score from 38.1% to 42.6% while cutting cost from $681.22 to $460.77; with Grok 4.6, Score rises 13.8% and resolved milestones go from 12 to 14. Against the other context-management baselines on the same benchmark and model, SpineCodex improves Score by 16.7% over AgentDiet and 14.8% over Context Folding, at 58.1% and 22.7% lower cost respectively. Recursive Subagent is the instructive comparison: per the preprint, it nearly matches SpineCodex’s Score (42.4% vs 42.6%) and resolves 17 milestones, but pushing every subtask boundary through delegation makes child agents 75.5% of its 32,650 model requests, against 8,792 requests in total for SpineCodex, and drives cost to $1,749.73 against $460.77. Isolation works; paying for it with an agent per boundary is what costs. The AgentDiet run is also a second documented case of the opening trace’s failure mode: cutting source-inspection history from 11.7k to 1.6k tokens while implementation was pending led to repeated rereading, 12 milestones resolved against Codex’s 14, at higher cost.

Elsewhere the pattern holds. On ProgramBench, the average test-pass rate rises 17.3% with GPT-5.6 Sol and 10.2% with Grok 4.6, with two of 50 tasks fully resolved against none for Codex under the first model. On FrontierSWE, Mean@5 improves on eight of ten tasks with GPT-5.6 Sol and both metrics on six tasks with Grok 4.6; on libexpat-to-x86asm, Mean@5 and Best@5 go from zero to 0.1707 and 0.5444. The Pi plugin, evaluated with Gemini 3.8 Flash and the open-weight Qwen 3.8 27B, improves SWE-Milestone Score by 9.5–17.5% and ProgramBench pass rate by 4.3–8.7% over native Pi. Cost falls in five of the six benchmark, model settings, by 6.7–37.9%; the exception is ProgramBench with GPT-5.6 Sol, where the pass-rate gain comes with 5.4% higher cost.

Two ablations isolate the mechanism rather than the wrapper. Limiting scopes to one level of nesting, and stripping boundary cues from model inputs while keeping runtime compilation, each cost 7.7–27.3% Score across three SWE-Milestone projects; the boundary ablation alone surges average input per request by 64–97% and raises cost 30–42%. The runtime’s own measurements point the same way: model input is shorter after 223 of 224 Close calls, with a median decrease of 23,045 tokens, and in a recorded Nushell migration run one outer return cut input from 65,815 to 19,207 tokens. Explicit boundaries in the context, not just structure in the runtime, are doing part of the work.

What the numbers do not settle: every figure comes from one preprint’s own runs, on three benchmarks, four models, and two harnesses. Claude Code, named alongside Codex and Pi as a coding-agent harness, is not among the evaluated systems. No baseline is a plan file or checklist, so the simplest intervention of all, a state file the agent updates itself, has never been measured against the compiled tree. Adoption would not fill that gap either; the GitHub-star figures the paper cites for Codex and Pi measure the harnesses’ popularity, not their drift behavior.

A pilot protocol, not a leap

Given that, the honest recommendation is staged. First, stop treating transcript compaction as sufficient on long runs: persist {goal, status, verification, resumption point} per subtask, in a plan file the agent updates as it works if your harness has nothing better. This is cheap, works with every harness mentioned here, and directly targets the failures the preprint documents. Second, keep cross-session truth in filesystem documents, as Context Governance formalizes, because within-run state and cross-session truth are different problems with different solutions. Third, if you run genuinely long tasks, pilot the Spine mechanism on your own work. The paper’s numbers are real but single-source, its baselines do not include a plan file, and both integrations are open source and installable: npm install -g @spinejit/spine-codex for Codex, pi install npm:@spinejit/pi-spinejit for an existing Pi installation. Measure re-read rates and premature-completion incidents before and after. If the compiled tree does not beat your plan file on your tasks, the plan file wins, and you will have spent a few runs learning that instead of a migration.

Frequently Asked Questions

What specific fields should be persisted for each subtask to prevent drift?

The paper’s failure analysis names exactly the fields that flat summaries lose: the subtask’s goal, its completion status, and where unfinished work should resume. I would add the verification result (which check passed, and how it was run) as a first-class field, because the worked example’s collapsed unit is a verified result, not just a claim of done. A subtask record of {goal, status, verification, resumption point} is the minimal structure that distinguishes “I read about this” from “this is finished and here is the proof.”

How can I determine if my coding agent is suffering from context drift?

The trigger is measurable re-exploration. The paper’s trace gives you a diagnostic: after a compaction event, count how many files the agent re-reads that it already inspected. If the answer looks anything like seven of nine, the run is paying a re-derivation tax that a persisted subtask record would mostly eliminate.

How do I install the Spine integration for Codex or Pi?

both integrations are open source and installable: npm install -g @spinejit/spine-codex for Codex, pi install npm:@spinejit/pi-spinejit for an existing Pi installation.