CarryOn context runtime — continuation carriers — What does it mean?

The news. On October 13, 2026, a paper titled CarryOn proposed organizing a long-horizon agent's context around reusable task objects instead of the interaction history that produced them. With Claude Opus 4.7 as the host model and no extra training, it reports a higher OSWorld 2.0 partial score and fewer tokens on OSWorld 2.0 and BrowseComp-Plus. Read the paper →

Picture a team that runs a project from a whiteboard. After every meeting someone could write minutes and, a month later, the team would re-read the whole pile before each decision. Or they could keep sticky notes, each with an ID, a note of when it is still valid, and a version number, and rewrite a note only when something changes. That second habit is what CarryOn gives an agent.

The usual fix for a long transcript is to shrink it: cut old turns, or summarize them. Both treat the history as the thing to keep. CarryOn treats the progress inside the history as the thing to keep, so the agent stops paying to re-read an account of work that already sits in its state. This is a different answer to the scarce context problem: spend the window on facts that can be reused, not on the story of how they were found.

The agent's context view has three parts. Continuation carriers come in three kinds: external objects (files, documents, spreadsheets), information products (findings stored as claims with source references and reuse conditions), and situated state (progress that exists only inside one application or session, stored with an anchor to that environment). Execution context holds the current focus and pending work. The live tail holds the raw recent interactions, word for word.

A fold runs in four steps. A Tracker watches for a candidate that can support continuation. The runtime binds the request to its authorized sources and current carrier versions, and a Grounder runs read-only checks. A Compiler then proposes edits only for the selected candidates, and revises the execution context against the whole live tail. Last, the runtime validates identity, version currency and evidence authorization, and a fold must change at least one carrier. On success the edits apply atomically, affected carriers get successor versions, and unaffected ones carry forward; on failure the old view and the live tail stay as they were. The raw log is append-only, so nothing is lost.

Here is the worked example, using the paper's OSWorld 2.0 numbers for Claude Opus 4.7 on the full set. The baseline used 40.10M tokens per task and cost $36.83. CarryOn used 19.30M tokens and $23.62, and these figures include 0.69M tokens of tracker and compiler overhead. That is 51.9% fewer tokens and 35.9% lower nominal cost. The reason is the size of the input. The baseline's input context grew past 200K tokens, while CarryOn's mean stayed near 65K, roughly 3x smaller on average (an illustrative ratio of those two figures, not a per-turn measurement). The cumulative cost curves crossed before turn 200, and CarryOn was 34.1% cheaper by turn 500.

Accuracy moved the right way too: the partial score rose from 43.9% to 49.7%, a gain of 5.8 points, and the binary score from 15.7% to 19.4%. On BrowseComp-Plus (a 100-question subset) accuracy went from 49% to 56% while tokens fell from 1.56M to 1.20M.

Read the table as a progression. Compressing the transcript alone hurts: the sliding window and the generic summary both lose accuracy. Applying CarryOn's organizing ideas inside a plain-text summary recovers most of the loss, and the full runtime does best while carrying about 10% less text than that summary variant. The ablations on the same subset point at the carriers: without them the agent made 23.8% more calls and cost 22.3% more, which the authors attribute to re-deriving results it had already found. Without the execution context, the partial score fell to 44.00%.

Treat the claims with care. The evidence covers one host model (Opus 4.7) and two benchmarks. The 40-task subset moves 2.5 points per task and BrowseComp-Plus moves 1 point per question, and the paper reports no confidence intervals. Binary gains are smaller than partial gains, and removing the carriers actually raised the binary score on the subset (25.00% against 22.50%), so the picture is mixed. The runtime checks guard consistency, not whether the task is correct, and the grounder checks exist only for the OSWorld setup. Costs are nominal API-equivalent figures, not measured bills. Today a successful fold covers the whole live tail, not a selected part of it.

For how this differs from other approaches, see re-compacting from the original context, which fights drift in repeated summaries, and folding a trace into typed run state, which builds that state for observers instead of for the agent's own next step. The agent's state object is the place in the loop where carriers would live.

Goes deeper in: AI Agents → Context Engineering → The 4 Fixes

Related explainers

• Re-compaction from the original context — the other way to keep compression from drifting
• Live trace model and typed run state — folding a run into a small state, for monitors