Claude Fable 5 從 6 月 9 日發表到現在，從發表到現在經歷了不少波折。先是上線三天就被美國政府禁用，接著在 7 月 1 日復活後，「什麼時候要開始收費」這件事又被反覆延期了三次，最後在 7 月 20 日才正式定案。
除了計費方案的混亂，開發者在實際使用中還會碰到兩個問題：安全分類器把正常請求誤判並退回 Opus 4.8，以及長對話中的 compact 壓縮導致上下文遺失。這篇把這些事情整理在一起，從時間線、降級判斷、到 compact 問題的處理建議，一次講完。
Fable 5 的發表細節與定價可以看之前寫的 Fable 5 發表整理，下架始末在 下架事件，復活後的安全機制與政府合作框架則在 Fable 5 復活 那篇。
完整時間線
從發表到計費方案定案，Fable 5 的存取權變動了至少七次。
| 日期 | 事件 |
|---|---|
| 6 月 9 日 | Fable 5 與 Mythos 5 正式發表，Pro、Max、Team、Enterprise 訂閱用戶可免費使用 |
| 6 月 12 日 | 美國商務部發出出口管制令，Anthropic 全面停用 Fable 5 與 Mythos 5 |
| 6 月 30 日 | 商務部解除出口管制 |
| 7 月 1 日 | Fable 5 全球重新上線，附帶改良版安全分類器。訂閱內免費使用延續至 7 月 7 日，Fable 5 用量佔每週額度上限的 50% |
| 7 月 7 日 | 原定截止日。當天深夜宣布延至 7 月 12 日 |
| 7 月 13 日 | 7 月 12 日截止後數小時，再度宣布延至 7 月 19 日 |
| 7 月 17 日 | 系統異常：Fable 5 突然要求 usage credits，status.claude.com 確認為非計畫中的故障，約一小時內修復 |
| 7 月 18 日 | Anthropic 公布最終方案 |
| 7 月 20 日 | 新方案正式生效：Max 與 Team Premium 永久保留 Fable 5，Pro 與 Team Standard 改為 usage credits |
三次延期都是透過 @claudeai 的 X 帳號宣布，沒有正式的部落格文章。7 月 13 日第二次延期的貼文在幾小時內突破一千萬次瀏覽，可以看出社群對這件事的關注程度。
目前的使用方案
7 月 20 日之後，Fable 5 的存取方式依方案而異：
| 方案 | Fable 5 存取方式 |
|---|---|
| Max | 訂閱內包含，用量佔每週額度上限的 50%。超過後需使用 usage credits |
| Team Premium 席位 | 同 Max |
| Pro | 僅限 usage credits（附贈一次性 $100 credit） |
| Team Standard 席位 | 同 Pro |
| Enterprise Premium 席位 | 同 Max |
| Enterprise Standard 席位 | 需啟用 usage credits |
| API | 按 token 計費：input $10 / output $50 每 1M tokens |
50% 的意思是：假設 Max 方案每週有 200 個使用額度，其中最多 100 個可以用在 Fable 5 上。Fable 5 消耗額度的速度比其他模型快（因為 thinking 永遠開啟，token 用量更高），所以實際可用的對話數會比用 Opus 4.8 或 Sonnet 5 時少。
對 Pro 用戶來說，$100 的一次性 credit 聽起來不少，但以 output $50 / 1M tokens 的價格，中等規模的程式碼遷移任務（生成約 200 萬 output tokens）就能把 credit 用完。考慮要不要升級 Max 時，先評估自己的 Fable 5 用量再決定。
安全分類器與 Opus 降級
Fable 5 復活後加裝的安全分類器是目前使用上常遇到的問題。分類器會掃描送進模型的所有內容（包含 system prompt、對話歷史、上傳的檔案、搜尋結果），觸發時請求會被退回 Opus 4.8 處理。
分類器主要針對四類內容：
- 攻擊性網路安全：exploit 開發、惡意軟體、攻擊工具相關
- 生物與生命科學：實驗方法、分子機制相關
- 推理萃取（reasoning extraction）：試圖取得模型的內部推理過程
- 前沿 LLM 開發：分散式訓練基礎設施等
Anthropic 也指出，這套分類器的 safety margin 設得比之前的版本都大。好處是針對引發出口管制的那個特定 jailbreak 技術，擋掉了超過 99% 的案例，代價是正常的程式碼也會被誤判。根據 Anthropic 的數據，不到 5% 的 Fable 5 session 會觸發分類器。但從開發者社群回報的案例來看，以下這些明顯無害的工作也曾被標記：
- Rust syscall 的 PR review
- AWS Bedrock 彈性設計的架構討論
- Django 專案中包含 AES-256-GCM 加密的程式碼
- macOS 應用程式的螢幕與麥克風錄製功能
- 基礎設施管理與 PDF 處理任務
像 security、vulnerable、unsafe、hook、kill、failover、circuit breaker 這些在日常開發中很常見的詞，都可能觸發分類器。
如何判斷請求是否被退回 Opus
判斷方式取決於使用的介面。
claude.ai 網頁版
網頁版的處理比較直接：被分類器攔截時，畫面上會顯示通知橫幅，回應也會標註實際使用的模型名稱。切換後 model picker 會停留在 Opus 4.8，後續對話會繼續用 Opus，除非手動切回 Fable 5。
API
API 端需要主動檢查幾個欄位。被分類器攔截的請求會回傳正常的 HTTP 200，但內容跟預期不同：
response.model 是比較直接的判斷依據。正常情況下會是 claude-fable-5，被退回時會變成 claude-opus-4-8。
stop_reason 會是 "refusal"（如果沒有設定自動 fallback 的話）。stop_details 物件會帶有分類類別（cyber、bio、reasoning_extraction、frontier_llm、或 null），但 stop_details 不一定有值，判斷時應該以 stop_reason 為主。
分類器可能在兩個時間點觸發：
- 輸出前觸發：
content陣列為空，不計費 - 輸出中途觸發：已產生的部分輸出會計費，但應該丟棄不要當作完整回應使用
建議在每次呼叫後都先檢查 stop_reason，再讀取 content：
response = client.messages.create(
model="claude-fable-5",
max_tokens=4096,
messages=[{"role": "user", "content": "..."}]
)
if response.stop_reason == "refusal":
# 被分類器攔截，content 可能為空或不完整
print(f"被退回：{response.stop_details}")
else:
# 正常回應
print(response.content[0].text)
# 確認實際回應的模型
print(f"實際模型：{response.model}")Claude Code
Claude Code 在模型切換時會顯示提示訊息。如果沒有注意到提示，以下幾個徵兆可以幫助判斷是否被降級了：
- 延遲明顯增加（可能是原本的 2–4 倍）
- 回應格式與預期不同（例如要求 JSON 卻回傳散文）
- 語氣變得過度保守（出現 “I want to make sure I understand…” 這類措辭）
- 回應長度大幅縮短
碰到這種情況，重啟 Claude Code session 可以清除「黏性降級」的狀態。在 session 內使用 /model 指令切回 Fable 5 不一定有效，開新 session 比較可靠。
被降級後的處理方式
對 claude.ai 使用者來說，處理方式比較單純：從 model picker 手動切回 Fable 5，或是編輯前一則訊息後重試。如果覺得是誤判，可以透過介面上的回饋功能回報。
API 開發者有幾種方式可以自動處理 fallback，依建議順序排列：
Server-side fallbacks（推薦）
在 Claude API 和 Claude Platform on AWS 上可用。只需要一次 API 呼叫，被分類器攔截時，API 會自動用 Opus 4.8 重新處理同一個請求：
response = client.beta.messages.create(
model="claude-fable-5",
max_tokens=4096,
betas=["server-side-fallback-2026-06-01"],
fallbacks=[{"model": "claude-opus-4-8"}],
messages=[{"role": "user", "content": "..."}]
)
# 檢查是否有 fallback 發生
fallback_ran = any(
entry.type == "fallback_message"
for entry in response.usage.iterations or []
)
if fallback_ran and response.stop_reason != "refusal":
print(f"由 {response.model} 回應（fallback）")
else:
print(f"由 {response.model} 回應")fallback 的計費會自動套用 credit 機制。退回 Opus 4.8 的那次呼叫，input tokens 按 cache-read 費率計算（約 $0.50 / 1M tokens），output tokens 按 Opus 4.8 標準費率 $25 / 1M tokens，比直接用 Fable 5 便宜許多。
Client-side middleware
在 Amazon Bedrock、Vertex AI、Microsoft Foundry 等不支援 server-side fallback 的平台上，可以用 SDK 內建的 middleware：
from anthropic import Anthropic, BetaFallbackState, BetaRefusalFallbackMiddleware
# 建立帶有 fallback middleware 的 client
client = Anthropic(
middleware=[
BetaRefusalFallbackMiddleware([{"model": "claude-opus-4-8"}])
]
)
# 每個對話建立一個 state 物件，用來追蹤 fallback 狀態
state = BetaFallbackState()
with state:
response = client.beta.messages.create(
model="claude-fable-5",
max_tokens=4096,
messages=messages
)BetaFallbackState 的作用是讓 fallback 的「黏性路由」能運作——一旦某個對話被退回 Opus，後續的請求會自動直接送到 Opus，避免每次都被分類器攔截一遍。每個對話要用獨立的 state 物件，不同對話之間不要共用。
手動重試搭配 fallback credit
如果不使用上面兩種機制，也可以自己偵測 stop_reason: "refusal" 後手動重試。搭配 fallback-credit-2026-06-01 beta header，被拒絕的請求會回傳一個 fallback_credit_token，在重試時帶上這個 token，原本已經 cache 的 prompt 部分會按 cache-read 費率計算，不用重新付 cache-write 的費用。
token 有效期限是 5 分鐘，重試時的請求內容必須跟原始請求完全一致（包含 thinking blocks，不需要也不應該自己移除）。
減少誤判的做法
雖然分類器的判斷不在使用者端的控制範圍內，但有幾個做法可以降低被誤判的機率：
- 在 system prompt 中明確標示意圖：例如「這是一個 systems engineering 專案」而非讓分類器自己判斷程式碼的性質
- 縮小 Claude Code session 的範圍：避免在同一個 session 中處理太多不同類型的任務
- 不同任務之間重啟 session：特別是在涉及安全相關詞彙的任務之後
- 合法的安全研究：可以申請 Anthropic 的 Cyber Verification Program
Compact 壓縮問題
Compaction 是 Anthropic 提供的對話壓縮功能（目前仍在 beta），會在對話接近 context window 上限時，自動將較早的對話內容摘要化以騰出空間。這個功能不是 Fable 5 獨有的，Opus 4.8、4.7、4.6、Sonnet 5 和 Sonnet 4.6 都支援，但 Fable 5 的使用者特別常碰到相關問題。
Compaction 的運作方式
API 層面，啟用 compaction 需要 beta header compact-2026-01-12，並在請求中設定 context_management：
response = client.beta.messages.create(
betas=["compact-2026-01-12"],
model="claude-fable-5",
max_tokens=4096,
messages=messages,
context_management={
"edits": [{
"type": "compact_20260112",
"trigger": {
"type": "input_tokens",
"value": 150000 # 預設值，最低 50000
}
}]
}
)觸發壓縮後，回應中會多出一個 compaction block，包含對話摘要。後續請求必須把這個 block 原封不動地傳回去，API 會自動忽略 compaction block 之前的所有內容。
壓縮本身是額外的一次 sampling 迭代，會產生費用。usage.iterations 裡會有一筆 type: "compaction" 的紀錄，top-level 的 usage 不包含壓縮的 token 數，計算總費用時需要把 iterations 裡所有項目加總。
開發者回報的問題
Claude Code 使用者反映的 compact 問題主要集中在幾個方面：
壓縮後上下文遺失：這是開發者較常回報的問題。壓縮會把長對話濃縮成一段摘要，但關鍵細節經常在過程中丟失，像是檔案命名慣例、先前的架構決策、微妙的限制條件都可能消失。有使用者回報 150K token 的架構討論被壓成一句「We discussed the codebase architecture and identified key patterns」。
CLAUDE.md 指令遺失：Claude Code 使用者特別在意的問題。壓縮後 CLAUDE.md 裡的專案指令可能被摘要掉，Claude 會回到預設行為，不再遵循之前的偏好設定。GitHub 上有多個相關的 bug report（#31409、#10006、#24460）。
過早觸發壓縮：有使用者發現在 context window 只用到 48% 時就觸發了壓縮，遠低於預期的閾值。可能的原因是壓縮過程本身使用的 summarization 模型有自己的 context 上限，當對話內容超過該模型能處理的範圍時就會失敗。
Auto-compact 行為不如預期：部分使用者反映即使設定關閉 auto-compact，系統仍然會在一定的 context 用量時強制壓縮。也有相反的情況，context 用滿 100% 時 auto-compact 沒有觸發，Claude Code 直接停止回應。
建議做法
- 主動壓縮比被動好：與其等到 context 接近上限才被自動壓縮，不如在 context 使用量到 60% 左右時，在 Claude Code 中用
/compact主動觸發，並附上自訂的壓縮指示告訴它哪些資訊要保留 - 重要決策寫入檔案：不要只依賴對話記憶來保存關鍵資訊。架構決策、命名慣例、先前的設計選擇，都應該寫進專案的文件中（例如
CLAUDE.md），這樣即使對話被壓縮，模型還是可以從檔案中讀取 - API 層面設定合理的 trigger 值：預設的 150,000 tokens 對大多數場景夠用，如果對話特別長或需要保留更多上下文，可以調高 trigger 值。最低可以設到 50,000
- 善用
pause_after_compaction：設為true時，壓縮後會暫停並回傳stop_reason: "compaction"，讓應用程式有機會在繼續對話前做額外處理（例如注入重要的上下文提醒） - 自訂壓縮指示：透過
instructions參數告訴壓縮模型要重點保留哪些資訊，例如"Focus on preserving code snippets, variable names, file paths, and technical decisions."