Taking over a project
does not require every conversation.
One development task is finished. Next, you need to verify an implemented feature or fix another bug. Do you stay in the same session, compact its context, fork its history, or start a fresh session?
We set out to investigate “context gravity”: could the goals, assumptions and habits of an earlier task pull a model back toward its old work and impair the next task? In isolated Sunny environments, we accumulated history through real development, then assigned new E2E verification and bugfix tasks.
We ran two rounds with two models and five strategies, repeating each group three times. After inspecting the deliverables and execution traces, we still could not say how long a conversation must be before it starts to impair the next task.
We would try a fresh session with a short summary first. The experiments have not yet shown that it is the best choice.
“Fresh” needs a careful definition. Fresh sessions still received the same task instructions, code, documentation and evidence. They could read the project files without inheriting the old chat. Both E2E and bugfix required a handoff. We compared whether to add chat history, and how much to carry.
The same work. Five ways to take over.
Project state and target tasks were held constant. What changed was the conversation carried into the new task.
A fresh session with a short summary.
Add a shared, frozen handoff summary generated by Sol. It is not customized for each target run.
The first round used a previously accumulated long development history. For the second, we replaced the prior work with a more complex development process: durable queues, idempotency, leases and fencing, cancellation, crash recovery and retry budgets. After stage acceptance, we froze the project and history, then branched into five strategies. Here, the “complex task” was the source of the old context, not a third target task.
The E2E task was to verify the existing export feature and report expected failures accurately. The bugfix was to redact visible text. Structural identifiers and raw diff comparisons had to remain unchanged. Both the displayed text and layout width had to use the redacted version. Changing the display without updating the layout would fail acceptance.
Explore where the cost goes.
Explore eight experiment groups and compare cost, time and delivery across five strategies for the same task. Each strategy has three runs.
Mean cost (USD), median time (minutes), three runs. Cost scale: $0–6. Comparable across groups.
Select a strategy to inspect all four cost categories. ≥ indicates a recorded lower bound caused by interruption; failed attempts remain in the mean. Cost and time include native compaction, but exclude prior development and preparation of the shared summary. Cache writes are included; all recorded values were zero.
Expand the eight-group overview 40 rows, including every strategy
Summary versus fresh, across all eight groups
The same strategy behaves
differently across models.
Sol showed the most consistent pattern. Across both E2E rounds, fresh, continue, fork and fresh + summary each achieved 6/6 complete deliveries. Fresh sessions averaged about $0.19 per run, with median times of roughly 2.4–2.7 minutes. Continuing cost $1.45–2.29 and took 9.3–14.0 minutes; forking cost $3.48–3.81 and took 14.2–14.5 minutes. Full history provided no additional benefit on this acceptance measure.
DeepSeek produced a different speed ranking. In E2E after the complex prior task, fresh sessions took about 6.8 minutes, continuing 3.0 minutes and forking 2.2 minutes, all with 3/3 complete deliveries. Continuing was fastest in the earlier round. For this model, carrying history sometimes saved time, and cost differences were much smaller.
For the bugfix, DeepSeek fresh and compact each passed functional acceptance in 6/6 runs across the two rounds. Compact averaged about $0.136 in both rounds, but its median time increased from 6.8 to 9.6 minutes. Similar costs do not imply similar execution.
These group-level results suggest that fresh sessions, summary handoffs and compaction are all worth considering, but their advantages differ. Sol’s fresh sessions had lower overhead; DeepSeek’s speed ranking varied by task. A short summary also did not consistently outperform starting from the task instructions and repository.
Cache hits still have a cost.
Continuing the session: cache-read cost
was about 6.5× the fresh session’s total cost.
Across the three E2E runs that continued the session, cumulative cache reads averaged about 6.33 million tokens per run. History entered the input repeatedly across calls. A cache hit makes an individual read cheaper; it does not make the whole task cheap.
Sol’s full-history groups also averaged about 2.8–3.8 times as many output tokens as the fresh group. Traces show longer verification, scripts and repeated checks. These runs did more work. We cannot say that every extra step was unnecessary.
Long inputs also had higher rates. We recalculated costs using the same recorded usage, but without the long-input surcharge. That surcharge accounted for about 47% of continue costs and 49% of fork costs in this round’s Sol E2E runs. A pricing-tier increase is not evidence of context gravity.
Why can a fork cost more?
Native fork copies history and creates a new session ID. Message contents matched in 12 same / fork pairs, but cache behavior did not necessarily match. In one Sol pair’s first requests, continuing recorded 425,984 cache-read tokens, while the fork recorded 426,666 uncached input tokens. First-request cost rose from about $0.090 to $1.710.
The runtime uses the session ID in its cache key, which suggests a possible mechanism. We did not run a server-side causal experiment, however. Continued sessions also experienced cold caches, and DeepSeek forks could hit the cache. We cannot conclude that a fork always loses cache reuse.
Incomplete delivery
does not always mean incorrect work.
Of 120 runs, 102 passed complete delivery. Of the remaining 18, 14 involved runtime failures or timeouts; four completed but failed functional edge cases. In some interrupted runs, the code had already passed acceptance, but the final delivery protocol was unfinished.
The functional defects deserve separate attention. They were concentrated in DeepSeek’s redaction task. Some runs treated visible paths as immutable structural identity and skipped redaction; others replaced displayed text but still computed layout width from the original text. The latter violated an explicit layout requirement, but is not by itself evidence of exposed sensitive text.
Similar path omissions also occurred in a fork in the earlier round, so they cannot be attributed to the second round’s complex prior task. Vocabulary from old work occasionally appeared in report scope statements, but none of the 60 complex-round runs modified old-task modules. We observed old-task wording, more checks and more output, but no consistent pattern of the old task taking over the new one.
Next, we would try a fresh session + summary.
We would try a fresh session with a short summary first. The experiments have not yet shown that it is the best choice.
We want a short summary to carry key decisions and unfinished work without copying the entire chat. These experiments did not fully test that idea. Each group used the same summary, prepared in advance. We did not rewrite it for each new task or include the cost of generating it.
The results were mixed. Sol’s summary and fresh groups were close. In DeepSeek’s complex-round E2E task, summary cost about $0.082 versus $0.103 for fresh and took 4.1 versus 6.8 minutes. But in the earlier round they were similar; across both bugfix rounds, summary passed functional acceptance in 4/6 runs versus fresh at 6/6.
We have not established a consistently best strategy or a context-gravity threshold. Each group has only three runs, and some runs encountered failures. Next, we will write summaries for the new task and include the cost of preparing them. We also need to test handoffs where key decisions exist only in the old chat, not in the repository.
Methods, sources and limitations
How were the 120 runs produced?
Two rounds × two models × two target tasks × five strategies × three repetitions. Models were gpt-6.1-sol (medium) and deepseek-flash (medium requested, resolved to high by the runtime). Each round started from one fixed development history. Three repetitions did not mean three independently developed histories.
Context accumulated through real development, without synthetic dossiers or a CURRENT.md reminder to switch tasks. The complex prior-task stage completed 161 of its own tests and nine independent acceptance checks; schema migration and the dashboard were outside its final scope.
Each target ran in an isolated project environment, with raw traces, acceptance results and deliverables retained. Four initial E2E judgments were corrected after manual review of permitted locations for independent verification scripts; original judgments were retained. Earlier-round evaluator errors caused by missing dependencies were also corrected. These corrections did not trigger model reruns.
How is cost calculated?
Cost = uncached input + cache reads + cache writes + output, calculated from message records and including native compaction. Reasoning already included in output is not counted twice. We use USD rates from the experiment’s frozen runtime, not current public prices or actual invoices.
Per million tokens, Sol’s base rates in that order are $2 / $0.10 / $2.50 / $10; when total input, including cached tokens, exceeds 272,000, they are $4 / $0.20 / $5 / $15. DeepSeek rates are $0.30 / $0.006 / $0 / $1.20.
The shared short summary was generated by Sol and then frozen; it was not tailored afresh for each target run.
Charts measure execution cost after handoff, including native compaction but excluding prior development and preparation of the shared summary. The complex-round summary was generated once, at a recorded cost of about $0.09585 and 23 seconds. Interrupted runs with incomplete usage records are marked ≥ as lower bounds. Low cost caused by interruption does not imply cheaper successful delivery.
Why can we not identify a context-gravity threshold yet?
The rounds changed prior-task content, and length did not increase monotonically. The runtime configured windows of 500,000 tokens for Sol and 1,000,000 for DeepSeek. We did not verify the maximum lengths accepted by the servers. Cache warmth, service routing and host load were not fully controlled. The complex round paused for disk capacity and later resumed; completed runs were not retried. With only three runs per group, small differences may be noise.
Fresh sessions could still read the repository, so the experiment provides limited coverage of handoffs where essential information exists only in the old conversation. Timeouts and transport failures are part of the real user experience, but should not all be classified as reasoning or task-switching failures.
The layout and exploratory interactions draw on Anthropic’s What will our economic future look like?. The experiment, conclusions and chart data are Sunny’s; the reference site is not a source for the experimental findings.