120 Runs, Five Session Strategies: No Universal Winner in Agent Handoff Experiment

An agent development task ends. Should the next task continue the original session, compact it first, fork a copy of the history, or just open a fresh one?

We ran a controlled comparison of two models, five session strategies, in two rounds, totaling 120 runs. The results produced no single optimal answer: full history significantly increased cost and time in some groups, but was faster on another model; short summaries did not stably beat starting fresh.

1. Comparing session handoff, not whether project knowledge exists

All groups received the same new task description, code, documentation, and evidence. "Fresh" can still read the repository; it just does not inherit the old chat.

Strategy	Handoff approach
Fresh	Takes over from task description and repository
Continue	Retains full conversation
Compact	Uses native compression, then continues
Fork	Copies history, creates a new session identity
Summary+fresh	Empty session plus a shared, frozen short handoff summary

Experiment scale: 2 rounds × 2 models × 2 target tasks × 5 strategies × 3 repetitions = 120 runs.

Models: gpt-6.1-sol (medium) and deepseek-flash (requested medium, resolved to high at runtime; page displays as DeepSeek V4.1 Flash).

Old history came from real development. The second round swapped in more complex old work, including persistent queues, idempotency, leases and fencing, cancellation, crash recovery, and retry budgets. More complex does not equal longer: Sol history went from about 442K to 425K tokens, DeepSeek from 331K to 295K. So this is not a tightly controlled context-length ladder experiment, and cannot be used to infer length thresholds.

Only two kinds of new targets:

• E2E verification: verify an already implemented export feature; expected failures must also be reported faithfully.
• Desensitization bugfix: visible text must be desensitized, but structural identifiers and raw diff comparison cannot change; both displayed text and layout width must use the desensitized result.

The complex old task is only a history source, not a third target task type.

2. Keeping full history does not necessarily improve delivery

Look first at Sol · complex round · E2E. Each strategy ran three times:

Strategy	Average recorded cost per run (USD)	Median time (min)	Full delivery
Fresh	0.194	2.7	3/3
Continue	2.293	14.0	3/3
Compact	≥0.548	6.8	2/3
Fork	3.813	14.2	3/3
Summary+fresh	0.207	2.6	3/3

≥ indicates a lower bound due to interruption. Failed attempts still count in the means. Cost and time include native compact, not old-task development or shared summary preparation.

In this group, continue and fork were more expensive and slower, without completing more deliveries than fresh.

This ordering does not generalize to all models. DeepSeek complex round E2E: fresh took about 6.8 minutes, continue about 3.0, fork about 2.2, all 3/3 fully qualified. For that model, inheriting history sometimes saves time.

3. Cache hits do not mean the whole task is cheap

In Sol complex E2E, the single cache-read cost item for continue sessions averaged about $1.266, while a fresh task's total cost was about $0.194. The former is roughly 6.5× the latter.

This is a task-level cost ratio, not a cache token unit-price ratio.

Continue groups accumulated about 6.33M cached tokens read per run. Old history repeatedly re-entered input across many calls; a single read is cheap, but multiplied cumulative usage can still be expensive.

Average output tokens for full-history groups were also about 2.8–3.8× those of fresh. Traces show longer verification processes, scripts, and repeated checks, but we cannot conclude every added step was unnecessary.

The long-input pricing tier also pushed costs up. Keeping recorded usage unchanged and removing only the long-input surcharge, continue and fork in this group had about 47% and 49% of recorded costs coming from that surcharge. Pricing-driven cost increases are not evidence of "context gravity."

4. Short summaries are worth trying, but not proven best

The raw chart below puts all eight groups together. Fresh is 1×; cost and time below 1 does not mean better delivery, so you must also look at full-delivery counts.

Sol's summary performed close to fresh. In DeepSeek complex E2E, summary cost about $0.082 and 4.1 minutes, fresh $0.103 and 6.8 minutes; but in both bugfix rounds, summary's functional acceptance was 4/6 versus fresh's 6/6.

Our next step will try "fresh session + short summary," but this is just a current choice, not a proven optimal strategy. This run used a shared frozen summary, not one written per new task, and the main comparison did not include summary preparation cost.

5. Correct function and full delivery need separate accounting

Of 120 runs, 102 fully qualified. The other 18 include:

• 14 runtime failures or timeouts;
• 4 functional boundary defects in completed runs.

Some interruptions happened after code already passed acceptance, but before the final delivery protocol completed. Calling all of them "code failures" would mask the source of the problem.

The real defects concentrated in DeepSeek desensitization tasks: some treated visible paths as immutable structural identities and missed desensitization; some replaced displayed content but layout width still used original text. The latter violates an explicit layout requirement, but it cannot be described as sensitive plaintext leakage.

The complex round's 60 runs did not modify old-task modules. We saw some leftover old-task wording, more checks, and more output, but no stable "old task taking over the new task" pattern.

6. What these results can support

Each group had only three runs, and each round used one fixed development history; three repetitions do not represent three independent histories. Cache cold/warm states, routing, and host load were not fully controlled.

The four E2E raw scores were corrected through manual review because of allowed independent verification script positions; original scores were retained, and models were not rerun for this.

Costs were calculated with frozen rates, so they are API-equivalent estimates, not current prices or actual subscription bills. They include recorded non-cached inputs, cache reads, cache writes, and outputs; inference tokens are already included in output, not double-counted. Cache writes in this run were all zero; incomplete usage after interruption can only be treated as a lower bound.

What can be established: session strategy must be evaluated separately by model, task, and delivery requirement, not by context length or single-token price alone. No stable optimal strategy has been identified, and no context-gravity threshold was found.

Next steps need to compare task-specific summaries, include summary preparation cost, and test cases where key decisions exist only in the old chat and cannot be found in the repository.

This article is adapted from the Sunny Code engineering experiment original. The full original includes interactive group comparisons, an eight-group overview, and aggregated data download.