Claude Fable 5：Mythos-class 旗艦模型解析

Claude Fable 5 是 Anthropic 已廣泛發布的 Mythos-class 模型，能力層級高於 Opus，主要面向長程 agentic 工作、大型程式碼遷移、視覺理解與複雜知識工作。它能處理創意寫作，但官方並未將它定位為創意寫作專用模型。以下依 2026 年 8 月 2 日可查到的官方資料，整理 Fable 5 的規格、計價、取得方式與限制。還不熟悉 Claude 各方案與介面定位的讀者，可以先看 Claude 入門懶人包，再回來對照規格。

重點先看

• Fable 5 是 Mythos-class 旗艦，官方定位是高難度推理與長程 agentic 工作，並非創意寫作專用模型。
• Fable 5 與 Mythos 5 使用同一個底層模型；Fable 5 加入安全分類器，Mythos 5 則透過 Project Glasswing 限量提供。
• Claude API 標準價為每百萬輸入 tokens 10 美元、每百萬輸出 tokens 50 美元；快取命中與更新為每百萬 tokens 1 美元。
• API 遇到分類器拒絕時會回傳 HTTP 200 與 stop_reason: "refusal"。若要改由其他模型處理，必須設定 fallback。
• Fable 5 是 Covered Model，提示與輸出會保留 30 天；遭安全系統標記或依法須保存時，可能保留更久。adaptive thinking 無法關閉，原始 chain-of-thought 不會回傳，但可要求思考摘要。
• 取得管道包含 Claude API、Amazon Bedrock、Claude Platform on AWS、Google Cloud、Microsoft Foundry，以及 Claude 的付費方案。

目錄

• 先確認定位：Fable 5 的官方用途
• 長程 agentic 任務長什麼樣：判斷面向與常見誤解
• Fable 5 與 Mythos 5：同一個模型，安全分類器的差異
• 旗艦的計價：10/50 背後要算的三件事
• 模型規格與取得入口
• refusal 會回傳 HTTP 200：fallback 需要明確設定
• 兩項採用條件：資料保留與 always-on thinking
• 從下線到重新部署：19 天內發生了什麼
• 決策矩陣：什麼任務該上 Fable 5
• 升級前的評測：用自家任務判斷，不看榜單
• 創意寫作誤解的由來，與適合使用的任務
• 怎麼判讀官方的能力宣稱
• 常見問題
• 結論與下一步

先確認定位：Fable 5 的官方用途

Anthropic 的模型文件將 Fable 5 定位為旗下能力最高、已廣泛發布的模型，用於高難度推理與長程 agentic 工作。官方也將 Mythos-class 定義為能力高於 Opus 的模型層級。

它是通用旗艦模型。Anthropic 在產品與發布資料中著重軟體工程、知識工作與視覺理解。這些任務通常包含多個階段、執行時間較長，也需要模型在長脈絡中維持目標。

目前沒有 Anthropic 官方資料將 Fable 5 定位為「創意寫作模型」。Fable 在英文裡有寓言、故事的意思；官方列出的能力包含 creative tasks，產品定位則著重長時間執行的 agent、程式開發、視覺與複雜知識工作。

使用 Fable 5 處理短問答或一般改寫並非不可行，但官方定價較高，模型比較表也將其相對延遲列為 slower。是否值得使用，應以自家任務的品質、成本與延遲評測判斷。

長程 agentic 指模型在多次工具呼叫、多輪回饋與長脈絡中持續執行同一個目標。流程可能包含讀檔、修改程式碼、執行測試，再依結果修正。Anthropic 表示，Fable 5 的自主執行可延伸到數小時甚至數天；這是官方能力宣稱，實際時間仍受任務、工具、逾時設定與 agent 架構影響。

模型能力不能取代工程設計。錯誤復原、狀態管理、測試與權限邊界若未處理好，較高的單次呼叫成本也會放大失敗代價。

長程 agentic 任務長什麼樣：判斷面向與常見誤解

步驟多不一定等於長程 agentic。判斷時要看模型是否必須經過多次工具呼叫與回饋，持續往同一個目標推進，並在出錯後調整下一步。

