Claude Sonnet 5是什麼？1M Context、Adaptive Thinking、API價格與企業遷移

Claude Sonnet 5是什麼？1M Context、Adaptive Thinking、API價格與企業遷移

Claude Sonnet 5是Anthropic於2026年6月30日發布的Sonnet級模型，定位在Coding、Agent、Tool Use和專業知識工作。API Model ID為claude-sonnet-5，並以Adaptive Thinking與Effort控制，在成本和能力之間提供多個工作點。

Sonnet 5不是只換Model ID。企業遷移需要重新計算Token、移除舊Manual Extended Thinking設定、檢查Sampling Parameter、重跑Prompt Cache與Tool Schema，並用Golden Set比較Sonnet 4.6的品質、延遲、成本和失敗分布。

• Claude Sonnet 5於2026年6月30日正式發布。
• API Model ID為claude-sonnet-5。
• 提供1M Token Context與128K最大輸出。
• Adaptive Thinking預設管理推理過程，使用effort控制程度。
• Effort可用Low、Medium、High與X-high等級，實際可用值以API文件為準。
• Introductory API價格至2026年8月31日為Input 2美元／MTok、Output 10美元／MTok。
• 2026年9月1日起標準價格為Input 3美元／MTok、Output 15美元／MTok。
• Anthropic公布的Benchmark屬供應商自報，需用私有任務重測。
• 遷移要建立Canary、Rollback和Cost per Accepted Task。

文章實體化：Claude Sonnet 5、1M Context、Adaptive Thinking、API價格與企業遷移

Claude Sonnet 5 的產品比較應把 1M Context、Adaptive Thinking、API 價格、速率限制、資料政策與企業遷移分開。上下文上限不等於每次請求都適合塞滿文件，Adaptive Thinking 也需要觀察延遲、成本、品質和可控性；企業遷移還涉及 SDK、權限、日誌、評估與回滾。2026 的模型名稱、價格和功能會更新，文章應標示查詢日期並以官方模型卡與價格頁核對。

• 人物／作品：Claude Sonnet 5、1M Context、Adaptive Thinking、API價格與企業遷移與文中相關角色、場景、社群或音樂節點。
• 關係脈絡：把人物、作品、地理與產業機制連回具體的創作選擇。
• 閱讀線索：沿著具名實體閱讀，區分作品分析、節目資訊與仍需查證的內容。

本文以「Claude Sonnet 5、1M Context、Adaptive Thinking、API價格與企業遷移」為主線，補回人物、組織、作品、技術節點、場景與它們之間的關係，讓讀者能從具名實體一路追到實際流程、文化語境與影響。

官方定位與Availability

Anthropic將Sonnet 5定位為目前最具Agent能力的Sonnet模型，可規劃、使用Browser與Terminal等工具，並完成過去需要更高階模型的長任務。

• Free與Pro方案的預設模型。
• Max、Team與Enterprise可用。
• Claude Code與Claude Platform可用。
• API使用claude-sonnet-5。
• 實際Rate Limit、Region與Feature依方案和文件為準。

核心規格

1M Context是上限，不代表每個Request都應載入1M Tokens。更長Context會增加成本、Latency、Stale Data與Review負擔，應使用Context Builder和Prompt Cache。

Adaptive Thinking

Adaptive Thinking讓模型依任務和Effort設定調整推理深度。開發者不再需要使用舊式Manual Extended Thinking Budget控制每一個Thinking Token。

不同Effort不是固定性能承諾。企業應對每類Task做Budget Sweep，找出達到門檻的最低Effort。

API價格

價格只包含基礎Token。Agent任務還有Tool Use、Web Search、Retry、Prompt Cache、Human Review與外部服務成本。

total_task_cost =
input_tokens
+ cache_write_and_read
+ output_tokens
+ server_tools
+ retries
+ human_review

Prompt Cache與Batch

• 穩定System Prompt、Tool Schema和長文件可建立Cache Prefix。
• 動態User Data放在Prefix後方。
• Cache命中率要由Usage資料驗證。
• 非即時大量任務可評估Batch API。
• 長Context價格和Cache規則要查看當期官方文件。

