StateTape: Action-Conditioned Evidence Lifecycle Modeling for Long-Horizon Coding Agents

What it claims

Coding agents accumulate context that their own edits make wrong, and text-based maintenance (masking old observations, summarizing past a size limit, model-based pruning) cannot see this because it never looks at code structure. The paper measures the gap first. On TraceBench, 73.4% of the tokens Claude Code holds before an edit are not needed for that edit, and 58.5% of the tokens the edit does need are absent. StateTape keys context maintenance to each write: the symbols a write changed decide what leaves the context and what enters it.

How it works

The paper treats each context record as a claim about the repository. A record carries its text, a referent and an entry step. The referent can be a byte range, a symbol, a query's result set, or the repo state a test ran under.

Only writes can falsify a record. So staleness is monotone: without intervention the stale set only grows, and it grows with the number of edits, not the number of steps.

Three components run inside the agent harness:

1. Code graph. A symbol-level graph of definitions and call edges, updated at every write. It puts writes and held records at the same granularity. Editing load_config should mark that function's held copy stale, not every definition in the file.
2. Tape. Logs which symbols each write changed and nominates every held record the change could have falsified.
3. Manager. A small model that does two things: - Settles cases the write log cannot decide, and evicts records that are stale or have lost their callers. - Retrieves unread code by walking the graph outward from the changed symbols, such as new callees and callers that must now change.

flowchart TD
  W[Agent write] --> G[Update code graph]
  G --> T[Tape: changed symbols]
  T --> N[Nominate possibly-falsified records]
  N --> M{Manager decides}
  M -->|stale / lost caller| E[Evict]
  M -->|still valid| K[Keep]
  T --> R[Walk graph from changed symbols]
  R --> A[Retrieve missing callers/callees]
  E --> C[Rewritten context]
  K --> C
  A --> C

Evidence

The visible text covers only the TraceBench motivation study:

• Setup: an unmodified Claude Code with Opus 4.8, run on 48 SWE-EVO instances from seven repositories. Trajectories were cut before each edit burst, giving 403 labeled decision points.
• Context growth: context grows from 5.9k tokens before the first edit to 28.6k after the thirtieth. The unneeded portion grows from 4.4k to 23.0k tokens, or 74% to 80% of what is held. A larger window does not absorb it.
• Staleness: stale records make up 72.3% of the unneeded tokens.
• Coverage: context covers 41.5% of gold tokens on average. Missing evidence is usually one call edge from the edit site, not the edit site itself.

The abstract claims the best resolve rate in every configuration (six agents, three edit-heavy benchmarks, five comparison methods) with little overhead. The fetched text gives no resolve-rate numbers, baselines or overhead figures.

Limits

• Results not in the fetched text. It ends during the problem formulation. The resolve-rate tables, the list of agents and benchmarks, the overhead cost, the manager model's identity and size, and the theoretical analysis are all missing. Check the full paper before trusting the headline claim.
• Narrow motivation study. The TraceBench numbers come from one agent and model on 48 tasks from a single benchmark (SWE-EVO), which was chosen for long, many-hunk runs.
• Gains depend on edit density. By the authors' own argument, runs with few writes accumulate little staleness, so the benefit should track how many edits a task needs.
• Language support unclear. The graph relies on per-language dependency rules, and the page does not say which languages are supported.
• No adoption details. The visible text gives no code, release or licence information.
• Preprint, v1.