DEV Community

sunny
sunny

Posted on Originally published at sunnycode.pro

Continue, compact, fork or start fresh? A 120-run coding-agent experiment

When a coding agent finishes a task, should the next task continue the conversation, compact it, fork it, or start fresh?

We compared five session strategies across two models and two rounds: 120 runs. There was no universal winner. Keeping history could be expensive without improving delivery in one model, yet faster in another.

Experiment design

Every strategy received the same target instructions, repository, documentation and evidence. Fresh meant no inherited chat, not an empty project.

  • Fresh: start from the task and repository.
  • Continue: retain the full conversation.
  • Compact: continue after native compaction.
  • Fork: copy history into a new session identity.
  • Fresh + summary: start fresh with a shared, frozen handoff summary generated by Sol.

Two rounds × two models × two target tasks × five strategies × three repetitions = 120 runs. Models were gpt-6.1-sol (medium) and deepseek-flash (medium requested, high resolved by the runtime; displayed as DeepSeek V4.1 Flash).

History came from real development. The second round used more complex prior work—durable queues, idempotency, leases, cancellation and recovery—but was not longer. Sol history went from roughly 442k to 425k tokens; DeepSeek from 331k to 295k. This is not a controlled context-length staircase.

The target tasks were E2E verification of an existing export feature, including honest reporting of expected failures, and a redaction bugfix. The fix had to preserve structural identities and raw diff comparisons while using redacted text for both display and layout width.

One group, all five strategies

Sol · complex prior-work round · E2E verification:

Strategy Mean recorded cost/run (USD) Median minutes Complete deliveries
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
Fresh + summary $0.207 2.6 3/3

The ≥ value is a recorded lower bound after interruption. Failed attempts remain in the means. Summary preparation and prior development are excluded.

In this group, full history increased cost and time without adding completed deliveries. That ordering did not generalize: in DeepSeek's complex-round E2E, Fresh took 6.8 minutes, Continue 3.0, and Fork 2.2, all with 3/3 complete deliveries.

Cache hits do not make an entire task cheap

For Sol's complex-round E2E, Continue averaged $1.266 in cache-read cost alone, versus $0.194 for the entire Fresh run—about 6.5×. This compares task-level costs, not token unit prices.

Continue cumulatively read about 6.33 million cached tokens per run across repeated calls. Full-history groups produced roughly 2.8–3.8× the output tokens of Fresh. Traces contained longer verification, scripts and repeated checks; we cannot label every additional step unnecessary.

A long-input pricing tier also contributed. Repricing the same recorded usage without its surcharge attributed about 47% of Continue's and 49% of Fork's recorded cost to the tier in this group. Pricing effects are not evidence of “context gravity.”

A summary remains a hypothesis

Fresh plus summary relative to Fresh across all eight groups

Fresh + summary was close to Fresh for Sol. In DeepSeek's complex E2E it cost about $0.082 and took 4.1 minutes, versus $0.103 and 6.8 minutes for Fresh. Yet across both bugfix rounds, summary runs passed functional checks 4/6, versus 6/6 for Fresh.

We would try a fresh session with a short summary first. The experiments have not shown it is the best choice. We used a shared frozen summary rather than a newly tailored summary for each target task; the main comparison excludes preparation cost.

Correctness and measurement boundaries

Of 120 runs, 102 completed successfully. The other 18 comprised 14 runtime failures/timeouts and four completed runs with functional boundary defects. Some interrupted runs already passed code acceptance but had not finished the delivery protocol.

Defects included visible paths mistakenly treated as immutable identities, and layout width calculated from original text after display redaction. The latter violates the task boundary; it does not by itself demonstrate a plaintext leak.

Three repetitions per group used one fixed development history per round. Four E2E judgments were corrected after manual review of permitted verification-script locations; original judgments were retained and models were not rerun. Cache warmth, routing and host load were not fully controlled.

Costs are fixed-rate API-equivalent estimates, not current prices or subscription bills. They include recorded uncached input, cache reads, cache writes and output, plus native compaction. Recorded cache writes were zero; incomplete usage can understate interrupted-run costs.

We have neither established a stable best strategy nor identified a context-gravity threshold. Next we want to test task-specific summaries, count preparation costs, and examine decisions that exist only in old chat rather than repository files.

Originally published on the Sunny Code engineering blog, with interactive comparisons, methodology and downloadable aggregate data.

Top comments (0)