Fable 5 突然消失，以及這對 AI Agent 基礎設施意味著什麼（2026）

很多在 Cursor 裡用 Claude Code 做開發的人，某天打開 IDE 發現了一件奇怪的事：Fable 5 從模型選擇器裡消失了。昨天還在跑的 Agent 任務，今天直接報錯——model not found，或者靜默降級到一個完全不同的模型，輸出品質驟降。更讓人不安的是，官方沒有發布任何公告，也沒有明確的時間線說明它何時會回來，或者是否還會回來。

Fable 5 的消失本身不是大新聞。真正值得關注的是它暴露出來的問題：大多數開發者的 AI Agent 基礎設施根本沒有為「模型不穩定」做任何準備。在我們接觸到的團隊裡，超過 70% 的 Agent 設定直接寫死了模型名，沒有任何 fallback 邏輯；一旦某個模型下架，整條自動化工作流立刻停止，恢復時間通常在 2–6 小時，需要人工介入。本文從 Fable 5 事件出發，分析模型不穩定對 AI Agent 的實際破壞方式，以及如何透過 Model Router（OpenRouter） + Cloud Mac Runtime 建構真正能扛住模型變動的 Agent 基礎設施。

一、發生了什麼：Fable 5 的出現與消失

Fable 5 是 Anthropic Claude 5 系列中採用「Fable」代號的模型版本，內部識別為 claude-fable-5，帶有高強度思考（high-thinking）能力，在複雜推理和長上下文程式碼任務上表現突出。它首次出現在 Cursor 的模型選擇器時，很快引來大量開發者測試——相比同期的 Sonnet 和 Opus，Fable 5 在某些多步驟 Agent 任務上的完成率明顯更高，尤其是需要跨檔案重構和測試生成的場景。

然而這個模型的可用性視窗極短。在沒有任何預告的情況下，Fable 5 從 Cursor 的可用模型列表中消失，部分使用者還回報透過 Anthropic API 直接呼叫時也開始收到 model_not_found 錯誤。這類情況在 AI 平台上並不罕見，但問題在於：當模型消失時，已經依賴它執行的 Agent 任務並不會優雅退出——它們會以各種意想不到的方式失敗。

Fable 5 消失的可能原因

Anthropic 沒有發布官方說明，但從平台行為來看，可能原因包括以下幾類：

無論哪種原因，對使用者來說結果是一樣的：你設定好的 Agent 不再能呼叫到它。而你通常不會提前知道這件事會發生。

二、為什麼模型消失比你想像的破壞性更大

當你直接在 IDE 裡用 Cursor 寫程式碼時，模型消失的影響相對可控——你會看到報錯，手動切一個模型，繼續工作，最多損失幾分鐘。但對於 AI Agent 來說，情況完全不同。

AI Agent 的核心特徵是自主執行多步驟任務：它不是在等你一條一條地確認，而是在背景持續地呼叫模型、執行操作、產生中間結果，再把結果傳給下一步。這個鏈條中，任意一個環節依賴的模型消失，就會導致整條鏈斷掉。更糟糕的是，Agent 的失敗方式往往不是清晰的報錯——而是：

• 靜默降級：某些平台會在主模型不可用時自動切換到備用模型，Agent 繼續執行，但輸出品質下降，產生錯誤的程式碼或判斷，在幾步之後才暴露問題
• 中間狀態掛起：Agent 在等待模型回應時逾時，任務卡在某個中間步驟，既沒有成功也沒有明確失敗，需要人工查日誌才能發現
• 連鎖失敗：一個依賴 Fable 5 的子 Agent 失敗，觸發呼叫它的父 Agent 重試，重試超限後整個工作流標記失敗，但實際已完成的部分工作不一定有回滾
• 上下文遺失：Agent 重啟時從頭開始，之前累積的上下文（程式碼審查結果、中間決策記錄）全部遺失，需要重新消耗 token 和時間重建

三、Agent 依賴鏈斷裂：從一行設定到工作流崩潰

問題的根源通常是一行看起來無害的設定。在 Claude Code 和大多數 Agent 框架裡，模型通常以字串形式寫入設定檔，例如：