Introductory價格結束後，Cache和Batch策略對大量工作流影響會更明顯。

新Tokenizer與Token重算

Anthropic的遷移說明指出，Sonnet 5使用新的Tokenizer，相同文字可能產生不同、甚至更多Token。舊模型的成本試算和Context Safety Margin不能直接沿用。

• 重新計算System Prompt與Tool Schema。
• 重跑長文件和多語言Token Count。
• 檢查繁中、Code、JSON和XML差異。
• 降低接近1M上限的Request。
• 更新Billing Alert和Output Limit。

Manual Extended Thinking遷移

Sonnet 5不再沿用舊式Manual Extended Thinking控制。原先以Thinking Budget或相關欄位調整推理的程式，需要改成Adaptive Thinking與Effort。

old:
  model: sonnet-4.6
  manual_thinking_budget: fixed

new:
  model: claude-sonnet-5
  effort: medium
  acceptance: task-specific

• 移除不支援的Thinking設定。
• 用Effort控制品質和成本。
• 不要把舊Budget數值直接映射到Effort。
• 重新測Output Length和Latency。

Sampling Parameter

官方遷移說明要求檢查非預設temperature、top_p和top_k。Sonnet 5不支援的組合可能回傳API錯誤，應在Canary前移除或改用官方允許設定。

• 搜尋Codebase中的Sampling設定。
• 建立API Contract Test。
• 不要吞掉400類錯誤後無限Retry。
• Structured Output以Schema和Validation控制。
• 創意多樣性用多候選和Rubric測試。

Tool Use與Agent

• 重新測Tool Selection和Argument Schema。
• 檢查Browser、Terminal和Computer Use權限。
• 長任務保存Checkpoint與Compaction。
• Tool Result視為外部資料，防止Prompt Injection。
• 高風險Action保留Preview、Approval與Idempotency。
• 設定Max Turn、Wall-clock和Cost Budget。

Sonnet 5更Agentic不等於可以提高Default Permission。能力和權限需要分開評估。

Vendor-reported Benchmark

Anthropic公布Sonnet 5在Coding、Agentic Search、Computer Use和Knowledge Work等評測相較Sonnet 4.6提升，部分高Effort任務接近Opus 4.8。這些結果屬供應商自報，使用了特定Method、Tool和Token Budget。

• 記錄Benchmark版本和Methodology。
• 比較時使用相同Effort與價格。
• 注意官方曾更新BrowseComp圖表方法。
• 不要把單一Benchmark直接換算成企業成功率。
• 私有Golden Set必須包含失敗和高風險Case。

Sonnet 4.6遷移清單

1. 將Model ID改為claude-sonnet-5。
2. 重新Token Count和Context Margin。
3. 移除Manual Extended Thinking設定。
4. 檢查Sampling Parameter。
5. 重跑Tool Schema與Structured Output。
6. 比較Low至X-high Effort。
7. 測Cache、Batch和Server Tool成本。
8. 建立Canary和Rollback。
9. 更新Dashboard、Alert和Runbook。

Golden Set

migration_metrics:
  accepted_task_rate
  critical_error
  p50_p95_latency
  input_output_tokens
  cache_hit_rate
  tool_retries
  human_edit_minutes
  cost_per_accepted_task

Canary與Rollback

• 先處理低風險內部流量。
• 保留Sonnet 4.6或核准Fallback。
• 比較相同Task和Human Review。
• Critical Error立即停止Canary。
• 保存Prompt、Model、Effort和Tool Version。
• Introductory價格結束前重新做成本Review。

資料和區域

企業應依Anthropic API、Claude Code、AWS Bedrock或Google Vertex的實際合約，確認Zero Data Retention、Region、Subprocessor和Data Use。不同接入面不應假設使用相同條款。

• 確認API Organization是否啟用ZDR。
• Local Claude Code Session可能保存在本機。
• Feedback和Support資料使用另行確認。
• Cloud Provider條款和Anthropic 1P不同。
• 敏感工作建立Data Classification與Audit。