長 prompt 仍可能只是單次問答；agent 任務則可能反覆讀檔、改程式碼、跑測試、檢查結果再修正。官方把 Fable 5 的主要場景放在長程 agent，是因為這類任務特別依賴長脈絡中的目標維持與自我檢查。

可以從以下面向判斷：

常見誤解包括：

判斷時可以依序問三個問題：模型拿到工具回傳值後，是否必須調整下一步？脈絡會不會隨回合累積，而且每一輪都要帶著舊狀態前進？任務能在單次回應內完成，還是必須分多回合收斂？三題都偏向「是」，比較接近長程 agentic；若有一題明確為否，可先測試單輪模型或固定 pipeline，不必直接採用長程 agent 架構。

例如，客服後台依使用者描述分類工單、查詢一次資料庫再寫回結果，比較接近帶工具的單輪任務。若流程還要在多輪對話中追問、補件、修正判斷，並跨系統整理脈絡，就比較接近長程 agentic，可將 Fable 5 納入評測。

先分類任務，再決定哪些工作需要 Fable 5，能避免把高頻、低難度的呼叫全部交給最高價模型。模型提供推理能力，agent 能否完成工作仍取決於整套執行迴路。

Fable 5 與 Mythos 5：同一個模型，安全分類器的差異

根據 Anthropic 的官方說明，Fable 5 與 Mythos 5 使用同一個底層模型，規格與價格相同。Fable 5 加入安全分類器；Mythos 5 不含這些分類器，只提供給 Project Glasswing 核准的客戶。

Fable 5 的拒絕類別包括可能造成資安、生物或一般危害的內容，以及可能協助開發競爭模型或擷取內部推理的請求。分類器採保守設定，無害的資安、生命科學或機器學習工作也可能被攔。Mythos 5 沒有公開的自助註冊入口。

命名關係也有官方說明。Anthropic 表示 Fable 源自拉丁文 fabula，與希臘文 mythos 相近；兩個名稱用來區分加入安全防護的 Fable 與受控供應的 Mythos。這項命名說明與創意寫作的產品定位無關。

一般開發者能直接申請的是 Fable 5。Mythos 5 屬於 Project Glasswing 的限量核准軌道，做模型選擇、成本估算與系統設計時，應以 Fable 5 的實際限制為準。

旗艦的計價：10/50 背後要算的三件事

依 Claude Platform 定價頁，Fable 5 的 Claude API 標準價為每百萬輸入 tokens 10 美元、每百萬輸出 tokens 50 美元。五分鐘快取寫入為 12.50 美元、1 小時快取寫入為 20 美元，快取命中與更新為 1 美元，幣別皆為美元。

估算時還要把快取、推論地區與實際輸出量算進去。

Fable 5 支援 prompt caching。快取命中的費率是標準輸入價的一成，建立快取則比一般輸入貴。預設有效期為 5 分鐘，每次命中會更新有效期；需要較長間隔時，可使用成本較高的 1 小時快取。只有相同的提示前綴在有效期內再次使用，才適用快取命中費率。

美國境內推論的 1.1 倍價格也有適用範圍。在 Claude API 與 Claude Platform on AWS 使用 inference_geo: "us"，以及 Microsoft Foundry 採用 US Data Zone Standard 部署時，所有 token 計價類別都乘以 1.1。Amazon Bedrock 與 Google Cloud 的區域價格由各平台另訂。

以下是按官方費率計算的示意，並非實測基準。假設一個 coding agent 建立 100 萬 tokens 的五分鐘快取，之後命中一次，另有 100 萬 tokens 的新輸入，並產生 20 萬輸出 tokens：

1. 快取寫入與命中：12.50 美元加 1 美元。
2. 新輸入：100 萬 tokens，10 美元。
3. 輸出：20 萬 tokens，10 美元。

合計為 33.50 美元，尚未計入伺服器端工具、區域倍率或其他回合。提示前綴無法重複使用時，就沒有快取命中折扣；輸出量增加也會直接推高費用。

快取效益取決於相同前綴能否在有效期內再次使用。長任務若每輪都改動前綴、切換 effort，或兩輪間隔超過快取期限，原本預估的節省可能不會出現。

常見的快取失效情況如下：

