Anthropic 全量開放 100 萬上下文：Opus 4.6 不加價，支援 600 頁檔案

如果你用 AI 跑過複雜的程式碼排錯，或者讓它讀過幾百頁的厚合同，大概都遇過一種尷尬：剛聊到關鍵步驟，模型突然開始前言不搭後語。問題不是它笨，而是之前的對話被壓縮或擠出去了。

Anthropic 正式將 Claude Opus 4.6 和 Sonnet 4.6 的 100 萬 token 上下文視窗轉為全面可用（GA）。更關鍵的是，他們取消了長上下文的加價策略。

長上下文不加價，圖片和 PDF 能塞 600 頁

在此之前，行業裡處理超長上下文通常要收一筆溢價，或者給更嚴格的速率限制。

這次 Anthropic 明確按標準費率結算，不管請求有多長。Opus 4.6 的百萬 token 價格維持在輸入 5 美元、輸出 25 美元，Sonnet 4.6 則是輸入 3 美元、輸出 15 美元。也就是說，塞進 90 萬 token 的計費單價，和呼叫 9000 token 沒有任何區別。

同時放寬的還有多模態輸入上限。單次請求支援的圖片或 PDF 頁數，從原來的 100 翻了六倍，一口氣拉到了 600。

開發者也不用在 API 請求頭裡帶 beta 標籤了，超過 20 萬 token 的請求會自動走長視窗。這項能力除了 Claude 自家平臺，也同步在 Amazon Bedrock、Google Cloud Vertex AI 和 Microsoft Foundry 上線。

至於訂閱了 Max、Team 和 Enterprise 的 Claude Code 使用者，Opus 4.6 已經預設開啟 100 萬 token 上下文。

解決長跑 Agent 的健忘症

模型能裝下 100 萬 token，和它能在 100 萬 token 裡找準線索，完全是兩碼事。按照 Anthropic 的資料，Opus 4.6 在長文本基準測試 MRCR v2 上拿到 78.3% 的得分，是目前該長度下前沿模型的最高水平。

在實際生產環境裡，很多團隊吃過頻繁上下文壓縮的苦頭。有工程師反饋，用 Claude Code 連續排查 Datadog、程式碼庫和資料庫，很容易燒掉 10 萬以上的 token，一旦觸發系統自動壓縮，核心細節就會丟失，排錯直接陷入死迴圈。

Cognition 團隊也提到，他們的 Devin 程式碼審查 Agent 以前很難把大型程式碼 diff 塞進 200K 視窗，只能切塊處理，經常漏掉跨檔案的呼叫依賴。現在直接塞入完整改動，審查質量和效率反而更高了。

甚至有開發團隊發現，把視窗從 20 萬放到 50 萬之後，消耗的 token 總量反而變少了。原因很簡單：模型不再需要為了省地方反覆做有損總結和多輪重試。

為什麼重要

我們認為，Anthropic 這次最狠的一刀其實砍在商業模式上，而不是單純堆引數。

此前行業裡的超長上下文大多更像展示肌肉的櫥窗功能，要麼單價翻倍，要麼限流嚴重，開發者根本不敢在生產環境常態化開啟。Anthropic 實行長短同價，基本上逼著競品放棄長上下文溢價這條路，直接把百萬上下文從高階實驗品打成了通用基建。

對開發者和企業使用者來說，這意味著複雜的 RAG 架構和切塊管道可以大幅精簡了。特別是法律合同比對、多輪審計排錯和跨程式碼庫重構這些場景，以前為了省 token 做的切片與摘要工程，很多都可以直接扔掉。

不過這也帶來了一個現實問題：賬單上限更容易失控。雖然單價沒變，但單次呼叫打滿 90 萬 token，一進一齣就是幾美元。普通開發者如果不做呼叫防護，長跑 Agent 很容易在不知不覺中刷出高額賬單。它很強大，但用起來依然需要剋制。