推理算力路由可閱讀推理模型怎麼分配算力？；Fable 5事件可閱讀Claude Fable 5為何曾停用？。

常見問題

Sonnet 5比Sonnet 4.6便宜嗎？

至2026年8月31日有2／10美元Introductory Pricing，之後為3／15美元，和Sonnet 4.6標準價相近。總成本還受Token、Effort、Tool和Retry影響。

1M Context需要全部使用嗎？

不需要。只載入會改變任務判斷的資料，使用Retrieval、Cache和Compaction控制成本與舊版本。

可以只改Model ID直接上線嗎？

不應。Tokenizer、Thinking、Sampling、Tool Behavior和Cost都可能不同，需要Golden Set和Canary。

官方資料

• Anthropic：Introducing Claude Sonnet 5
• Anthropic API Pricing

Sonnet 5的價值，不只在更高Benchmark，而在同一模型能用Effort覆蓋更多成本與能力區間。企業遷移要把1M Context、Tokenizer、Tool Use和價格放進同一組Eval，才能知道它是否真正取代Sonnet 4.6。

想延伸閱讀相關主題，可參考 AI 與科技主題整理。

Claude Sonnet 5 的真正變化：不是把視窗拉長，而是把工作流程重新設計

Claude Sonnet 5 的討論很容易被「1M Context」四個字帶走，好像只要把更多文件塞進一次請求，模型就會自然變得更可靠。這個理解太簡單。長上下文首先是一個工程能力，接著才是一個產品能力；它改變的是資料如何被組織、哪些內容應該留在同一個任務、哪些內容仍然要透過檢索與工具取得，以及團隊要用什麼方式判斷模型是否真的讀懂了資料。對企業而言，真正的升級不是把提示詞變長，而是把工作流從「一次問答」改成可以追蹤、測試、分段與回滾的系統。

Anthropic 的官方 Sonnet 頁面確認，Claude Sonnet 5 可透過 Claude API、Anthropic 平台，以及 AWS、Google Cloud、Microsoft Foundry 等管道使用；官方頁面也列出 1M context，以及截至 2026 年 8 月 31 日的介紹期每百萬 input tokens 2 美元、每百萬 output tokens 10 美元，之後回到每百萬 input tokens 3 美元、每百萬 output tokens 15 美元。這些是產品與價格資訊，不等於任何團隊都會用相同成本得到相同效果；實際帳單還會受到輸入長度、輸出長度、快取、批次、工具呼叫與重試策略影響。

因此，本文把官方已公開的規格和實作建議分開。官方資料可以回答「有沒有 1M context」「價格何時改變」「可以從哪些平台呼叫」；至於「要不要把完整資料放進去」「怎樣設計權限」「何時觸發人工審查」，則是導入團隊必須自己驗證的工程決策。這個區分很重要，因為模型的上限不會自動替代資料治理、測試資料集與人類責任。

1M Context 到底改變什麼？先從「能放下」與「值得放下」分開

長上下文的第一個好處，是讓一個任務可以同時看到較完整的背景：多份規格、長篇程式碼、會議紀錄、合約版本、客服對話或一個專案的歷史決策。過去需要把資料切成許多小段、靠人工維持摘要的工作，現在可能可以用較大的單一上下文處理。不過「放得下」只是一個容量條件，並不保證模型會平等地注意每一段內容，也不保證文件之間沒有矛盾。長文本仍需要標題、時間戳、來源、版本與優先順序，否則增加的只是可讀資料量，不是可驗證的理解。

第二個問題是新鮮度。把一整個知識庫長期放在提示詞裡，可能讓工作流看起來簡單，卻會把過期條款、舊價格、撤銷的權限與已失效的流程一起帶進回答。對即時性高的內容，仍應優先從受控工具或檢索層取得最新狀態；長上下文比較適合承載「本次任務需要一起比較的材料」，而不是取代所有資料來源。理想架構通常是固定政策與任務背景放入上下文，變動資料透過有記錄的工具呼叫讀取，最後把引用與版本一併寫入結果。