安排 prompt 時，可以把穩定的系統提示、工具定義與長文件放在前段，把會變動的使用者輸入、變數與時間戳記放在後段。實際是否命中，仍應以 API 回傳的快取用量欄位確認。

不同工作負載的成本來源也不同：

輸出費率是標準輸入費率的五倍，thinking tokens 也按輸出 tokens 計費。effort 可調整模型投入的推理與整體輸出量，但單純隱藏思考內容不會免除 thinking 的費用。價格與平台條件可能調整，正式估價前仍應查看官方定價頁與實際用量。

估算時應把 token 用量與快取命中率分開記錄。API 回應的 usage 欄位會回報輸入、輸出、快取寫入與快取讀取量；thinking tokens 位於 usage.output_tokens_details.thinking_tokens。記錄這些欄位，才能區分輸出增加與快取失效造成的成本。

追蹤時可觀察快取命中佔總輸入的比例、同類任務的回合數，以及 thinking tokens 佔輸出的比例。數值出現異常時，再檢查 prompt 結構、工具定義與 effort 設定。

模型規格與取得入口

Fable 5 的 API 模型 ID 是 claude-fable-5，預設 context window 為 1M tokens，單次請求最多輸出 128K tokens。這些是容量上限，不代表模型能可靠處理任何接近上限的程式碼庫或文件；實際效果仍要用自己的資料測試。

官方 models overview列出的 reliable knowledge cutoff 與 training data cutoff 都是 2026 年 1 月。這不表示該日期以前的知識必然正確，也不代表模型完全不知道後來的資訊。處理近期事件、新版 API 或新產品時，仍應查閱可追溯的外部來源。

Fable 5 目前有以下取得管道：

截至 2026 年 8 月 2 日，Fable 5 可在 Pro、Max、Team 與 Enterprise 付費方案使用，但各方案的內含額度不同。Claude Help Center說明，自 2026 年 7 月 20 日起，Max、Team 的 Premium 席次與舊版席次制 Enterprise 的 Premium 席次，可在每週方案額度中使用 Fable 5，最高佔每週額度的 50%，這部分不另收費；超過後可改用 usage credits。Pro、Team 的 Standard 席次與舊版席次制 Enterprise 的 Standard 席次則使用 usage credits。用量制 Enterprise 與 Claude API 按標準 API 費率計價。Free 方案不提供 Fable 5。方案內容可能調整，實際額度與費用以官方方案頁為準。

不同雲端平台可能有各自的區域供應、功能限制、折扣與價格。即使使用同一個模型，帳單、端點、模型 ID 與功能支援也未必相同。

選擇入口時，可以從以下條件評估：

若團隊已集中使用某個雲端平台，沿用既有帳務與權限架構通常較容易管理；若需要 Claude API 的特定參數，則要先確認合作平台是否支援。

refusal 會回傳 HTTP 200：fallback 需要明確設定

Fable 5 的安全分類器可能拒絕請求。Anthropic 在 2026 年 6 月 9 日的發布文中表示，早期資料顯示，超過 95% 的 Fable 工作階段沒有發生 fallback。這是發布初期的平均觀察值，不是服務水準保證，也不能直接套用到特定應用。

Messages API 拒絕請求時會回傳 HTTP 200，並將 stop_reason 設為 "refusal"，而非回傳 4xx 或 5xx。程式若只看 HTTP status code，可能把拒絕誤判成成功。處理回應時應檢查 stop_reason；若拒絕發生在串流中途，官方文件要求將部分輸出視為不完整並丟棄。

Claude API 的 fallback 不會在未設定時自動啟用。目前可使用 beta 版伺服器端 fallback，以 fallbacks: "default" 交由 Anthropic 依拒絕類別選擇建議模型，也可以列出最多三個備援模型。使用預設路由時，還要送出 server-side-fallback-2026-07-01 beta header；若某個拒絕類別沒有建議模型，API 仍會回傳 refusal。其他平台可用 Anthropic SDK middleware 或自行重試。伺服器端 fallback 不支援 Message Batches，也不適用於 Amazon Bedrock、Google Cloud 或 Microsoft Foundry。官方文件範例使用 Claude Opus 4.8，但預設路由可能調整，應以實際回應的 model 欄位為準。

