可攜式 handoff 中的上下文

當你切換 Provider、經由可攜式重新啟動繼續工作，或是使用 Provider 自己無法續接的 fork 時，T3 Code 會把對話的上下文轉交過去。

短的對話會完整轉交。對於較長的對話，T3 Code 會優先保留最近的請求與回答、最初的請求，以及相關的活動，例如指令的執行結果。被選中的訊息會保留完整的文字、順序，以及是使用者還是助理說的；失敗或被中斷的 turn 裡做到一半的工作也包含在內。你的新請求是分開處理的，絕對不會為了塞進歷史紀錄而被縮短。

如果已安裝的 Codex 版本支援這項操作，Codex 會直接收到歷史訊息。其他 Provider 則會收到同一批挑選出來的內容，形式是標註了來源的對話上下文。handoff 不會複製原本那個 Provider 的推理過程、工具呼叫狀態或附件。

handoff 裡包含了指向被省略歷史的參照。agent 可以用 T3 Code 的 Thread 讀取工具，取回已儲存的訊息和活動，包含一則很長的項目裡剩下的部分。對於重要的限制條件，你還是可以在下一則訊息裡再說一次。handoff 是在額度內挑選出來的內容，不是由 agent 寫出來的摘要。

上下文的限制#

handoff 必須留出空間給 Provider 既有的上下文、你的請求與附件、指示、工具，以及後續的工作。如果連它的取回參照都放不下，T3 Code 會回報錯誤，而不是縮短你的請求。請先壓縮（compact）目標對話，或是選擇上下文較大的模型，然後再試一次。

Server 的管理者可以設定 T3CODE_CONTEXT_HANDOFF_TOKEN_CAP，來變更一開始分配給歷史紀錄的額度（預設 16,000；會被限制在 1,024–64,000 之間）。這是一個上限，不是對 Provider 上下文視窗大小的保證。文字的計算方式採保守估計，每個 UTF-8 byte 算一個 token，包含來源標註和 JSON 跳脫字元在內。匯入的歷史紀錄另外有一個 64,000 byte 的上限；你目前的輸入和附件內容不會佔用這個上限。

T3 Code 會使用你所選模型與選項的可用容量資訊，再搭配 Provider 回報的上下文用量資料。開啟一個全新的 Provider 對話時，會清除先前的用量，但保留已知的模型容量。變更模型或上下文視窗的選項時，會丟棄已經過時的用量和壓縮門檻。

當沒有任何容量資訊可用時，T3 Code 會假設視窗大小是 128,000 個 token。它會保留至少 16,000 個 token，或是視窗的四分之一（取較大者），給指示、工具和後續的工作使用。每張圖片會保留估計 8,192 個 token，與檔案大小無關；其他附件則各保留 4,096 個，用於它們的參照。當沒有用量資料時，既有的上下文會從已儲存的活動來估算。已知的較小視窗仍然會限制 handoff 的大小。這些都是備用的估計值，不是精確的 token 數。圖片解析度、自訂模型，以及隱藏的原生上下文都可能造成差異，所以 Provider 仍然有可能拒絕某一次輸入。

本頁譯自 docs/user/portable-handoffs.md（英文原文，版本 e2d8445）。標示「本站補充」的區塊不在原文裡。