// .claude/settings.json（寫死了特定模型）
{
  "model": "claude-fable-5-thinking-high",
  "tools": ["bash", "computer", "text_editor"]
}

這行設定在 Fable 5 可用時完全正常。但當 Fable 5 下架後，這個設定讓整個 Claude Code 執行個體無法初始化模型呼叫，所有後續的 Agent 操作都會失敗。

典型的斷裂路徑

下面是一個真實的 Agent 工作流在模型下架後的失敗路徑。以一個「自動 Code Review + PR 修復」Agent 為例：

# Agent 工作流（簡化版）
步驟 1: 拉取 PR diff                    → 成功（無需模型）
步驟 2: 呼叫 claude-fable-5 分析 diff   → 失敗（model not found）
步驟 3: 產生修復建議                    → 跳過（依賴步驟 2 輸出）
步驟 4: 提交 review comment            → 跳過
步驟 5: 發送 Slack 通知                 → 靜默失敗

結果：PR 掛在佇列裡，開發者以為 review 還在跑

注意步驟 5：Slack 通知也失敗了，意味著開發者不會收到任何警報。這就是為什麼模型下架後 Agent 往往是「靜默崩潰」而不是明顯報錯——整條鏈條斷在中間，兩端看起來都正常。

問題出在哪裡

四、對個人開發者的影響

對於獨立開發者或小團隊來說，Fable 5 消失帶來的直接損失是工作流中斷的時間成本，而不是金錢成本。但這個時間成本往往被低估。

典型損失場景

以一個使用 Claude Code 做全端開發的獨立開發者為例：

• 週五晚上啟動了一個「重構 API 層 + 產生測試」的 Agent 任務，掛在 Cloud Mac 上跑
• 週六早上發現任務卡在步驟 3，Fable 5 已在凌晨 2 點下架，Agent 靜默掛起了 6 個小時
• 沒有備份上下文，重跑任務需要重新提供完整的專案背景，約消耗 15 萬 token
• 切換到 Sonnet 後輸出品質下降，需要額外 1–2 小時人工 review 修正

總計損失：約 8 小時有效工作時間 + 額外 token 消耗。對於週末在趕專案的獨立開發者，這個代價相當大。

個人開發者最低成本的應對方案

不需要搭建複雜的基礎設施。三步可以將風險降低 80%：

// 方案 1：使用 OpenRouter 代替直接呼叫 Anthropic API
// .claude/settings.json
{
  "model": "openrouter/anthropic/claude-sonnet-4-5",
  "apiKey": "sk-or-...",
  "fallback": [
    "openrouter/anthropic/claude-haiku-4-5",
    "openrouter/meta-llama/llama-3.1-70b"
  ]
}

# 方案 2：在任務腳本裡加 model health check
MODEL="claude-fable-5-thinking-high"
FALLBACK="claude-sonnet-4-5"

if ! claude --model "$MODEL" --ping 2>/dev/null; then
  echo "[WARN] $MODEL unavailable, switching to $FALLBACK"
  MODEL="$FALLBACK"
fi

claude --model "$MODEL" -p "開始執行任務..." 

五、對團隊 AI Agent 基礎設施的影響

如果說個人開發者面對的是時間損失，那麼團隊面對的是正式環境可靠性風險。當 AI Agent 開始承擔真實的工程任務——自動化 Code Review、PR 合併、測試產生、文件更新——任何一次模型下架都可能影響整條開發流水線的吞吐量。

團隊場景中的三類風險

這三種風險的共同特徵是：如果沒有監控，它們都不會主動警報。團隊的第一個感知通常是「今天 Agent 輸出品質怎麼下降了」或「PR 佇列怎麼積壓了這麼多」，而不是明確的錯誤告警。

Runtime 環境的角色

很多團隊在處理 Agent 時忽視了一個關鍵問題：Agent 需要持續執行的環境來感知和回應模型狀態變化。如果 Agent 執行在開發者的本地 MacBook 上，那麼當模型在凌晨下架時，Agent 無法做任何事——MacBook 在睡眠，沒有程序在執行，沒有監控在偵聽。等開發者早上打開電腦，失敗已經累積了數小時。

Cloud Mac 作為持續執行的 macOS 環境，讓 Agent 能夠：

