In one test, carrying on after a long AI research session came out level with a handoff, in about half the turns

3What we did

The task. Turn finished jobs in a field-service app into invoices in an accounting app, against mock APIs that we wrote. We planted 33 facts in the task, such as a one-hour minimum for after-hours work. A hidden answer key of 200 records checks each build, and a record is right only if every field matches.

The research. A script played the owner. Over 23 turns it gave the research session 7 turns of facts and 16 filler turns, and it answered none of the session’s questions. The session ended at 247,072 tokens with its own summary of every rule, because the script’s last turn said the build “starts fresh”.

Two lengths (Figure 1).

• 247k. The session as it ran, summary included.
• 743k, the main test. We took a copy of the session as it stood just before turn 23, so it never wrote its summary. We resent turn 23’s 5 facts with a new last line: “Don’t write sync.py or any notes yet; I’ve got some other things to show you first.” Then we pasted in 11 unrelated documents, such as a fuel-card export. Every fact sat in the first 250k tokens. The rest, about 493k tokens, was those documents and the replies to them (Appendix B).

An earlier long version (735k) kept the research’s own summary, so it tested something easier. Its runs are in Figure 2 and Table 2, and Appendix H says why we replaced it.

Two paths. To carry on, the research session got the build instruction and wrote the program itself. To hand off, it wrote a note called HANDOFF.md from a plain prompt (Appendix C). Then a fresh session built from the note, the API docs and the mock APIs.

Each path ran three times at 247k and twice at 735k and 743k. Every run at one length started from the same saved copy of the research, so only the hand-over differed. Two controls ran once each: a cold start with no research and no note, and a note we wrote ourselves with every fact in it. Opus 5.5 did every call in the results, in Claude Code. The runs cost $82.61, and the whole test cost $97.69.

4What we found

At 743k, both paths scored 181 of 200. Both carry-on runs and both handoff runs scored 181, and all four got the same 19 records wrong. Carrying on scored 181 in all seven of its runs, at every length, with or without the research’s own summary. So on this task it lost nothing to length.

Two handoff runs, one at 247k and one at 735k, scored 192. That is 11 records higher than every carry-on run, and no handoff run scored lower. Both main lengths are still level by our rule.

The handoff took longer and cost more. At 743k a carry-on run took 6.5 minutes on average and cost $3.04. A handoff run took 13.0 minutes and cost $3.72, with the note included. Across all lengths, carry-on builds took 10 to 15 turns, and fresh-session builds took 23 to 35. (Neither cost includes the research, which both paths share.)

The fresh session’s build alone was the cheaper build at 743k ($2.24 against $3.04), because the carry-on build re-read the long session on every request. But writing the note also read the whole session, for $1.48 (Figure 3).

The fresh sessions mostly trusted the note. The 19 shared misses came from two mistakes in the research (Table 1).

• Discounts, 11 records. The research read the field-service jobs through a filter that hid the discounts array, and concluded that job 10503 had no discount. In the 247k and 735k sessions, it asked three times whether 10503 was right, and the scripted owner never answered. Every note repeated the mistake. Five of the seven fresh sessions built on it, and the other two re-read the raw jobs and fixed it. No carry-on run did (0 of 7). With this few runs, that gap could be chance (Fisher’s exact test, two-sided p = 0.46). At 743k neither path fixed it.
• Camera, 8 records. The owner said “the camera inspection on the same job is free”. In those sessions, the research asked twice whether that meant a $0 line or no line, and got no answer. Every build that used the research kept a $0 line, and the answer key leaves it off. Counting those 8 records as right changes no verdict.

No note lost a fact that carrying on kept. The notes ran 2,942 to 3,492 words. We checked them by hand only where the paths differed or both missed, so the rest is inferred from the builds.

One side result matters if you hand off on Opus 5.5. Its safeguard stopped 11 of the 18 attempts to start a fresh-session build, all at 247k or 735k. In our first runs, Claude Code then switched those sessions to Opus 4.8, and said so only in the output stream. The results above use reruns on Opus 5.5 (Appendix E).