第三個問題是上下文的邊界。真正可維護的長上下文，不應該是一個無限延伸的垃圾桶。每一份資料都要有用途：它是規則、事實、例外、反例、輸出格式，還是待核對的線索？若同一個請求同時放入互相衝突的政策，系統就必須明確標出優先順序，不能期待模型替團隊猜測哪一版是正確的。這也是為什麼長上下文導入通常要搭配文件清單、版本欄位、資料擁有者與過期策略。

Adaptive Thinking 與 Effort：把推理預算當成可觀測的資源

Claude Sonnet 5 的 Adaptive Thinking 概念，適合被理解成「每個請求需要多少推理投入」的控制問題，而不是一個神奇的正確率開關。簡單分類、格式轉換、已知欄位抽取，通常不值得消耗與複雜分析同等的推理預算；跨文件矛盾比對、程式碼修改、合約風險辨識或需要多步工具使用的任務，才可能需要更高的思考投入。這裡的重點不是永遠把 effort 調到最高，而是讓任務類型與成本、延遲、品質要求有明確關聯。

導入時可以先建立四級任務表。低投入處理明確的摘要、標籤與格式化；中投入處理多段資料的對照與有固定答案的分類；高投入處理需要引用、計算、工具調度與例外判斷的工作；最高投入只保留給高價值且有人審查的複雜任務。這不是 Anthropic 對所有企業的官方規定，而是一種可測試的內部策略。每級都要記錄平均輸入 token、輸出 token、延遲、重試率、人工退回率與錯誤類型，否則「提高 effort 後變好」只是一種印象。

更穩妥的做法是把 effort 視為預算，而不是結果保證。當任務的風險高於預設閾值時，可以升級推理投入或轉交人工；當輸入缺少關鍵資料時，應先提出補件或使用工具查詢，而不是讓模型以更長的思考掩蓋證據不足。系統也應避免把內部思考文字直接當成稽核證據，對外保存的是輸入版本、工具結果、引用、結論與人工核准狀態。

API 價格怎麼估？用工作單位算，不要只看每百萬 token

最基本的估算公式是：單次成本等於 input tokens 除以一百萬乘以 input 單價，加上 output tokens 除以一百萬乘以 output 單價。若採用官方介紹期的 2 美元與 10 美元價格，一次 100,000 input tokens、10,000 output tokens 的請求，粗略成本是 0.2 加 0.1，也就是 0.3 美元；這只是未計入快取、工具、批次、平台差異與重試的模型 token 粗估。之後價格變成 3 美元與 15 美元，同一組 token 量就會是 0.3 加 0.15，即 0.45 美元。實際上線前應以當下官方 pricing 文件和所選平台的帳單規則重新核對。

企業更需要追蹤的是「每個完成工作」的成本，而不是漂亮的單次價格。例如客服案件可能需要一次分類、一次查詢、一次草稿與一次安全檢查；程式碼代理可能重複讀取相同檔案並呼叫數個工具。把每個請求都視為孤立樣本，會低估上下文重送、失敗重試與人工重作的成本。建議在應用層建立 job id，保存模型版本、請求類型、token 數、工具次數、延遲、重試原因與人工處理結果，再以「每個成功且被採用的工作」計算單位經濟。

快取與批次可以改善成本，但也會改變資料生命週期。固定的系統提示、產品規格或共用政策若長時間不變，適合評估快取；含有個資、短期權限或尚未公開的文件，則必須先確認快取的保存時間、隔離方式與清除機制。批次工作適合離線分類、資料清理與夜間評估，不適合需要立即回覆或遇到錯誤就必須停止的高風險決策。省下 token 費用，不能用更大的資料暴露或更長的錯誤延遲換來。

從 Sonnet 4.6 遷移到 Sonnet 5：先做契約測試，再改 production

