Working software on tap：Fable 5 的 Jevon's 悖論與自主性溢價

karpathy 那則貼文值得從頭讀完。Fable 5 跟底層模型 Mythos 共用同一個基礎，差異在加了安全機制。榜上是全面新高，但他說真正的跳躍在質感：他認為這跟 Claude 4.5 當時的幅度是同一量級，尤其在長時間、高難度解題場景裡最明顯。你可以丟更有野心的任務，模型「懂你的意圖」直接去跑，他第一次真的想放手不看代碼，但他同時補了一句：生產環境千萬別這樣做。

這個轉折說明了問題所在。他也直接承認，現在的 safeguard 觸發得太快，launch 版的參數調得偏緊。工程師這邊有個很具體的張力：一個能跑長任務的模型，如果自主執行途中一直被誤中斷，autonomous 的價值就折掉一大半。 能力天花板提高了，但可靠性底線還沒跟上。

然後是他提到的 Jevon's paradox。他觀察到，當可用軟體愈來愈容易產出，他自己對軟體的需求反而大幅成長。說明書、視覺化工具、客製化 dashboard、針對單一專案打造的一次性工具（他舉的例子是一個只適合你自己專案的 wandb 等價物）、擴充十倍的測試套件、搭配 HTML 報告的大型研究任務，需求沒有因為取得容易而飽和，反而開了更多。這個現象看起來符合 Jevon's 悖論的歷史模式：資源愈便宜，消耗量反而上升。

理解 Fable 5 要看定位，跑分只是旁注。 能力門檻一旦降低，誰的需求先爆炸、瓶頸移到哪，才是要問的問題。

工程師要判斷的問題比「要不要升級」更具體。長時間高難度任務的價值是真實的，這類場景原本就需要人緊盯，模型能穩定跑完代表的節省是真實的時間成本。但前提是 safeguard 誤觸發的機率得夠低，中斷帶來的 debug 與重跑成本可能抵消效率增益，這不是理論問題，是使用前要實測的數字。

至於自主性溢價值不值得付，目前看來得看兩件事：你的任務是否夠長夠複雜，以及 safeguard 調整速度能否跟上實際場景。karpathy 在貼文裡對這兩點都誠實留了未知數。Working software on tap 這個願景是真的，但 tap 現在還有個流量限制器，而且沒人確定什麼時候會調鬆。