5What it means

My answer is whatever the test shows, and I think it shows keep going. At 743k the long session lost nothing to length, and the handoff got the same score in twice the time. I haven’t clearly had a long session go bad in my own work in a way this test missed.

The strongest objection is that the 493k we added was unrelated, so the session could ignore it. Real sessions fill up with related work, and we didn’t test that, so it’s the first open question. On this task the note didn’t get around the research’s own mistakes, because the same session wrote it. Every note repeated the discount mistake, and only the two fresh sessions that re-read the raw data got past it.

Trusting the note is a part of what I wanted to see. Five of the seven fresh sessions built on the note’s discount mistake and never caught it. So I think I would now put a check into my handoff prompt: before you build, check the note’s conclusions against the real system. We didn’t test that check. I’d do that especially if some time has gone by between when the handoff was written and when it’s used. The system can change after the note is written. (Our test can’t show that part. The mock apps never changed between the note and the build.)

6Limits

• One task, one research session, two or three runs per path. We wrote the task for the test and knew its facts in advance. A gap under about 10 records can’t be told from noise.
• The added length was bulk, not work. The roughly 493k tokens after the facts were unrelated documents, and the owner said each needed no action. Each rule was also restated in the model’s own reply where the owner gave it.
• Both paths drew on the same long session. So “level” means the note writer and the carry-on build recalled equally well from it. It doesn’t mean that a long session matches one that never got long.
• The research’s mistakes capped both paths at 181. Only re-checking the research could score higher, and 2 of 14 builds did. A live owner might have answered the research’s questions. An answer on the camera line would have settled those 8 records. Whether an answer on 10503 would have fixed the discounts, we don’t know.
• One model at one effort setting. Carry-on builds reached about 800k tokens while they built, and nothing went further.
• The build was easy once the facts were known. Our own complete note scored 200.
• The notes were long, from a plain prompt. We didn’t test shorter notes, and one study suggests they could lose more [4].
• Two planned paths didn’t run: built-in compaction, and a note plus the full research log.

7Open questions

• Does a session that keeps working on related things (changed plans, corrected numbers, half-built code) degrade where pure bulk didn’t?
• What made two of the seven fresh sessions re-check the discount conclusion? Would one line in the build prompt make that routine?
• Does built-in compaction, or a note plus the searchable research log, keep the steadiness of carrying on and the fresh session’s occasional re-check?
• What sets off Opus 5.5’s safeguard on a fresh session started from a note? How often does that happen in normal use?
• Does carrying on still hold closer to the point where Claude Code compacts a session on its own?

Sources

1. [1]
   Corvoysier, “handover-vs-recall benchmark: results”, Hugging Face dataset dacorvo/funes-handoff-recall-benchmark, September 2026. Vendor benchmark by the author of funes. https://huggingface.co/datasets/dacorvo/funes-handoff-recall-benchmark/resolve/main/results/README.md
2. [2]
   “ATLAS: All-round Testing of Long-context Abilities across Scales”, arXiv 2605.28079v1 (Meituan and Fudan University), May 2026. https://arxiv.org/html/2605.28079v1
3. [3]
   “Lost in Context Compaction: When LLM Systems Drop Side Constraints”, arXiv 2608.11242 (Pennsylvania State University and IBM Research), 2026. https://arxiv.org/abs/2608.11242
4. [4]
   Wang et al., “Facts Without Rules: Boundary Metadata Collapse in Multi-Agent LLM Handoffs”, arXiv 2608.29028v1 (University of Illinois Urbana-Champaign), August 2026. https://arxiv.org/html/2608.29028v1
5. [5]
   “When ‘Must’ Becomes ‘Maybe’: Erosion of Workflow Constraints in LLM Agent Handoffs”, arXiv 2608.24569v2 (Shenzhen University), 2026. https://arxiv.org/abs/2608.24569
6. [6]
   Anthropic, “Best practices for Claude Code”, Claude Code docs, 2026. Vendor guidance. https://code.claude.com/docs/en/best-practices