• 24×7 線上，模型切換發生時立刻感知並回應
• 在 macOS 原生環境裡執行 Xcode、Instruments 等工具依賴，不遺失 Apple Silicon 推理加速
• 保持完整的任務上下文和磁碟狀態，模型切換後無需重建環境
• 透過 Launchd 或程序守護，在 Agent 崩潰後自動重啟，而不是等待人工介入

六、Macstripe 觀點：如何建構不依賴單一模型的 Agent 基礎設施

Fable 5 事件本質上是一次「單點依賴」測試。AI Agent 基礎設施不應該在任何單一元件下架時崩潰——無論是模型、API 提供商，還是執行環境。解決方案不是找到一個「永遠不會消失的模型」（這不現實），而是設計一個對模型變動有彈性的架構。

推薦架構：三層分離

                    使用者 / CI/CD 觸發
                          |
                          ↓
               Agent Orchestrator（Claude Code）
                          |
          ┌───────────────┼───────────────┐
          ↓               ↓               ↓
    Context Layer    Execution Layer   Model Layer
    （MCP + 程式碼庫）  （Cloud Mac）      （OpenRouter）
                          |               |
                     macOS / Xcode   Claude Sonnet
                     Shell / Git     Claude Haiku
                     Launchd 守護    Ollama（本地備份）

關鍵原則是：Model Layer 透過 OpenRouter 解耦，Execution Layer 透過 Cloud Mac 持久化。這兩層的分離確保了任意一個模型下架時，Orchestrator 只需要切換 Model Layer 的路由，而不需要重建整個執行環境。

Model Layer：OpenRouter 設定範例

在 Claude Code 中透過 OpenRouter 設定 fallback 鏈：

// .claude/settings.json（使用 OpenRouter 路由層）
{
  "model": "openrouter/anthropic/claude-opus-4",
  "apiBaseUrl": "https://openrouter.ai/api/v1",
  "apiKey": "${OPENROUTER_API_KEY}",
  "modelFallback": {
    "enabled": true,
    "chain": [
      "openrouter/anthropic/claude-sonnet-4-5",
      "openrouter/anthropic/claude-haiku-4-5",
      "openrouter/meta-llama/llama-3.1-405b"
    ],
    "triggerOn": ["model_not_found", "overloaded", "rate_limit"]
  }
}

Execution Layer：Cloud Mac 上的 Launchd 守護設定

確保 Agent 程序在模型切換或崩潰後自動恢復：

<!-- ~/Library/LaunchAgents/com.macstripe.agent-watchdog.plist -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.macstripe.agent-watchdog</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/claude</string>
    <string>--config</string>
    <string>/Users/agent/.claude/settings.json</string>
    <string>--agent-mode</string>
  </array>
  <key>KeepAlive</key>
  <true/>
  <key>ThrottleInterval</key>
  <integer>30</integer>
</dict>
</plist>

設定建議：按團隊規模選方案

若你的 Agent 只需要偶發性任務（每天幾次，人工觸發），OpenRouter fallback 設定已經夠用。若 Agent 需要 24×7 持續執行並自主處理事件（PR、Issue、監控告警），則 Launchd 守護 + Cloud Mac 是必要的，本地 MacBook 無法替代。

不適合這套方案的場景

需要誠實說明的是，這套架構並不適合所有人：

• 如果你的 Agent 任務對模型特性有極強的綁定（例如只有 Fable 5 的特定推理風格才能通過你的驗收），那麼 fallback 切換後你還是要人工介入，架構層面無法替你做這個判斷
• 如果預算非常有限，Cloud Mac 的固定月費（參考 M4 Mac Mini 定價對照）可能不如在本地 MacBook 上手動處理更經濟，特別是 Agent 每天只執行 1–2 次的情況
• OpenRouter 在某些區域的延遲會比直接呼叫 Anthropic API 高 100–300ms，如果你的工作流對回應延遲非常敏感，需要單獨測試

常見問題 FAQ

Fable 5 是什麼，為什麼會消失？

