Anthropic 於 9 月 22 日發布 Claude Opus 5.5。大約一週後，Reddit、X 和 GitHub 上開始出現貼文，稱這款模型比剛上線時明顯變差；另一批抱怨則說 Claude 訂閱額度比以前用得更快。本文整理使用者的說法、一個專門為此做公開追蹤的第三方測試測到了什麼，以及 Anthropic 說了什麼、沒說什麼。以下內容均於北京時間 10 月 21 日 10:40 左右核對。
使用者怎麼說
關於品質的抱怨集中在一次故障前後。Claude 狀態頁記錄，北京時間 9 月 29 日 22:21 起，claude.ai、Claude Code、Cowork 和 API 出現錯誤增多。幾小時後，9 月 30 日 08:57，Reddit 使用者 juaps 在 r/ClaudeAI 發文，標題是「Opus 5.5 feels way dumber after today's outage, anyone else noticing this?」。貼文說模型「forgets things, makes mistakes, invents details that weren't even in the documents I gave it」，感覺「like a quantized version or a completely different model」。這篇貼文獲得 400 多個讚，但版塊的自動摘要稱討論「pretty split down the middle」：附和的人很多，說用起來沒問題的人也差不多一樣多。r/ClaudeCode 也有一篇類似的貼文，標題是「Opus 5.5 is Quite Degraded after the Outage」。
X 上，Rajath Gowda（buildwithrajath）在 10 月 2 日 22:28 發文稱「Anthropic may have NERFED Opus 5.5 BIG TIME」，列舉了模型漏掉任務、跳過提交、「claiming work is done when it isn't」等回報，同時也寫了「way too early to say」。EnvolDev 重跑了一個生成圖景的「Eiffel Tower benchmark」，10 月 4 日發文說「it honestly feels like Opus 5.5 got little nerfed」，但同一篇貼文也說「one run doesn't prove a nerf」。重測結果並不一致。SKatalystAI 用 9 月 22 日做過的程式測試，在同一個凍結的儲存庫、同樣的提示詞和同樣的 Cursor 環境下重跑，兩次都是 9 題全對，這次更快、用的上下文更少，結論是「I can't reproduce the nerf」。
抱怨也出現在 GitHub 上 Claude Code 的 issue 裡。facitoo 於 10 月 5 日 14:29 開的 issue 寫道「the model quality has degraded back to level of opus 5」。該討論串中，TANOSHIT 貼出日誌，認為原因可能是 Claude Code 用戶端更新而不是模型本身：自動更新後每輪思考 token 的中位數下降，退回舊版本後「restores quality」。這只是一位使用者的測量，討論串裡沒有 Anthropic 的回覆。
額度方面的抱怨
另一類抱怨是額度。Reddit 使用者 chroner 在 9 月 25 日寫道，Max 5x 方案的用量下降「like 3 -5 times faster」，但同一討論串裡也有人說自己的用量漲得反而很慢。GitHub 上，Dougmayfair67 於 10 月 14 日 11:05 開了一個 issue，標題是「Opus 5.5 Usage Limits Exhausted Within 1-2 Days」，稱自己沒改變用法，額度卻「draining between 30-50% per day」。同一討論串裡，leolim031 根據本機 Claude Code 日誌統計了 token 數，認為 5 小時工作階段計量「got much stricter around Oct 13, while the weekly meter didn't change」。這些都是使用者對自己帳號的測量。Anthropic 沒有確認也沒有否認計量方式有任何變化。
NerfBench 測的是什麼
NerfBench 是開發者社群 BridgeMind 旗下第三方基準 BridgeBench 的一項測試，與 Anthropic 無關。它的結果是一個參考指標，不是模型有沒有變的定論。
依 BridgeMind 公布的方法，每次測試給模型出 8 類、50 道程式和推理題，每題 3 次，共 150 次評分。作答是單次回覆，不用工具也不給程式碼儲存庫。主要指標「power」把正確率與輸出 token 數、花費合在一起，以該模型上線當天的測試為 100%。BridgeMind 把 90% 到 110% 視為正常波動，只有連續兩次在同一側超出這個區間，才算有變化。它的局限也很明顯：題目、測試和答案都不公開，BridgeMind 表示不會開源，外界無法核實是哪些題拉動了分數；token 和花費計入 power，所以答得一樣好但寫得更長，分數也會下降；目前只追蹤 4 個模型，且透過 API 測試，不是多數抱怨者使用的 Claude 應用程式或 Claude Code 訂閱，不過 BridgeMind 表示正在加入訂閱管道的測試。
Opus 5.5 的結果如下。9 月 22 日上線當天的測試是 100% 基準。9 月 27 日 99.2%，10 月 1 日 103.8%，10 月 2 日 94.2%。BridgeMind 在北京時間當天 21:29 發文說「94.2% is still inside normal variance, so we can't call it a nerf yet」。10 月 4 日為 96.5%；10 月 9 日 BridgeBench 回報 95.7%，並稱 Opus 5.5 是「the only model below its launch score」。最近一次每週結果於 10 月 16 日 21:26 發布，Opus 5.5 為 105.8%，BridgeBench 寫的是「No nerfs detected」。到目前為止，Opus 5.5 每次結果都在 90% 到 110% 之內。BridgeMind 10 月 15 日新加的一項前端測試顯示，同一任務上 Opus 5.5 比上線時多用了 26% 的 token，但 BridgeMind 認為結果「way better」。
Anthropic 回應了嗎
沒有公開回應。截至北京時間 10 月 21 日 10:40 左右，我們在 Anthropic 新聞頁、Claude 狀態頁，以及 X 上的 AnthropicAI、Claude、ClaudeDevs 帳號中，都沒有找到針對 Opus 5.5 變差或額度消耗變快的說法；上面兩個 GitHub issue 裡也沒有 Anthropic 員工回覆。狀態頁確實列出了這段期間的故障，包括 9 月 29 日那次，以及北京時間 10 月 6 日 20:24 的「Elevated errors for Claude Opus 5.5」，但這些記錄的是錯誤，不是模型品質變化。Anthropic 公開說過的是發布時的內容：Opus 5.5 的服務成本低於 Opus 5，並在發布時提高了 Pro、Max、Team 和按席位計費的 Enterprise 方案的 5 小時額度。
怎麼查自己的額度消耗
如果覺得額度掉得快，先看 Anthropic 自己的工具。在 claude.ai 和 Claude Desktop 的「設定 > 用量」（Settings > Usage）裡，可以看到 5 小時工作階段額度和每週額度的進度條，以及各自的重設時間。額度是共用的，所以 Claude Code 的消耗也算在裡面。
在 Claude Code 裡，/usage 指令會顯示同樣的方案用量條。Pro、Max、Team 和 Enterprise 方案還會顯示一個明細，把近期用量按 skill、子代理、外掛和各個 MCP 伺服器分攤，並對占近期用量 10% 以上的行為（例如長上下文、快取未命中）提出改善建議。按 d 或 w 可在最近 24 小時和最近 7 天之間切換。Anthropic 說明，這些數字是根據本機的本地工作階段紀錄算出的近似值，不包括 claude.ai 和其他裝置上的用量。/usage 頂部的 Session 區塊顯示 token 數，以及一行「Prompt cache (main)」，列出快取未命中次數。這一行值得看：Anthropic 文件說，間隔超過快取有效期後的第一則訊息會重新處理全部上下文。該區塊裡的金額是給 API 使用者看的，Anthropic 說它與訂閱計費無關。如果開啟了用量額度（usage credits），/usage 還會顯示當月的額度支出。
Anthropic 的成本指南列出了長工作階段裡用量上升的常見原因，包括長上下文、快取未命中、排程任務、子代理和壓縮上下文等。具體帳號的計費問題，Anthropic 建議訂閱使用者透過 claude.ai 選單裡的 Get help 聯絡支援。
各方案 5 小時和每週額度怎麼算，可以看我們的解讀「Anthropic Still Describes Claude Code Limits in Multiples, So Here's What Each Plan Gets」。