Recover a provider switch when the destination has insufficient context allowance

[RoySalisbury]

Problem or use case

A long-running coordinator was asked to switch from Claude to Codex to reduce pressure on the current provider's token allowance. The requested handoff stopped with:

Insufficient context allowance for the provider handoff. Compact the target conversation or use a larger-context model; the current request has not been truncated.

Three consecutive destination runs failed before the agent could do any work or request recovery. The user had to intervene and return to the source provider; the coordinator subsequently created fresh Codex threads from concise handoff files for several worker lanes.

This can affect each worker switched in place as well as the coordinator, leaving an unattended workflow dependent on manual intervention.

Observed evidence

• T3 Code 0.0.46-nightly.20261006.2735, Linux x64.
• Source: claudeAgent, claude-opus-5-5; destination: codex, gpt-6.1-sol.
• The destination was a previously used Codex session, not an empty session.
• Its persisted context usage was 199405 used tokens with a 258400 maximum.
• The failed turn items recorded the handoff-budget error above. Retrying without changing the context state produced the same error.

The current handoff documentation already describes this refusal and advises compaction or a larger-context model. I am requesting a recovery workflow, rather than treating the documented refusal itself as a defect.

The inspected upstream handoff budget calculation reserves a quarter of the window, or at least 16000 tokens, in addition to existing context and the current request. With the recorded destination usage, that calculation leaves no handoff allowance even before the current request. This explains the refusal; the inspected upstream commit has not been verified as the installed build's commit.

Requested behavior

Provide a bounded, server-owned way to recover when an explicitly requested provider handoff is rejected for insufficient context allowance. Recovery cannot depend solely on the destination agent responding, because its turn has already failed.

A smallest useful version could:

1. Check the destination handoff allowance before attempting the switch, and report that an existing destination session needs compaction, along with the relevant capacity and reserve.
2. Offer Compact destination and retry when that provider supports it, with an optional user-configured policy for unattended recovery. Execute recovery and continuation through the same service for UI- and MCP-initiated switches.
3. If compaction is unsupported or cannot complete, offer continuation in a fresh destination session using T3's existing budgeted portable context and history references. Explain any context-selection limits.
4. Preserve the current user request, pending messages, and coordinator/worker associations. Make recovery bounded and explicit so repeated failures do not start duplicate work or loop between providers.

A first version can expose one clear recovery action and a structured outcome when recovery is unavailable; fully automatic fallback across arbitrary providers is not required.

Related work

• #15846 proposes selecting a fallback provider after a quota limit. This request covers an already requested switch whose context handoff cannot start.
• #15106 proposes agent-initiated compaction at a safe boundary. Recovery here also needs to work after the agent can no longer execute a turn.
• #15997 and #16147 report related handoff failures with different providers and triggers. This observation does not establish those reports' causes or permanent thread corruption.

I searched existing issues, Ideas discussions, and the documented handoff workflow. The related proposals cover parts of this need; I did not find a complete proposal for recovery from this specific refusal.