若 Fable 5 在產生任何輸出前拒絕請求，該次拒絕不計費，但仍會計入 rate limits；若在串流途中拒絕，輸入與已串流輸出會按正常費率收費。備援模型的輸出按其費率計價。自行重試時，可依官方 fallback credit 機制避免重複支付部分 prompt-cache 成本。

目前文件列出的拒絕類別包括 cyber、bio、frontier_llm、reasoning_extraction 與 general_harms。無害的資安、生命科學與機器學習工作也可能觸發分類器，因此一般商業用途也應準備拒絕處理流程。

回應分支可以依序檢查：

例如，程式碼助理審查身分驗證流程時，正常的資安工作也可能觸發 cyber 分類器。攔到 stop_reason: "refusal" 後，應把結果標記為不可用並記錄拒絕類別，再依產品設定顯示說明或使用合規的 fallback。若回應來自備援模型，介面與評測紀錄都應標明實際模型。這套邏輯可集中在路由層，避免各呼叫點處理不一致。

分類器的判斷邊界可能調整，不應把目前的拒絕類別當成永久規則。可在符合隱私與資料保存政策的前提下，記錄 refusal 類別、必要的請求特徵與處理方式，觀察哪些工作流程較常被攔。除非有明確需要與權限，不要把完整 prompt 寫入一般應用程式日誌。

分類器 fallback 只處理安全分類器拒絕。Rate limit、overload 與伺服器錯誤會照常回傳；應用程式逾時也要另外處理，不能依賴這套 fallback。

兩項採用條件：資料保留與 always-on thinking

Fable 5 的資料保留與 adaptive thinking 設定會直接影響合規與成本。

Fable 5 與 Mythos 5 都是 Covered Models。官方資料保留說明規定提示與輸出保留 30 天，因此不能在 zero data retention（ZDR）設定下使用。資料會在 30 天後自動刪除；遭自動安全系統標記或依法須保存時，可能保留更久。

保留資料由誰處理會隨入口而異。Claude API 與 Claude Platform on AWS 由 Anthropic 處理；Amazon Bedrock 的保留資料留在 AWS，Google Cloud Agent Platform 的保留資料留在 GCP。Microsoft Foundry 則按 Azure Subscription 設定 retention；官方說明沒有在同一頁明列其保留資料的實體位置，確切條件以 Microsoft 官方文件與合約為準。

若合約要求 ZDR，Fable 5 就不符合該條件。金融、醫療或法律專案能否採用，仍要依資料類型、合約與適用規範評估，不能只按產業別判斷。

另一項限制是 adaptive thinking 永遠開啟。Fable 5 不支援 thinking: {"type": "disabled"}，但可以用 effort 調整模型投入的思考與整體輸出量。原始 chain-of-thought 不會回傳；thinking.display: "summarized" 會回傳可閱讀的思考摘要，預設的 "omitted" 則回傳空的 thinking 欄位。

thinking tokens 會按輸出 tokens 計費，即使選擇不顯示思考內容也一樣。需要控制成本時，應調整 effort 並觀察 usage.output_tokens_details.thinking_tokens，不能只看畫面上顯示的答案長度。

官方 effort 文件列出 low、medium、high、xhigh 與 max 等級；各模型支援範圍不同。Fable 5 支援這五個等級，預設為 high。較高設定通常會增加思考與整體輸出，可能改善困難任務表現，也通常會增加延遲與費用。effort 是行為控制訊號，不是固定的 token 預算。

導入前可一起檢查：

合規評估可分成兩層。先確認專案能否接受 30 天保留，以及遭安全系統標記或依法保存時可能延長；若合約或適用規範要求 ZDR，Fable 5 就不適用。可接受保留後，再比對資料由誰處理、留在哪個環境，以及是否符合資料主權與跨境傳輸要求。

若其中一項無法接受，可先評估 Opus 5 或 Sonnet 5；最終仍要確認替代模型本身的功能、保留政策與平台條件。

從下線到重新部署：19 天內發生了什麼

Fable 5 與 Mythos 5 在 2026 年 6 月 9 日發布，6 月 12 日暫停供應。7 月 1 日，Fable 5 先在 Claude Platform、Claude.ai、Claude Code 與 Claude Cowork 恢復全球供應，距暫停日相隔 19 天；AWS、Google Cloud 與 Microsoft Foundry 當時仍在陸續恢復。Mythos 5 則先恢復給一批經美國政府核准的美國組織，並未全面開放。

