[Bug]: Switching back to a Claude provider instance silently resumes a much larger, cold context #23086

Summary

Switching between two Claude provider instances in the same T3 thread made the context appear to jump from under 200k to over 550k on one short follow-up. The logs show that switching back resumed the first instance's older, much larger native conversation, then incurred a full prompt-cache write after an idle period.

Preserving a provider's native conversation may be intentional. The problem is the lack of clear pre-send visibility/guardrails around the target session: I expected to continue with the roughly 122k context I had just been using, but the first request back on the other instance processed roughly 554k instead.

This is not a claim that the short prompt created 300k tokens, that T3 freshly reread the entire app transcript, or that Claude's cache expiry is itself a T3 bug.

Area

apps/web — provider-instance switching, context meter, and stale-resume compaction guard; potentially apps/server session/handoff integration.

Steps to reproduce

Recorded sequence from an affected thread; not yet reduced to a fresh minimal repro:

1. Work with Claude provider instance A until its native conversation is large. In this case its input context reached 543,501 tokens.
2. Switch the same T3 thread to a separate Claude provider instance B. T3 creates a different native session with a summary handoff. B starts at 47,609 tokens and later finishes at 121,853 tokens.
3. Leave A idle beyond its prompt-cache lifetime. In this case the idle gap was over seven hours and the usage records specify one-hour cache creation.
4. Switch back to A and submit a short follow-up.
5. T3 explicitly resumes A's original native session. The first response reports 554,506 input-context tokens, including 554,504 cache-creation tokens and zero cache-read tokens.

Both instances use the native Claude Agent SDK driver, not Claude ACP.

Expected behavior

Before sending the first turn after a provider-instance switch:

• Clearly show the target native session's context, rather than leave the impression that the smaller context from the previously active instance carries over.
• Evaluate any existing stale-Claude-resume compaction suggestion against that target session and its last activity/cache state.
• Make a potentially large cold-cache resume apparent before the request is submitted. If a fresh-session/summary option is offered, make that an explicit user choice, not silent history loss.

I have not yet established whether the specific defect is a stale/ambiguous meter, a missed compaction suggestion on instance changes, or insufficient disclosure of the existing resume behavior. Please investigate that boundary rather than interpreting this report as a request to automatically discard or compact history.

Actual behavior

The switch back resumes the old, larger session and the short follow-up triggers a large cache rebuild. The switch-back handoff itself was only 14,358 characters, using delta_since_target_last_seen; the 554k context was predominantly the resumed native conversation, not a new full-transcript handoff.

Impact

Major unexpected allowance consumption for a small follow-up. Around this reply, the provider-reported five-hour utilization changed from 0% to 21%. These are account-wide reports, so they do not prove that every percentage point came exclusively from this thread if concurrent account activity occurred.

The reply had only 573 generated tokens across two SDK turns, but aggregate usage included 555,380 cache-creation tokens and 554,504 cache-read tokens.

Version or commit

Observed on T3 Code Nightly on 2026-10-21 UTC. Installed version at report time: 0.1.2-nightly.20261021.3486. The desktop auto-updated around the incident/investigation; the exact build running at the first affected request is not independently confirmed.

Environment

Windows desktop; two Claude provider instances backed by separate native sessions/config directories; model claude-opus-5-5; native Claude Agent SDK driver (claudeAgent).

Logs / evidence

Relevant fields only; native session IDs are replaced with aliases. No full transcript, workspace paths, credentials, or project content is included.

A before switching away:
  input-context = 543501

Query opened on switch to B:
  options.sessionId = SESSION_B
  handoff.strategy = full_thread_summary
  handoff.summaryText length = 14333 characters

B final response:
  input-context = 121853

Query opened on switch back to A:
  options.resume = SESSION_A
  handoff.strategy = delta_since_target_last_seen
  handoff.summaryText length = 14358 characters

First model response after resuming A:

{
  "input_tokens": 2,
  "cache_creation_input_tokens": 554504,
  "cache_read_input_tokens": 0,
  "cache_creation": {
    "ephemeral_1h_input_tokens": 554504,
    "ephemeral_5m_input_tokens": 0
  }
}

Aggregate SDK result for that short reply, relevant fields only:

{
  "num_turns": 2,
  "usage": {
    "input_tokens": 4,
    "cache_creation_input_tokens": 555380,
    "cache_read_input_tokens": 554504,
    "output_tokens": 573
  }
}

Workaround

Continue with the smaller provider instance, or use a fresh thread with a short handoff. Compacting one provider instance's conversation does not compact the other instance's saved conversation. Compaction on an already-cold session can itself require processing the old history, so it is not necessarily a zero-cost recovery.

Related

• [Bug]: Switching back to a provider whose conversation is full gets stuck, and the error asks for a /compact that isn't available #22636 — switching back to a provider resumes its separate full conversation; that report concerns a hard handoff-budget failure, whereas this one concerns a successful but unexpectedly expensive resume.
• [Feature]: Make stale Claude resume-compaction token threshold configurable #19823 — documents an existing stale-Claude-resume compaction suggestion. Could its target-session/context handling be checked specifically when switching between Claude provider instances?

I searched existing issues and did not find an exact duplicate. If target-session visibility/confirmation is considered intentional UX rather than a bug, happy for this to be reclassified or moved to Discussions.