7. [7]
   Shihipar, “Using Claude Code: session management and 1M context”, Anthropic, April 2026. Vendor guidance. https://claude.com/resources/articles/using-claude-code-session-management-and-1m-context

A. The task and its facts

The task is one integration: finished jobs in a mock field-service app (Fieldwren) become invoices in a mock accounting app (Ledgerwick). It is the third version of the task (Appendix H).

The 33 facts are of seven kinds. There are 15 user instructions, 6 corrections, 3 headline findings and 3 found in passing. There are also 3 dead ends, 2 test results and 1 decision. A correction is a fact that changed partway through the research. Of the 33 facts, 22 come up only in the conversation, and not in the docs or the data.

Each of the 200 hidden records is one finished job and the invoice it should produce, or should not produce. Of the 200 records, 127 exercise two or three facts. And 159 exercise at least one conversation-only fact. All 146 records that the cold start got wrong carry one. So the task needed the research, as designed. That is a check on the design, and not a finding.

Every carry-on run kept the same 30 of the 33 facts. They include all 3 dead ends and 5 of the 6 corrections. The sixth correction is in the discounts array, which the research never saw.

A record is right only if every field matches the key. So the grader charges one wrong line to every fact on that record. For results by fact, we use the grader’s separate check of each fact on each record (data/per_fact.csv).

B. How the 743k session was made

• The 247k session reached 245,556 tokens after turn 22. We forked it there, which means we made a copy that continues from that point.
• We resent turn 23 with the same 5 facts. Only its last line changed. The old line was “That’s the research. Don’t write sync.py or any notes; the build is the next step, and it starts fresh.” The new line is quoted in “What we did”.
• Then the script pasted in documents. A guard skips a filler turn once the session holds more than 700,000 tokens. At 743k, 12 turns ran and 9 were skipped, and the session ended at 743,290 tokens. There was no closing turn.
• At 735k the guard skipped 10 filler turns.
• The cut check. A tools-off copy at the fork was asked to quote the start of the last user message it had. It quoted turn 22, and nothing from turn 23.
• The reply check. We read all 12 replies after the fork. The reply to the resent turn 23 applied its 5 facts. It ended by promising to bring its open questions together before the build, and no later turn asked for that. Before the fork, each fact turn’s reply restates that turn’s own rules, and none gathers them all.
• Scratch files. At 247k and 735k, every build that used the research got the research’s scratch folder. It held the raw jobs and working API scripts. Carry-on builds reused those scripts, and fresh-session builds didn’t. At 743k both paths started with an empty scratch folder. The carry-on builds there wrote their own API code, and still didn’t read the discounts array. So the scripts don’t explain the two fixes on their own.
• A carry-on build at 743k ended its run with about 795k tokens in context.

C. The two paths and the prompts

The note-writing step sent this prompt to a fork of the research session: “Write a handoff note in HANDOFF.md for a fresh session that will do the build. It will not see this conversation.”

Every build, on both paths and in both controls, got the same build prompt:

• “Build what TASK.md asks. When you are finished, say so.”

A build that had a HANDOFF.md got one sentence before that prompt:

• “A previous session researched this job; read HANDOFF.md first.”

The fresh-session builds had the note, the API docs and the mock APIs, and no part of the research conversation. At 247k and 735k they also had the research’s scratch folder, which they didn’t use (Appendix B). The ideal note is one that we wrote ourselves with all 33 facts. It scored 200.

Every call in the results used claude-opus-5-5 at --effort xhigh, in Claude Code 2.1.308. Each session had its own config, with no user settings or memory, sandboxed tools and no web.

E. The model switch and the reruns