Anthropic 的重新部署聲明指出，美國政府在 6 月 12 日對兩個模型實施出口管制，要求限制外國人士使用。Anthropic 當時無法即時驗證國籍，因此全面暫停服務。相關出口管制於 6 月 30 日解除，Fable 5 的第一方服務在 7 月 1 日恢復全球供應。依目前的 models overview，Claude API、Amazon Bedrock、Claude Platform on AWS、Google Cloud 與 Microsoft Foundry 都已提供 Fable 5；各平台的實際區域與帳戶可用性仍以官方頁面為準。

分類器 fallback 與服務中斷備援是兩套機制。前者處理正常 API 回應中的 refusal；後者處理逾時、服務錯誤或模型無法使用。若系統要求高可用性，兩條路徑都要設計，備援模型也應先通過相同任務的測試。

這次中斷顯示，單一模型會集中供應風險。若服務有可用性要求，可讓 prompt 與工具定義維持跨模型可攜，替關鍵任務準備至少一個測試過的備援模型，並把切換邏輯集中在路由層。這樣模型不可用時，系統才有明確的降級路徑。

決策矩陣：什麼任務該上 Fable 5

Fable 5 是旗艦，但每個生產工作負載仍要一起評估任務難度、品質、延遲、合規與成本。

如果較低價模型在自家評測中遇到明確瓶頸，而 Fable 5 帶來的完成率或品質改善足以抵銷成本與延遲，再考慮採用。高頻短問答、單純分類、摘要與對延遲敏感的互動，可先測 Sonnet 5；複雜但未必需要最高能力的工作，可將 Opus 5 納入對照。這是選型建議，不是官方效果保證。

可依下列順序評估：

1. 先確認合規。若專案不能接受 30 天資料保留，或不能接受特定例外可能延長，Fable 5 就不符合條件。
2. 再看任務形狀。高頻短問答、單純分類與對延遲敏感的互動，優先測 Sonnet 5。
3. 複雜但未必需要最高能力的工作，將 Opus 5 納入中間選項。
4. 較低價模型出現會影響成果的瓶頸時，再測 Fable 5。
5. 以自家任務的完成率、成本與延遲做最後決定。

升級前的評測：用自家任務判斷，不看榜單

榜單可以用來篩選模型，採購與升級仍應依自家任務的評測結果。

評測流程要固定且可重複：

1. 準備涵蓋常見與困難情境的任務集，為每一題訂出可量測的成功條件。
2. 在相同 prompt、工具與評分標準下，分別測試 Sonnet 5、Opus 5 與 Fable 5。
3. 記錄完成率、修正次數、延遲與 token 成本，另行追蹤 thinking tokens。
4. 集中分析較低價模型失敗或卡住的任務，確認 Fable 5 是否能穩定改善結果。
5. 將改善帶來的效益與新增的費用、延遲及合規條件一起評估。

例如，團隊可以在大型程式碼遷移任務中比較三個模型處理跨檔案相依性的完成率，再把人工修正成本與 API 費用一起計算。這是評測方法示意，不代表任何模型在未實測前就會達到特定結果。

先建立可重複的評測流程，之後遇到新模型時就能沿用同一套任務與標準，不必只依發布文或單次示範判斷。

只挑旗艦擅長的題目，會高估整體效益。任務集應反映實際工作分布，包含簡單、中等與困難案例。評測要回答的是：Fable 5 能否穩定完成其他候選模型容易失敗的任務，以及這項差異是否值得增加成本。

另一個偏差是每題只跑一次。agent 任務可能因工具回應與執行路徑而產生差異，同一任務要重複測試，才能觀察穩定度。採購判斷應看完成率與人工修正成本，不宜只看單次最佳結果。

創意寫作誤解的由來，與適合使用的任務

官方資料能確認的是 Fable 與 Mythos 的命名語源，以及 Fable 5 的產品定位。至於「創意寫作模型」說法最早從何而來，目前查不到可靠的官方紀錄，不應將名稱或未具名的第三方評測當成確定成因。

