可移植交接中的上下文

切换提供方（provider）、经一次可移植重启继续，或使用提供方自己无法恢复的分叉时，T3 Code 会转移对话上下文。

短对话会完整转移。对话较长时，T3 Code 优先保留最近的请求与回答、最初的请求，以及相关活动，例如命令的结果。被选中的消息保留全文、顺序，以及用户或助手角色，也包括失败或被中断的回合（turn）中已完成的部分工作。你的新请求保持独立，绝不会为了让历史放得下而被缩短。

当已安装的版本支持该操作时，Codex 会直接接收历史消息。其他提供方收到的是同一份选择，作为带归属的对话上下文。交接不会复制正在离开的提供方的推理、工具调用状态或附件。

交接包含指向被省略历史的引用。智能体可以使用 T3 Code 的对话线程（thread）读取工具，取回已保存的消息和活动，包括一条长内容的剩余部分。对于重要的约束，你仍可以在下一条消息中重复它。交接是按预算做出的选择，不是智能体撰写的摘要。

上下文限制

一次交接必须为已有的提供方（provider）上下文、你的请求和附件、指令、工具以及后续工作留出空间。如果目标对话放不下这次交接，T3 Code 会用一份有界的已保存历史选择，开始一段新的提供方对话，并自动发送你的请求。你不需要手动压缩。如果即便在新对话中，请求和附件留下的空间仍然太小，请缩短请求，或选择上下文更大的模型。T3 Code 从不会为了放得下而缩短你的请求。

恢复会保持正在运行的后台工作不动。重试交接之前，让它完成，或先停止它。

服务器运维人员可以设置 T3CODE_CONTEXT_HANDOFF_TOKEN_CAP，以更改初始历史额度（默认 16,000；钳制在 1,024–64,000）。这是上限，不是提供方上下文窗口的保证。文本记账保守地按每个 UTF-8 字节计一个 token，归属标记和 JSON 转义也计算在内。导入的历史另有 64,000 字节的上限；你当前的输入和附件载荷不占用该上限。

T3 Code 会使用所选模型与选项的可用容量信息，以及提供方的上下文遥测。开始一段新的提供方对话会清除先前的用量，同时保留已知的模型容量。更改模型或上下文窗口选项时，会丢弃过期的用量和压缩阈值。

没有可用的容量信息时，T3 Code 假定窗口为 128,000 个 token。它为指令、工具和后续工作至少预留 16,000 个 token；当窗口的四分之一更大时，则预留四分之一。每张图片预留估计的 8,192 个 token，与文件大小无关；其他附件为其引用各预留 4,096 个。用量遥测不可用时，已有上下文根据已保存的活动来估计。已知更小的窗口仍会约束这次交接。这些是回退估计，不是精确的 token 计数。图片分辨率、自定义模型以及隐藏的原生上下文可能不同，因此提供方仍可能拒绝某次输入。