ModelosPreciosDocumentaciónAcerca de
Iniciar sesión[ Obtener clave API ]
cd ../back to blog
$Review//June 4, 2026//7 min read

Claude Opus、Sonnet、Haiku：哪一個該在什麼時候用

拆解 Claude 三層模型各自擅長什麼、在 Brievio 上分別多少錢，以及一套「預設往下分層、按需往上升級」的省錢路由模式。

Claude 不是單一一個模型 — 它是一份分層清單。Opus 是最深的推理者, Sonnet 是均衡的主力,Haiku 則是又快又便宜的那一個。團隊最常犯的 錯誤,就是為了「保險起見」事事都挑頂規,然後眼睜睜看著帳單因為一些 小模型本來就能漂亮搞定的工作而越爬越高。反過來的錯誤 — 為了省錢 硬把每件難事都塞進 Haiku — 則會在重試、錯誤答案和人工善後上悄悄 付出代價。正確答案幾乎從來不是「單一模型」。而是 讓分層去對應任務。

這篇文章會講清楚每一層 Claude 究竟擅長什麼、三者在 Brievio 上各自多少 錢、具體的「什麼時候該用 X」指引,以及一種把簡單工作路由給 Haiku、 只把最難的工作升級到 Opus 的分層模式。Brievio 上的每一層,都是貨真價實 的第一方模型,跑在 AWS Bedrock 之上 — 完整 200K 脈絡、原生 工具、視覺與快取一應俱全 — 定價約比 Anthropic 官方表列低 15%。

三層一覽

整個取捨就在這裡一次說清 — Brievio 費率(附上 Anthropic 官方表列 作為對照),以每 100 萬權杖計,輸入 / 輸出:

  • Claude Opus 4.7 — $4.25 / $21.25 (官方 $5 / $25)。最深的推理,以及最強的代理行為:長篇多步驟 計畫、棘手的重構、模糊的規格、研究等級的分析。最有能耐,也最 昂貴 — 就設計而言,它是你最後才動用的那一個。
  • Claude Sonnet 4.6 — $2.55 / $12.75 (官方 $3 / $15)。均衡的生產主力,也是一流的程式設計師。對多數 團隊而言,這就是預設值:足夠應付絕大多數的實際工作, 快到讓人感覺靈敏,定價也讓你不必為了用量而手軟。
  • Claude Haiku 4.5 — $0.85 / $4.25 (官方 $1 / $5)。又快又便宜,為高流量工作而生:分類、擷取、 路由、標記、短轉換。輸入比 Opus 便宜五倍 — 而且在很窄的任務上, 一樣正確。

留意這個落差。Opus 的輸入是 Haiku 的 5 倍;Opus 的輸出是 Haiku 的 5 倍。在一條跑數百萬次呼叫的流程上,這個倍數就是「微不足道的零頭」 與「財務團隊會來追問的一筆支出」之間的差別。真正的本事不在於挑出 「最好」的模型 — 而在於知道哪些工作真正需要頂層、哪些不需要。

什麼時候該用 Haiku…

只要任務很窄、輸出很短,而且你要跑很多次,Haiku 就是對的選擇。每一次 呼叫的決策很小;真正關鍵的是量。

  • 分類與路由 — 替工單貼標、為內容打標籤、意圖 偵測、垃圾訊息過濾、情緒判斷。答案就是少數幾個選項其中之一; Haiku 做得準,每一千次也只花幾美分。
  • 結構化擷取 — 從發票、電子郵件或日誌裡,依固定 綱要把欄位抽成 JSON。再搭配把綱要拿去做快取,每次呼叫的成本就 趨近於零。
  • 大規模的短轉換 — 摘要一段文字、改寫一句話、 正規化一個數值、產生一個 slug。頻率高,每次風險低。
  • 分層流程裡那道便宜的第一關 — 由它分流,決定 更大的模型到底要不要跑(下面會詳談)。