Fable 5 能處理寫作任務。Anthropic 的 Transparency Hub將 creative tasks 列在可處理的工作中，但官方主打的能力仍是長程 agentic 工作、軟體工程、知識工作、視覺與科學研究。能處理創意寫作，不等於專為創意寫作設計。

網路上的能力數字也要區分來源。Anthropic 發布文中的基準、內部測試與客戶早期回饋，不等於獨立第三方已用公開方法重複驗證。引用時要保留測試者、任務與方法等背景。

依官方資料，Fable 5 的主要用途包括長時間自主執行、大型程式開發與遷移、複雜視覺理解，以及多階段知識工作。生命科學成果多以 Mythos 5 或 Mythos-class 的研究展示為主，不能直接改寫成一般 Fable 5 使用者都能重現的能力。

若寫作流程會產生大量輸出，Fable 5 的輸出費率與 thinking tokens 都要列入成本。可測試混合模型配置：把論點結構或複雜改寫交給 Fable 5，將標準化潤飾、格式轉換或摘要交給較低價模型。這是依計價結構提出的配置方式，品質與成本仍要實測。

怎麼判讀官方的能力宣稱

選模型時，也要判斷證據來源。Fable 5 發布時伴隨基準結果、內部實驗與客戶早期回饋，這些資料的測試者、方法與可重複性並不相同。

模型 ID、價格、context window、最大輸出與支援平台等規格，應以官方文件為主要來源。至於「比其他模型強多少」或「替企業節省多少時間」，即使出現在官方發布文，也要保留測試者、任務與評測方法等背景。

看到效益或基準數字時，先確認來源與方法，再判斷任務是否接近自己的使用情境。缺少對照組或方法說明的數字，可用來設計測試，但不宜當成採購保證。

常見問題

我已經在用 Claude Sonnet 5，什麼情況才值得升級到 Fable 5？

先在相同任務與評分標準下測試。若 Sonnet 5 在長程任務、大量脈絡或大型程式碼遷移上持續失敗，而 Fable 5 帶來的改善足以抵銷成本與延遲，再考慮升級。複雜工作也可把 Opus 5 納入對照。升級前還要確認專案能接受 30 天資料保留、特定例外可能延長，以及 always-on thinking。

Fable 5 的知識截止日到什麼時候？

官方 models overview 列出的 reliable knowledge cutoff 與 training data cutoff 都是 2026 年 1 月。模型仍可能答錯，處理近期資訊時也應搭配搜尋、資料庫或其他可追溯來源。

走 Amazon Bedrock 或 Google Cloud，計價跟快取機制一樣嗎？

不能假設完全相同。兩個平台有自己的區域供應、計價與合約條件。官方文件顯示，1 小時 prompt cache 可在 Amazon Bedrock 與 Google Cloud 使用；automatic caching 可在 Google Cloud 使用，但 Amazon Bedrock 不支援。導入前應查看各平台最新文件。

30 天資料保留對合規專案意味著什麼，能不能使用 ZDR？

Fable 5 與 Mythos 5 是 Covered Models，提示與輸出保留 30 天，不能在 ZDR 設定下使用；遭安全系統標記或依法須保存時，可能保留更久。Claude API 與 Claude Platform on AWS 的保留資料由 Anthropic 處理；Amazon Bedrock 與 Google Cloud Agent Platform 的資料留在相應的雲端供應商環境。專案能否採用，取決於資料、合約與適用規範。

結論與下一步

Claude Fable 5 是 Anthropic 能力最高、已廣泛發布的 Mythos-class 模型，定位在長程 agentic、coding、視覺與複雜知識工作。它能處理創意寫作，但官方沒有將它定位為寫作專用模型。

導入前先確認三件事：

1. 合規條件是否容許 30 天資料保留、特定例外可能延長，以及所選平台的 retention 設定與資料位置。
2. 成本估算是否納入快取寫入、快取命中、thinking tokens、fallback 與區域倍率。
3. 系統是否分別處理 stop_reason: "refusal" 與服務不可用，並記錄最後實際提供回應的模型。

完成這些檢查後，再用自己的任務評測 Fable 5、Opus 5 與 Sonnet 5，判斷增加的費用是否能換到足夠的品質或完成率改善。