模型遷移不應該只把 model id 替換掉就提交。第一層是請求契約：確認新的 model id、訊息格式、輸出上限、思考設定、取樣參數與工具欄位是否被目前 SDK 正確傳送。第二層是資料契約：確認原本的 tokenizer 預估、截斷位置、附件處理、編碼與特殊字元不會讓長文件在進入模型前被錯誤切掉。第三層是結果契約：確認下游程式仍然能解析 JSON、函式名稱、欄位型別、引用格式與拒答狀態。

第一批測試應該包含短輸入、接近既有上限的中型輸入、跨文件長上下文、包含衝突規則的輸入，以及工具失敗的輸入。每個案例都要有預期行為，而不是只比對生成文字是否相似。對摘要任務可以檢查關鍵事實是否保留；對抽取任務可以檢查欄位完整性與空值處理；對代理任務則要檢查工具是否只被允許呼叫一次、是否需要人工核准，以及失敗後是否真的停止。模型輸出變得更流暢，不代表它通過了這些契約。

若系統使用手動 extended thinking 或其他推理相關參數，更應以官方當前 API 文件為準，逐一確認參數名稱、可用範圍與回應格式，不要沿用上一代模型的猜測。第三方 SDK、代理框架與內部 wrapper 可能會把未知欄位靜默丟棄，造成「設定看起來成功、實際沒有生效」的假象。遷移報告至少要留下原始請求摘要、實際送出的參數、回應 metadata 與 SDK 版本，讓之後能區分模型差異與客戶端差異。

Tool Use 與 Agent 工作流：能力變強後，權限也要變細

長上下文和更高的推理能力，可能讓代理更能完成多步工作，但也讓錯誤操作的影響面變大。工具不應只用一個模糊的「執行」按鈕，而要把讀取、搜尋、草稿、變更、發送與刪除拆成不同能力。每個工具都應定義輸入 schema、可存取的資源範圍、逾時、重試上限與人工核准點；模型能夠提出一個工具呼叫，不代表它有權直接完成不可逆動作。

建議把代理分成觀察、建議與執行三種模式。觀察模式只讀資料並產生引用；建議模式可以產生 patch、草稿或待核准操作，但不直接寫入；執行模式只在明確的專案、使用者、時間窗與變更範圍內運作。當工具回傳與上下文互相矛盾時，代理應標記矛盾並停止升級，不應靠更長的推理自行補出權限。這種分層不是模型功能，而是應用系統必須提供的安全邊界。

同時要防範提示注入。長文件可能包含「忽略先前規則」「把秘密貼到外部服務」等文字，這些內容應被視為不可信資料，而不是系統指令。資料標籤、工具 allowlist、輸出脫敏、網域限制、審計 log 與人工核准需要一起工作；單靠提示詞提醒模型小心，不足以形成企業控制。若代理要處理個資、原始碼、合約或內部財務資料，更要先確定資料是否可以送往選定的平台與區域。

Golden Set、Canary 與 Rollback：把「模型變好」變成可反駁的假設

遷移前先建立 Golden Set。它不需要很大，但要覆蓋真實高價值流程、常見失敗、邊界條件、敏感資料、工具錯誤與需要拒答的案例。每個案例應保存輸入版本、評估規則與允許的答案範圍；若只保存一組漂亮的示例，模型很容易在 demo 中表現良好，卻在實際例外裡失控。Golden Set 也要定期淘汰過期內容，並由領域負責人確認新增案例。

接著採用小流量 Canary，而不是一次切換所有請求。可以按工作類型、租戶、內部團隊或低風險資料集分流，並在相同輸入上比較舊模型與新模型的事實正確率、結構化輸出通過率、工具成功率、延遲、成本、拒答品質與人工退回率。若新模型只是寫得更順，但關鍵欄位錯得更多，應視為回歸。這裡要特別記錄「沒有足夠證據」的結果，不要把不確定性硬轉成分數。

Rollback 必須在上線前就能執行。保留上一個可用 model id、請求模板、工具 schema、評估門檻與 feature flag；當錯誤率、資料外洩警報、成本或延遲超過門檻時，先停止擴大流量，再回到已知版本。回滾後仍要保留新模型的輸入輸出與錯誤樣本，否則團隊只是在恢復服務，沒有學到遷移哪個環節出問題。模型升級的完成條件，應是「可觀測、可停止、可回退」，而不只是 API 回傳 200。