Haiku 吃力的地方:多步驟推理、細膩的判斷、長線規劃,以及任何「稍微 錯一點就代價高昂」的情況。如果你發現自己得在 Haiku 的輸出外圍加上 重試邏輯和驗證器,那就是該把那件工作往上升一層的訊號。

什麼時候該用 Sonnet…(多數團隊的預設)

Sonnet 是大多數生產流量該落腳的地方。它是一流的程式設計模型、能 穩定遵循複雜指令,而且定價讓你能把它當成日常預設來跑,不必精打細算 地配給。當你拿不準該挑哪一層時,就從這裡起步 — 然後把量大的工作 往下分到 Haiku,把少數真正需要的工作往上升到 Opus。

  • 日常寫程式 — 開發功能、修 bug、產生測試、程式 審查。Sonnet 4.6 在這裡確實夠強,鮮少成為瓶頸。
  • 面向客戶的助理與 RAG 聊天機器人 — 判斷力好、 長答案連貫、工具使用可靠,而且快到足以撐起互動式延遲。
  • 內容與文件工作流 — 草擬、摘要長文件、轉換結構化 內容,品質要緊但又不需要 Opus 等級的推理。
  • 多數代理迴圈 — Sonnet 把多工具代理處理得很好。 把 Opus 保留給那些規劃吃重、或高度模糊的情況。

誠實地說:相當高比例的團隊,其實幾乎所有事都用 Sonnet 跑也沒問題。 之所以還要分層,是因為兩個極端 — 數百萬次微不足道的呼叫,或寥寥 幾件難到不行的工作 — 才是「讓模型對應任務」最能回本的地方。

什麼時候該用 Opus…

Opus 是頂層自有它的道理,但它是要刻意去動用的那一個,而不是預設。 當難度真的撐得起這份成本時才用它 — 也就是當「錯誤或膚淺的答案」 比「多花的那些權杖」更昂貴的時候。

  • 困難的長線代理工作 — 必須跨越許多次工具呼叫 仍保持連貫的多步驟計畫,正是 Sonnet 開始飄移、抓不住主線的 地方。
  • 棘手的重構與架構 — 大型跨檔案變更、麻煩的遷移、 除一個橫跨好幾個系統的錯。
  • 模糊的規格與深度分析 — 研究等級的綜整、細膩的 判斷、那種你會交給自己最資深工程師的問題。
  • 升級的目標 — 當較便宜的層把某個案件標記為困難 時,你的流程往上退守的那個模型。

如果在你的任務上,Opus 與 Sonnet 給出難以分辨的答案,那這件任務本來 就不需要 Opus — 而你剛剛白白付了約 1.7 倍的 Sonnet 費率。要知道答案, 就拿你自己的提示去實際比較它們,而不是假設貴的那個永遠比較好。

那套模式:預設往下分層,按需往上升級

最有槓桿的一步,是別再用單一模型去想,而開始用一座階梯去想。先做 便宜的事;只有當便宜的事不夠用時,才往上升級。因為 Brievio 上的每一層 都共用同一個 base_url 與同一套 SDK,切換分層只是一行 改動 — 動的只有模型字串。

tiering.py
# 一種模型分層模式：先做便宜的事，需要時才往上升級。
# 同一個 base_url、同一套 SDK — 每一層只有模型字串不同。
from openai import OpenAI

client = OpenAI(
    api_key="sk-brievio-...",
    base_url="https://api.brievio.com/v1",
)

# Brievio 每 100 萬權杖費率（輸入 / 輸出）：
#   Haiku 4.5   $0.85 / $4.25    — 快速、便宜、適合高流量
#   Sonnet 4.6  $2.55 / $12.75   — 均衡的生產主力
#   Opus 4.7    $4.25 / $21.25   — 最深的推理，最難的工作

