1# Context in portable handoffs
2
3T3 Code transfers conversation context when you switch providers, continue through a portable
4restart, or use a fork that the provider cannot resume itself.
5
6Short conversations transfer intact. For longer conversations, T3 Code favors recent requests and
7answers, the original request, and relevant activity such as command outcomes. Selected messages
8keep their full text, order, and user or assistant role, including partial work from failed or
9interrupted turns. Your new request stays separate and is never shortened to make history fit.
10
11Codex receives historical messages directly when its installed version supports that operation.
12Other providers receive the same selection as attributed conversation context. A handoff does not
13copy the outgoing provider's reasoning, tool-call state, or attachments.
14
15The handoff includes references to omitted history. The agent can use T3 Code's thread-reading tool
16to retrieve saved messages and activity, including the remainder of a long item. For an important
17constraint, you can still repeat it in your next message. A handoff is a budgeted selection, not an
18agent-written summary.
19
20## Context limits
21
22A handoff must leave room for existing provider context, your request and attachments, instructions,
23tools, and subsequent work. If the target conversation has no room for the handoff, T3 Code starts
24a fresh provider conversation with a bounded selection of saved history and sends your request
25automatically. You do not need to compact manually. If the request and attachments leave too little
26room even in a fresh conversation, shorten the request or select a larger-context model. T3 Code
27never shortens your request to make it fit.
28
29Recovery leaves running background work intact. Let it finish or stop it before retrying the handoff.
30
31Server operators can set `T3CODE_CONTEXT_HANDOFF_TOKEN_CAP` to change the initial history allowance
32(default 16,000; clamped to 1,024–64,000). This is an upper bound, not a provider context-window
33guarantee. Text accounting conservatively charges one token per UTF-8 byte, including attribution
34and JSON escaping. Imported history has a separate 64,000-byte ceiling; your current input and
35attachment payloads do not consume that ceiling.
36
37T3 Code uses available capacity information for your selected model and options, together with
38provider context telemetry. Starting a fresh provider conversation clears prior usage, while keeping
39known model capacity. Changing models or context-window options discards stale usage and compaction
40thresholds.
41
42When no capacity information is available, T3 Code assumes a 128,000-token window. It reserves at
43least 16,000 tokens, or a quarter of the window when larger, for instructions, tools, and subsequent
44work. Images reserve an estimated 8,192 tokens each, independent of their file size; other
45attachments reserve 4,096 each for their references. Existing context is estimated from saved
46activity when usage telemetry is unavailable. Known smaller windows still constrain the handoff.
47These are fallback estimates, not exact token counts. Image resolution, custom models, and hidden
48native context can differ, so the provider may still reject an input.