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