Hand over to a fresh thread instead of compacting, with a handoff note kept from the first turn

[cornishandy]

Problem

T3 compacts a long Claude thread in one case: before my next message, once the thread has 100k+ tokens and has sat idle longer than the prompt-cache TTL.

• A thread that stays busy never hits that trigger. One of mine reached about 370k tokens today without compacting, and every turn re-reads all of it.
• When the trigger does fire, compaction reads the whole thread uncached and writes one summary, in one pass, from whatever is in the window at that moment.

To be clear about evidence: I haven't measured compaction dropping facts. The case is reasoning (a summary written once, after the fact, keeps only what that pass picks out) and per-turn cost.

Prior art, and what's different

• feat(web): continue conversations in new threads #8452 (closed 28 Aug) added a separate "Continue in new thread" action, declined as not a priority. Continue a structured handoff in a fresh thread #8754 was closed as a duplicate of Agent-controlled T3 threads: a multi-provider proof of concept #8433 and PRs feat(threads): add agent-requested handoffs #7487, feat(web): continue conversations in new threads #8452 and feat(handoff): let an agent hand its thread off to a fresh one #8492.
• feat(threads): add agent-requested handoffs #7487 and feat(handoff): let an agent hand its thread off to a fresh one #8492 let an agent request a handoff, with a recap written at that moment.
• Auto-fork thread with distilled context on rate-limit / quota cutoff #15128 forks on a rate-limit cutoff with a one-shot note; [Feature]: Switch provider/model mid-conversation via transcript handoff #6757 moved a transcript to another provider.
• A setting to turn off compact-before-send on stale Claude threads #17170, [Feature]: Make stale Claude resume-compaction token threshold configurable #19823 and feat(web): stale Claude threads can start with the Compact chip off #19643 opt out of or tune auto-compact.

What's different here:

1. The note is kept from the thread's first turn, updated at each milestone, not written as a recap when the switch happens.
2. No new button or agent action. It's an opt-in second behaviour of the auto-compact trigger T3 already has, taken only at a clean boundary.
3. Running work carries over: PR watches and scheduled tasks move to the new thread, and running subagents or a pending question keep the thread where it is.

Proposal

1. A handoff note for each thread. T3 gives each thread a small note file that the agent keeps current at milestones (a decision made, a step finished, a service started or stopped, a question asked or answered): state, the user's decisions, open questions, running services, next steps, key files. Because it's always current, a handover needs no extra turn.
2. Hand over at a clean boundary. The turn has finished, no subagents or delegated tasks are running, no question is pending and nothing is queued. Then T3 creates a new thread in the same project and workspace (worktree and branch) with the same model, effort and modes, seeds it with the note, links the two threads both ways, and moves PR watches and scheduled tasks. At the compact-before-send trigger, my message goes to the new thread instead of being preceded by /compact.
3. A setting next to Auto-compact: Compact (today) / Ask / Hand over. Ask asks before sending: "This thread is at 180k tokens. Compact, or hand over to a fresh thread?" A busy thread could get the same question at the end of a turn once it passes a size threshold.

What I'm running locally

Since agents can now launch T3 threads themselves, I'm trying a local version: rules in my agent instructions, a small handover script that reads the transcript for context size and compactions, an ask/auto/off switch (default ask), and a Claude Code SessionStart hook (matcher compact) that tells the agent to re-read the note after a compaction. I'll report how it goes.

[cornishandy]

Update after three days of running this locally (16–19 Oct)

As promised, here's how the local version went. Numbers come from the outcome log my handover script writes.

• 10 handovers, all completed, none aborted. Each new thread's first step checks the note against live state (running local servers, keep-alive jobs, scheduled tasks, PR watches) before doing anything. In all 10 it found nothing material wrong. The drift was small: a few stale numbers (a usage figure, a timestamp), and once the new thread came up at a different effort setting than the note recorded.
• Ask mode made 10 offers; I turned down 3, and two lapsed unanswered. Some handovers I asked for myself, usually at the end of a phase of work.
• 8 compactions still happened in threads that had a note (threads that hadn't accepted an offer yet). After each one, a SessionStart hook told the agent to re-read the note before continuing.

Three refinements to the proposal, from using it:

1. A "Prepare handover" button after all. I said "no new button". After using it I'd add one: a one-click "Prepare handover" in the composer, alongside the automatic trigger. I'm trying one that inserts the request into the composer without sending it, so I can hand over at a natural break before any size threshold.
2. Show the chain. A small "Handover 2" pill in the thread header, linking back to the predecessor and its note, would help. Today the links live only in the two threads' messages and in the note itself.
3. What actually needed carrying over was mostly long-running local servers, keep-alive jobs and usage reservations, more than PR watches. A built-in version could list those from the note and confirm each one in the new thread.

One small snag: threads launched through MCP have ids like mcp:<uuid>, and agents sometimes pass the bare UUID, so one takeover failed its first attempt. My script now accepts both forms. A built-in handover wouldn't need agents to copy ids at all.

[guryanov-a]

+1, I'd like this too. One thought on where it lives: the composer already has the Compact chip with the token count (mine shows "Compact 309k" on a busy thread that never hit the idle trigger). That chip is already where you decide what to do about context, so the handover could sit there as a second option: "Compact" / "Continue in a fresh thread". That would cover your "Prepare handover" refinement without adding a new button anywhere else.

[code-kasha]

Adding a data point from a different angle, in case it's useful. I run a twelve-phase project with one fresh thread per phase. Instead of an agent-written note at handover time, I keep a capped (10 KB) briefing file in the repo, updated after each finished task with the next task's details. A hook generates its status block (branch, recent commits, open tasks), so the volatile facts are never written by hand. That targets the kind of drift described in the update above, such as stale numbers.

I measured it with replayed fresh-agent runs on one project. Starting a phase from the file used about 7,500 fewer tokens than rediscovering the repo from scratch, and took about half the time. Keeping it current costs roughly 1,000 tokens per update in a thread that already holds the file, so at around 11 tasks per phase it's close to break-even on tokens. The gains are mostly speed and consistent starts.

It needs nothing from T3 Code. The one thing that would help is seeing how many tokens a new thread spent before its first useful action. Write-up with method and limits: https://www.akashdamle.in/blog/a-context-pack-for-ai-sessions-measured