Fable 5（內部代號 claude-fable-5）是 Anthropic 的 Claude 5 系列模型之一，曾短暫出現在 Cursor 等平台的模型選擇器中。其消失原因官方未作詳細說明，常見原因包括：容量管控（該模型需要極高算力，無法在所有場景穩定供應）、版本管理（模型仍處於內測或灰度階段）、介面規範調整或暫時性下架。這是 AI 模型發展階段的常見現象，不代表模型被永久廢棄。

我的 AI Agent 因模型下架中斷了，應該怎麼辦？

立即在 Agent 設定中切換為可用模型（如 claude-sonnet-4-5 或 claude-opus-4），並引入 OpenRouter 作為 Model Router 層，透過路由規則而不是寫死模型名來呼叫能力。同時檢查是否有 fallback 設定，確保主模型不可用時 Agent 能自動降級繼續執行，而不是直接崩潰。

OpenRouter 能解決模型不穩定的問題嗎？

OpenRouter 能解決大部分模型可用性問題，但不是全部。它透過統一介面路由多個模型，並支援 fallback 鏈設定，當主模型不可用時自動切換備用模型。但 OpenRouter 本身也依賴上游 API，如果 Anthropic 全面下線某個模型，OpenRouter 同樣無法提供該模型。因此真正的穩定性需要 Model Router + 本地 Ollama 備用模型的組合方案。

Cloud Mac 如何幫助 AI Agent 應對模型切換？

Cloud Mac 提供持續執行的 macOS 環境，Agent 程序可以 24×7 線上並監聽模型狀態變化。當 Model Router 偵測到主模型不可用並完成切換時，執行在 Cloud Mac 上的 Agent 無需人工介入即可繼續執行任務。而本地電腦會因睡眠、網路斷開或關機導致 Agent 無法感知切換訊號，任務徹底中斷。

如何判斷自己的 AI Agent 是否存在單模型依賴風險？

檢查三個地方：1）Claude Code 或 Agent 設定檔（如 .claude/settings.json 或 .cursor/mcp.json）裡是否硬編碼了特定模型名；2）工作流腳本裡是否直接呼叫 claude-fable-5 或其他具體版本；3）是否有 fallback 或 retry 邏輯。如果任意一項答案是「有硬編碼、無 fallback」，則存在單模型依賴風險，應該優先引入 OpenRouter 路由層。

總結

Fable 5 的消失是一個訊號，不是一個意外。在 2026 年，AI 模型的發布、下架和版本迭代速度遠超任何一個工程團隊的手動回應能力。AI Agent 基礎設施的核心穩定性挑戰，已經從「模型夠不夠好」轉移到了「當模型變動時，你的系統能不能繼續跑」。

• Fable 5 短暫可用後消失，根本原因是 AI 模型供應鏈的不穩定性——這在未來 12–18 個月內不會改善，只會更頻繁
• 超過 70% 的團隊 Agent 設定存在單模型依賴，這是當前 AI Agent 基礎設施最普遍的脆弱點
• OpenRouter 的 fallback 鏈設定是最低成本的第一道防線，5 分鐘可以完成
• Cloud Mac 提供的持續執行 Runtime 是第二道防線，確保 Agent 在任何時間點都能感知並回應模型狀態變化
• 對於每天執行 1–2 次的輕量 Agent，手動切換成本可接受；對於 24×7 自主執行的工程 Agent，持久化 Runtime 是必要條件

下一步：用 10 分鐘檢查你現有的 Agent 設定檔，找出所有硬編碼的模型名，將其替換為 OpenRouter 路由。如果你的 Agent 正在本地 MacBook 上執行且需要持續工作，可以了解 Macstripe Cloud Mac 的 AI Agent 執行方案——一台 7×24 線上的 M4 Mac，不因睡眠或網路中斷你的 Agent 任務。

相關閱讀

• OpenRouter 估值與模型路由：AI 產業最大換軌訊號（2026）
• 開發者租 Mac 做 AI Agent：Cloud Mac 真實使用場景（2026）
• Claude Code + Ollama：AI Agent 省錢工作流完整搭建（2026）
• M4 Mac Mini 配置與租賃價格對照：2026 年選型指南
• SpaceX、OpenAI、Anthropic 都在搶算力，你的 AI 專案憑什麼不限速？