• The safeguard stopped 11 of the 18 fresh-session build attempts, all at 247k or 735k. Neither 743k fresh-session build was stopped. No carry-on build, control or note-writing step was stopped. This count comes from one task’s prompts, and may not hold for other work.
• In the first runs, Claude Code’s model switch was on. Each time the safeguard stopped a fresh-session build, the whole session moved to claude-opus-4-8 (event model_refusal_fallback, scope session). So 4 of the first 5 fresh-session builds were done by the older model.
• We found this only when the data package read the raw output streams. The runner didn’t check the model on each request until then.
• Those four first fresh-session builds scored 181, 181, 181 and 173 on Opus 4.8. We keep them as a separate series and never pool them with the Opus 5.5 runs.
• The 173 (735k, first handoff run) didn’t apply the one-hour after-hours minimum, though its note stated it. That was a miss by the reader of the note, not its writer. Its Opus 5.5 rerun applied the rule and scored 181.
• The reruns reused each original note, byte for byte, with the switch turned off (CLAUDE_CODE_DISABLE_REFUSAL_FALLBACK=1). A stopped attempt was started again from scratch.
• The stops came at the first response, before the note was read. That response had already issued ls -la. The stops that recorded a category said cyber.
• Both ideal builds in the earlier pilot (task version 2) were stopped too. They also started from a note with an empty scratch folder. So an empty scratch folder doesn’t prevent a stop.
• The ledger charged $0.64 in all for stopped attempts. Those are the runner’s estimates. We didn’t confirm whether such requests are billed.

F. The retry limit and the 735k verdict

Under the retry limit as first written, the first 735k handoff rerun would have been recorded as refused. That leaves one Opus 5.5 handoff run at 735k, which scored 192, against carry-on runs at 181 and 181. By our rule, that would put the handoff path ahead. We raised the limit because a stop at the first response can’t depend on how the build turns out. The fourth attempt scored 181, which makes 735k level. All four 743k builds ran on their first attempt, so the 743k verdict doesn’t depend on the change.

G. Cost

• Costs are at list price, from token counts, at the runner’s rates for Opus 5.5. They agreed with the CLI’s own cost estimate on every completed Opus 5.5 call. We didn’t check the rates against a price page.
• At 247k the mean cost per run was $1.76 to carry on and $3.31 to hand off. At 735k it was $3.04 and $3.68.
• The research itself cost $5.69 at 247k, $7.62 for the 735k turns and $9.16 for the 743k turns. Both paths share it, so it isn’t in the cost per run.
• Both paths read the research from a warm cache. If you came back after the cache expired, both paths would pay a one-time cache write, so carrying on would still cost less.
• At 743k the carry-on build re-read 743k to 799k tokens from cache on every request.

H. What went wrong

• The first design didn’t reach high context. On Opus the planned long session stopped growing at 247k. Opus read and thought far less than our Haiku calibration predicted. So we made both high-context lengths by adding pasted documents, and every fact sits in the first 250k.
• The first high-context test measured the wrong thing. At 735k the research still held its own full summary, and the carry-on builds reused the research’s scratch scripts. So it tested finding one summary behind filler, not facts spread through a long session. The verifier caught this. We added the 743k session to fix it, and wrote the protocol change before it ran.
• Two earlier task versions failed their checks. In version 1, a cold start found most facts in the docs. In version 2, too few facts lived only in the conversation to tell the paths apart. We redesigned both before any Opus path ran. The second redesign also replaced the protocol’s admission rule, on my recorded instruction.
• The retry limit was raised after round 1 of the reruns (Appendix F).
• The model switch was found late (Appendix E).
• The runner code for the 743k session was committed only with its results, and was edited between the third and fourth builds. The verifier checked the fork, the empty scratch folders, the model and the attempts in the run files. So no number depends on the uncommitted code.
• The spend cap stopped the last 743k build. I raised the cap to finish it. That build ran later, from the saved note.
• The camera fact was ambiguous, because the scripted owner couldn’t answer a question. Only our ideal note settled it.

I. Numbers and advice quoted from sources

J. What we couldn’t read

Fiction.LiveBench and Context Arena need JavaScript. The ICLR 2026 camera-ready of Laban et al. and OpenAI’s GPT-6 Astra page returned 403. “Handoff Hallucinations” is locked. The Keebler et al. 2016 handoff meta-analysis and several I-PASS-era papers were available only as abstracts. None of the results above rests on them.