如何看 benchmark？把官方數字和自己的工作指標放在兩張表

模型發布頁上的 benchmark 能幫助讀者了解定位與能力方向，但不能直接預測你的客服、程式碼、研究或內容工作流。第一張表可以記錄官方公開的測試名稱、比較對象、日期與測試條件；第二張表則只放自己的 Golden Set 結果、抽樣方式、人工評分規則與失敗案例。兩張表不能混在一起，否則讀者會誤以為外部 benchmark 已經替自己的產品完成驗證。

自己的評估也要避免只看平均分。把錯誤依照嚴重度分級，比較「一百次中多一個小錯字」和「一次錯誤刪除客戶資料」並不合理；前者可以透過人工修正，後者必須在工具層阻止。評估表至少要分開品質、風險、成本與速度四個面向，再由產品負責人決定哪個面向是硬門檻。當資料量不足、案例分布偏斜或評分者不一致時，結論應寫成暫定，不要包裝成普遍能力。

企業導入前的十項檢查清單

• 確認實際呼叫平台、區域、合約與資料處理條款，不能只因模型名稱相同就假設環境相同。
• 確認官方當前價格與工具附加費，並以實際 token 與重試資料估算每個工作單位成本。
• 把模型版本、SDK 版本、請求參數與提示模板固定在可追蹤的變更紀錄。
• 以短、中、長、衝突與工具失敗案例測試輸入長度、截斷與輸出格式。
• 針對每個工具建立最小權限、schema、逾時、重試與人工核准規則。
• 把不可信文件、提示注入、個資與秘密視為安全測試資料，不要只測正常案例。
• 建立 Golden Set，保存評分規則與已知失敗，不用單一 demo 代替驗收。
• 先跑 Canary，設定品質、風險、成本與延遲的停止門檻。
• 在上線前演練回滾，確認舊模型與舊模板仍然可用。
• 每次發布後重新檢查官方文件，因為價格、可用平台與參數可能更新。

結論：Claude Sonnet 5 的價值，取決於團隊是否把容量變成流程

Claude Sonnet 5 的 1M context、Adaptive Thinking 與 agent 導向能力，確實讓長文件、工具協作與複雜任務有更大的設計空間；官方介紹期價格與之後的標準價格，也讓團隊可以提前做成本分界。不過，長上下文不會自動解決過期資料，推理投入不會自動產生正確答案，API 200 也不代表工具工作流安全。能否從上一代平穩遷移，取決於團隊是否把請求、資料、輸出、權限與回滾都寫成可驗證的契約。

比較成熟的導入順序，是先挑一個低風險但有真實價值的工作，建立 Golden Set，記錄舊模型基線，接著用小流量測試新模型。把每次請求的成本、延遲、工具行為、引用與人工結果留存，才能知道改善發生在哪裡，也才能在退化時找到原因。對企業來說，最值得追求的不是「一次讓模型做更多事」，而是讓系統在需要時做得更深，在證據不足時停下來，在失敗時回到安全版本。

資料來源與圖片說明

• Anthropic 官方 Claude Sonnet 頁面：核對 Claude Sonnet 5 的 1M context、可用平台與 2026 年 8 月 31 日前後的官方價格說明。
• Claude 官方定價文件：核對當前 API 定價與可能影響成本估算的官方說明；實際上線前應再次查閱。
• Claude 官方 Context Windows 文件：核對 1M context 的使用脈絡與上下文相關行為；應依實際平台與版本重新驗證。
• Anthropic 官方 Claude Sonnet 5 公告：作為產品發布脈絡的官方來源。

本次新增圖片是長上下文、工具節點、推理訊號、成本與遷移路徑的原創編輯示意圖，不使用 Anthropic 商標、產品介面、真人肖像或可辨識的官方截圖；圖片只協助讀者理解系統概念，不取代官方文件、價格頁或實際 API 測試。