上下文視窗

隨著對話的增長，您最終會接近上下文視窗的限制。對於長時間運行的對話和代理工作流程，伺服器端壓縮是上下文管理的主要策略。



上下文視窗的運作方式

「Context window」（上下文視窗）是指語言模型在生成回應時可以參考的所有文本，包括回應本身。這與語言模型訓練所用的大型語料庫不同，而是代表模型的「工作記憶」。較大的上下文視窗允許模型處理更複雜和冗長的提示，但更多的上下文並不自動代表更好。隨著 token 數量的增長，準確性和回憶能力會下降，這種現象稱為「context rot」（上下文衰退）。這使得精心策劃上下文中的內容與可用空間的大小同樣重要。

下圖說明了 API 請求的標準上下文視窗行為¹：

¹ 聊天介面（例如 claude.ai）也可以以滾動的「先進先出」方式管理上下文視窗。

• 漸進式 token 累積： 隨著對話輪次的推進，每個使用者訊息和助手回應都會在上下文視窗中累積，並且先前的輪次會被完整保留。
• 上下文視窗容量： 上下文視窗（最多 1M token，取決於模型）容納對話歷史記錄以及 Claude 生成的新輸出。
• 輸入-輸出流程： 每個輪次包含：
  • 輸入階段： 包含所有先前的對話歷史記錄以及當前的使用者訊息
  • 輸出階段： 生成文本回應，該回應成為下一輪輸入的一部分

請求中的所有內容都計入上下文視窗：系統提示、messages 中的每則訊息（包括工具結果、圖像和文件），以及您的工具定義。Claude 在該輪次生成的輸出（包括其擴展思考）也計入其中。每個回應都會在其 usage 欄位中報告該請求消耗的量。如果您使用提示快取，輸入計數會分為 input_tokens、cache_read_input_tokens 和 cache_creation_input_tokens，這三者都計入視窗。若要在發送請求之前進行估算，請使用 token 計數 API。



各模型的上下文視窗大小

Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7、Claude Opus 4.6、Claude Sonnet 5 和 Claude Sonnet 4.6 在 Claude API、Amazon Bedrock、Google Cloud 和 Microsoft Foundry 上具有 1M token 的上下文視窗。Claude Mythos Preview 也具有 1M token 的上下文視窗。

Claude Fable 5 和 Claude Mythos 5（claude-fable-5 和 claude-mythos-5）也具有 1M token 的上下文視窗。對任何具有 1M token 上下文視窗的模型發出的單一請求最多可以生成 128k 個輸出 token（max_tokens）。其他 Claude 模型（包括 Claude Sonnet 4.5）具有 200k token 的上下文視窗。

對於每個具有 1M token 上下文視窗的模型，1M 是預設值：您不需要 beta 標頭，且長上下文請求按標準定價計費。

單一請求最多可以包含 600 張圖像或 PDF 頁面（具有 200k token 上下文視窗的模型為 100 張）。如果您發送許多圖像或大型文件，您可能會在達到 token 限制之前先達到請求大小限制。

請參閱模型比較表以了解各模型的上下文視窗大小列表。



上下文視窗與思考

使用思考時，所有輸入和輸出 token（包括思考 token）都計入上下文視窗限制，在多輪情況下有一些細微差異。

思考 token 是您的 max_tokens 參數的子集，按輸出 token 計費，並計入速率限制。使用自適應思考時，Claude 會動態決定其思考分配，因此思考 token 的使用量會因請求而異。

先前助手輪次的思考區塊是否保留在上下文視窗中取決於模型。在 Claude Opus 4.5 及更新的 Opus 模型、Claude Sonnet 4.6 及更新的 Sonnet 模型、Claude Fable 5、Claude Mythos 5 和 Claude Mythos Preview 上，API 預設會保留先前的思考區塊，它們像任何其他輸入 token 一樣計入上下文視窗。在較早的 Opus 和 Sonnet 模型以及所有 Haiku 模型上，當您將先前的思考區塊傳回時，API 會自動從對話歷史記錄中移除它們，這為對話內容保留了 token 容量。有關各模型的預設值，請參閱各模型的思考區塊保留。若要在任一方向上覆寫預設值，請使用思考區塊清除。