def triage(ticket: str) -> str:
    """由 Haiku 判斷：便宜模型搞得定，還是該升級？"""
    resp = client.chat.completions.create(
        model="claude-haiku-4-5",
        max_tokens=20,
        messages=[
            {"role": "system", "content": "Reply only EASY or HARD."},
            {"role": "user", "content": ticket},
        ],
    )
    return resp.choices[0].message.content.strip()

def answer(ticket: str) -> str:
    tier = "claude-sonnet-4-6" if triage(ticket) == "EASY" else "claude-opus-4-7"
    resp = client.chat.completions.create(
        model=tier,
        max_tokens=800,
        messages=[{"role": "user", "content": ticket}],
    )
    return resp.choices[0].message.content

# 大多數工單在 Haiku + Sonnet 就能解決。Opus 只在真正困難的那一小撮
# 案件才會啟動 — 所以每張工單的平均成本，遠低於全程都用 Opus 的流程。

經濟帳很簡單:一次 Haiku 上的分流呼叫,只花不到一美分的一小部分。 如果它把簡單的大宗路由給 Sonnet、只把困難的少數丟給 Opus,你每件 任務的平均成本就會遠低於全程用 Opus 的流程 — 而在那些確實需要頂層的 案件上,品質毫無損失。對純高流量的工作來說,同一套邏輯反過來也成立, 由 Haiku 把整件工作獨力包辦:

classify.py
# Haiku 真正發揮價值的地方：高流量的分類 / 擷取。
# 以每 100 萬輸入 $0.85 來算，一百萬份短文件只要幾美分，而不是好幾美元。
import json

LABELS = ["bug", "feature_request", "billing", "spam", "other"]

def classify(text: str) -> str:
    resp = client.chat.completions.create(
        model="claude-haiku-4-5",
        max_tokens=10,
        messages=[
            {"role": "system",
             "content": f"Classify into exactly one of: {LABELS}. Reply with the label only."},
            {"role": "user", "content": text},
        ],
    )
    return resp.choices[0].message.content.strip()

# 1,000,000 則進站訊息，每則約 300 個輸入權杖、約 3 個輸出權杖：
#   輸入：300M 權杖 × $0.85 / 1M  = $255
#   輸出：  3M 權杖 × $4.25 / 1M  = 約 $13
# 同樣的工作交給 Opus，輸入要花約 5 倍、輸出也要約 5 倍，而在這麼窄的
# 任務上換不到任何準確度提升。讓分層去對應難度。

兩種模式,一個道理:讓分層去對應難度。 量大與簡單的工作交給 Haiku,生產的主體交給 Sonnet,Opus 則保留給 那些撐得起它的工作。又因為失敗的 4xx/5xx 呼叫在 Brievio 上免費,一次出錯的 升級重試對你毫無花費 — 計量表只在真正完成時才會跳動。

依任務快速挑選

當你只是需要一個答案時,從這裡起步,等你在自己的提示上量過之後再 調整:

  • 大規模分類 / 標記 / 路由 / 擷取 → Haiku 4.5。
  • 日常寫程式、修 bug、測試、程式審查 → Sonnet 4.6。
  • 面向客戶的聊天機器人 / RAG 助理 → Sonnet 4.6。
  • 草擬、摘要、內容工作流 → Sonnet 4.6。
  • 多數多工具代理 → Sonnet 4.6;把規劃吃重的 步驟升級給 Opus。
  • 棘手的重構、模糊的規格、深度分析 → Opus 4.7。
  • 拿不準? → Sonnet 4.6,再把量大的往下分到 Haiku、把最難的往上升到 Opus。

這一切都不需要事先綁定在某一層上。在 Brievio 上拿同一段提示在三者 之間都試一遍,比較答案與權杖數,讓結果替你挑出分層。完整費率卡在 定價頁;若想了解「在不犧牲品質的前提下 壓低成本」這個更廣的策略,請見 成本最佳化手冊 以及我們的 AI API 閘道選用指南。分層分得好,是你手上單一最大的槓桿 — 而它的代價,不過是一個模型 字串。

$ ls ./related