下圖顯示了在會移除先前思考區塊的模型上啟用思考時如何管理 token：

• 移除思考區塊： 在會移除先前思考區塊的模型上，思考區塊（以深灰色顯示）在每個輪次的輸出階段生成，但不會作為後續輪次的輸入 token 向前傳遞。您不需要自己移除思考區塊：如果您將它們傳回，Claude API 會自動移除它們。
• 計費： 思考 token 在生成時按輸出 token 計費一次。在會保留先前思考區塊的模型上，保留的區塊隨後成為後續請求輸入的一部分，並像對話歷史記錄的其餘部分一樣按輸入 token 計費。



上下文視窗與思考和工具使用

下圖說明了在會移除先前思考區塊的模型上，當您將思考與工具使用結合時如何管理 token：

• 工具使用與思考的注意事項：
  • 當您發布工具結果時，您必須包含伴隨該工具請求的完整未修改思考區塊，包括其簽名。
  • API 使用加密簽名來驗證思考區塊的真實性。如果您修改思考區塊，API 會返回錯誤。

若要減少工具定義本身消耗的上下文，請參閱管理工具上下文，或使用工具搜尋工具延遲工具定義。



上下文感知

Claude Sonnet 5、Claude Sonnet 4.6、Claude Sonnet 4.5 和 Claude Haiku 4.5 具有上下文感知（context awareness）： 這些模型在整個對話過程中追蹤其剩餘的上下文視窗（其「token 預算」）。這讓模型可以根據剩餘空間管理長時間運行的任務，而不是猜測還剩多少 token。上下文感知是自動的：您不需要啟用任何東西，也永遠不需要自己發送本節中顯示的標籤。API 會注入它們。



運作方式

在每個請求的系統提示中，API 會告知 Claude 其總上下文視窗：

<budget:token_budget>200000</budget:token_budget>

預算與您的請求可用的上下文視窗相符：Claude Sonnet 5 和 Claude Sonnet 4.6 為 1M token，Claude Sonnet 4.5 和 Claude Haiku 4.5 為 200k token。本節中的範例顯示的是具有 200k token 上下文視窗的模型。

在每次工具呼叫之後，API 會向 Claude 提供其剩餘容量的更新：

<system_warning>Token usage: 35000/200000; 165000 remaining</system_warning>

圖像 token 包含在這些預算中。

Claude Opus 4.7 及更新的 Opus 模型、Claude Fable 5 和 Claude Mythos 5 不會收到這些注入的標籤。在 Claude Opus 4.7 及更新的 Opus 模型、Claude Fable 5 和 Claude Mythos 5 上，您可以使用任務預算（目前為 beta 版）為模型提供明確的預算。

有關使用上下文感知的提示指南，請參閱提示最佳實踐。



使用壓縮管理上下文

如果您的對話經常接近上下文視窗限制，請使用伺服器端壓縮。壓縮會在伺服器上自動總結對話的較早部分，因此對話可以在超過上下文視窗限制後繼續進行。它在 Claude 4.6 及更新的模型和 Claude Mythos Preview 上以 beta 版提供。

對於更專門的需求，上下文編輯提供了額外的策略：

• 工具結果清除： 在代理工作流程中清除舊的工具結果
• 思考區塊清除： 在使用擴展思考時管理思考區塊

快取的提示前綴仍然佔用上下文視窗：提示快取改變的是您為這些 token 支付的費用，而不是它們是否被計入。



上下文視窗溢出行為

如果僅輸入就已經超過模型的上下文視窗，API 會在每個模型上返回 400 invalid_request_error（「prompt is too long」）。

在 Claude 4.5 及更新的模型上，如果輸入 token 加上 max_tokens 超過上下文視窗大小，API 會接受該請求。如果生成隨後達到上下文視窗限制，它會以 stop_reason: "model_context_window_exceeded" 停止。在較早的模型上，API 會改為返回驗證錯誤。若要在這些模型上選擇啟用 model_context_window_exceeded 行為，請使用 model-context-window-exceeded-2025-08-26 beta 標頭。詳情請參閱停止原因和後備方案。

若要保持在上下文視窗限制內，請使用 token 計數 API 在向 Claude 發送訊息之前估算 token 使用量。



後續步驟