深度讨论 Fable 5：模型收入分化，RSI，Tokenmaxxing 减速

Fable 5 是过去半年最受市场期待的模型，而在真正发布之后，它又迅速成为“最具争议”的模型。除了安全禁令外，它的使用体验反差也相当明显：在一些任务里，Fable 5 更像一位能独立推进任务的同事，而不再是只会执行的实习生；与此同时，也有一部分开发者却给出相反结论：在很多真实生产任务里，它并没有带来底层智能的质变。

评价的两极其实并不矛盾：只有在高价值任务上，模型的上限才看得见；在那些已经“够用”的任务上，最强模型和低价模型的差距会被迅速抹平。这个分歧本身才是最值得关注的信号：模型能力与收入的分化正在发生。

而 GLM 5.2 之所以引发讨论，本质上也是“Mythos 级别模型”竞争的另一面：Fable 5（以及传闻中即将发布的 GPT 5.6）赚取塔尖高价值任务的溢价，而能够迅速追平 SOTA 的国产模型有机会在吞掉塔基的海量 token。

这两股力量指向的是同一个结构。这个结构，也是我们认为下半年最值得下注的判断：前沿模型拿走 80% 的收入，开源与低价模型处理 80% 的 token。模型能力的分化，正在变成模型收入的分化；而真正决定高价模型收入厚度的，是金字塔顶端的高价值任务到底有多厚。

这篇文章是拾象 Best Ideas 社群关于 Fable 5 的一场主题讨论。我们也希望把它作为下半年观察模型的一个坐标，持续观察模型竞赛的趋势变化。

Insight 01

评价分化：高价值任务才看得到模型上限

一线开发者体感

1. 在 Fable 5 的用户使用感受中，有一个很有趣也十分值得重视的分化趋势：

•一方面，不少用户认为 Fable 5 已经接近 project owner 的角色：它能主动补充上下文、拆解任务、调用工具、推进流程并验证结果；

•与此同时，也有用户给到完全相反的结论，甚至认为 Fable 5 相比 Opus 4.7 / 4.8，智能上没有本质变化；

•最有趣的是，即便同是开发任务，Fable 在 SQL 语言任务的表现被认为很强，但在 Python 类任务里，则被用户评价“与 GPT-5.5 表现更接近”。

2. 这个分歧的本质其实是测试任务的不同。如果具体看两类反馈的实际测试任务，会发现在生活规划、文本格式、常规的 coding 等已经能被现有模型很好完成的任务上，很难直接、直观地看出 Fable 5 与 GPT-5.5、Opus 4.8、Sonnet 级模型的差异，但如果涉及到复杂工程、反编译、auto research、安全攻防、大型系统改造等高价值任务，反而更加容易展示 Fable 在主动推进、反思纠错、造工具和调度 sub-agents 的能力。

3.有 AI Researcher 提到，Mythos 在部分开放研究方向选择上已经接近人类研究者判断。在从 Claude 切回 Gemini 3.5 继续推进同一类研究工作时，能明显感觉到切换模型带来的任务推进质量下降：原本用 Claude 已经推进到约 70% 的研究进度，换回 Gemini 后可能因为 hallucination、instruction following 不稳定、无法持续沿着既定实验路径推进等问题，被迫返工或回退，体感进度可能掉到约 50%。

4. 用户对 Fable 5 的评价分化，也和在使用时实际运行的模型状态有关。

有用户把 Fable 5 调到 low effort 后，使用体感更像一个“稳定版 Opus 4.6”，质量仍可用但 token 消耗可能明显下降；也有人观察到，Fable 5 在 sub-agent 任务里会把简单步骤交给 Haiku 等更便宜的模型；再加上部分任务会触发 safety fallback，实际承接任务的也可能变成 Opus 4.8 或其他模型。因此不同用户看到的 Fable 5，可能对应不同 effort、不同 routing 和不同成本结构，最终评价自然不会完全一致。

5. 不过，开发者用户对于 Fable 的模型体验一定程度上也受到了 Fable 的安全分类器和访问权限影响，因此，对于绝大多数开发者而言，他们未必能接触到 Fable 5 的完整能力。比如目前网络安全、生物化学、模型蒸馏等方向更容易被拒答、限制，或路由至 Claude Opus 4.8。

6. 一个普遍的猜想是，AI for Science、网络安全等高敏感能力未来可能不会完全通过公众模型开放，而是以授权、白名单或专用模型方式提供。

7. 资本市场对 Fable 5 的分歧，也可以放回这套用户体验框架里看。从乐观角度看，Fable 5 让高价值任务、超级工程和自动化研究更接近可用，说明模型能力仍在加速；从谨慎角度看，Fable 5 还没有体现足够强的 TAM 扩张 driver，使用门槛高，高价值任务的价值量仍没有结论。

Benchmark 表现

8. Fable 5 在红杉中国 Xbench 的测评结果更直观地说明了为什么开发者对 Fable 5 的体感会出现分歧：

•首先，Fable 5 的提升没有直接表现为所有 benchmark 分数全面上涨；

•在 ScienceQA 等测试里，安全路由、拒答和 fallback 会拉低总分，但把输出 token 等细项拆开看，它在部分任务上能用更短的推理链完成回答。

成本

9. 综合 Xbench 中 Fable 5 平均输出 token 更低的结果，以及部分开发者把 effort 调到 low 后的实际体验，可以得到一个粗略的成本估算：Fable 5 的 token 单价虽然约为 Opus 4.8 的 5 倍，但在一些任务里，由于输出 token 和中间推理消耗更少，token 用量约只有 Opus 4.8 的 1/2，甚至如果将 effort 调成 low，中间过程用量会低于 1/5，因此， Fable 5 在 low effort 综合成本可能低于 Opus 4.8。

10. 但这并不意味着 Fable 5 在所有场景里都更省钱。在更接近真实 coding agent 的 CursorBench 里，成本和性能的关系会变得更复杂。

11. CursorBench 3.1 显示，Fable 5 Max 分数最高，但 cost/task 也最高；同时，test-time compute scaling 已经比较平缓，继续增加推理预算仍能换来更高分，但单位成本带来的边际提升已经下降。

Insight 02

Use Case：企业 Workflow 重塑

12. 有创业团队提到，Fable 5 已经几乎重塑了他们的工作流程。现在更多是由人来确定目标、边界和验收标准，模型负责拆解任务并推进执行。随着 Fable 5 在端到端任务上的能力提升，人和 agent 的分工也在变化：团队越来越像一个 file system，每个人都是独立 IC，把任务交给模型后持续跟进结果。

13. 虽然 Fable 5 能自己补上下文、拆任务、开 sub-agent、自检和修正，但这不意味业务流程就自动化了。因为模型能并行调用 100 个 sub-agent，也可能把错误路线放大；真正可复用的 workflow 需要稳定输入、输出、状态管理、异常处理和验收标准。无论是 Opus 4.8 还是 Fable 5，从 0 到 1 搭建一个可复用 workflow 仍然很费劲，最后常常需要人花一两周重新整理和改写。

14. 企业提效的基础框架仍然是 workflow 加 toolchain，AI 只是让后两步发生变化。

15. 企业 AI 转型的关键，不只是用 AI 替代现有流程，而是重构流程本身。减少信息传递、压缩协作层级、简化决策链路，往往比单纯给员工配更强的模型更能创造价值。

16. 随着模型能力提升，面向 coder 和非 coder 的 agent 将走向两条不同路径：

•Coder 需要更开放、更可编程的系统；

•非 coder 需要更简单、更稳定的任务界面，依赖 GUI、预定义工作流完成工作。

17. 大部分用户没有必要同时扮演生产者和消费者，harness 的价值是把模型能力封装成可直接使用的工作界面。

18. 设计、3D 和交互 demo

用户在 three.js、3D 世界构建和 one-shot 网站设计中感受到 Fable 5 的 design taste 有明显提升。比如 Fable 5 能生成更复杂的 3D demo，复杂度从简单小游戏提高到接近 “Minecraft” 风格的互动场景；在 one-shot 网站设计中，Fable 5 第一次生成的网站就已经有一定美感，AI 配色感更弱，也更会在视觉表达上做减法，呈现出一些 “less is more” 的 design taste。

19. 反编译和隐藏上下文获取

在这类任务里，Fable 5 需要从网页、混淆 JS、Android App、游戏 ROM 和运行逻辑里获取上下文，再还原产品功能或游戏机制。

一个例子是把 web 游戏还原到 Godot，Fable 5 能通过混淆 JS 还原第一关逻辑，代码可以运行，主要元素也能复现。短板主要出现在视觉细节上，元素大小、重叠、缩放和参考图对齐不够稳定，即使用户提供参考图，模型也未必能把所有视觉细节调准。

“混淆 JS”通常指 JavaScript 代码混淆（JavaScript Obfuscation），就是把原本容易阅读和理解的 JavaScript 源代码转换成难以阅读但功能不变的代码。

有开发者认为，类似于“混淆 JS”这类能力其实从 Opus 4.6 开始就可能已经逐步形成，这类能力与安全和黑客技巧相关训练被模型吸收有关，也给网络安全提出了更高要求。

20. TypeScript Eval

这个任务相当于写一个 Excel，规格文档有几千行。Fable 5 用了约 3 小时、花费约 200 美元一次完成，是第一个完成该任务的模型。相比之下，GPT-5.5 xhigh 大约需要 10 小时，功能完成度接近 90%，但工程决策和性能较弱。

这个例子一定程度上可以说明 Fable 5 已经能搞定一些旧模型容易卡住的复杂 POC。不过，虽然这类复杂任务后续可以交给 Fable 5，但日常开发场景里，开发者认为自己大概率还是会优先用 Codex。

21. Long Horizon 任务

一位 CTO 级用户过去一年 AI 编程超过 100 万行，最近 3 个月日均 AI coding 成本超过 1000 美元。Fable 5 开放后，他拿之前做过的生产任务重新对比和延续测试，两天花费超过 1 万美元。实际体验下来，他认为 Fable 5 相比 Opus 4.7 / 4.8，主要提升在工具调用熟练度和稳定性上，智能水平没有本质变化。

也有开发者基于 OpenClaw 自研了一个飞书上层插件系统，在企业内部部署了约 300 套，用户希望模型写一个每天定时自动升级这个系统的 workflow：能自动找到最新版本，处理 OpenClaw 和 Hermes 升级，保留自研 patch，修复上游 merge 后的冲突，并能持续复用。在已有 1.0 基础上，Fable 5 能处理具体版本问题，也能理解部分升级和 patch 修复工作，但它反复把“写一个通用升级 workflow”误解为“针对 0606 版本修一个 patch”。

也有开发者提到，在使用 Fable 5 直接跑一些 long horizon 任务时，主要卡点是任务跑得很久以后忘掉前面的信息。虽然 Fable 的 long horizon 能力有增强，但距离“无限上下文和无限可靠执行”还存在距离。

Insight 03

模型能力分化带来模型收入分化

22. Fable 5 实测中的“体验分化”会指向一个潜在趋势，即人们在使用模型时，会开始判断任务本身是否值得消耗最强模型。比如对于“Mythos 级别”模型而言，一个好标准是：不要只问“Fable 能不能做”，更要看“Sonnet / Opus 是否也能做得差不多”。如果旧模型也能凑合完成，Fable 的溢价就不一定成立；如果任务超出用户和旧模型的能力边界，Fable 才更容易体现差异。

23. 相对应，高价值任务也可以用三条标准判断：

•模型需要主动获取上下文，

•结果可以被清晰验收，

•任务本身能承受更高探索成本。

当模型要自己读代码、查环境、补背景、拆步骤、调用工具并验证结果时，Fable 5 更容易体现价值；当用户只把 Fable 当执行器、交给它已经定义清楚的小任务时，Fable 与其他模型之间的差距会被压缩。普通 coding、生活规划、聊天和结果较 fuzzy 的任务容易低估 Fable 5，通常就是因为验收不清或成本不值得摊开。

24. Fable 5 的 ROI 取决于任务价值，token 价格只是其中一个变量。对于上亿规模的投资决策，或支撑上亿 DAU 应用的核心 infra，额外 token 成本相对业务价值已经不再是主要约束。虽然当前我们还无法完全信任 Fable 5 / Mythos 承接这类高价值任务，但方向已经可见。如果未来 1–2 年模型成本再下降两个数量级，这类场景的可行性将明显提升。

25. 但在普通白领和 C 端场景里，Opus 4.6、国产模型或低价模型可能已经够用，因此前沿模型的商业问题变成：金字塔顶端的高价值任务有多厚、能产生多少收入、是否足够支撑持续扩张。

•模型价值分布可能比人类社会更偏向头部，因为模型供给比顶级人才供给更具弹性，小幅能力提升也可能带来显著价值差异。

•模型市场可粗略看作 P × Q：P 是单个任务价值，Q 是任务数量。随着模型成本下降，更多高价值任务会被释放出来，头部模型的价值集中度可能进一步提升。

26. AI 时代的 ToB 生产力市场可能是 ToC 的很多倍，推荐系统、搜索系统、底层 infra、企业内部工具链和大型工程重构，都会消耗大量 token。Fable 5 的 multi-agent / sub-agent 能力让超级工程更可行，或许未来模型可以做到自主写一个 Google、一个 Office 或重构大型系统。

27. 其实在 Fable 5 的 sub-agent workflow 里，并不一定每个环节都由最强模型完成，一些简单子任务可能会被路由给更便宜的 Haiku。比如，在一些 case 中，如果在 Codex / Claude Code 等环境里接入 DeepSeek、Gemini API 或本地小模型，这些模型也可能进入可调用的模型池。但当前的问题是 routing 还不够透明，用户很难知道每个步骤到底用了哪个模型、为什么这样分配，以及最终是否真的省钱。

28.未来一种可能的格局是，前沿模型拿走 80% revenue，开源或低价模型处理 80% token，也就是说，高价值任务继续交给 frontier model，低价值或可批量化任务交给便宜模型。

29. 低价模型需求不只来自 C 端，也来自 ToB 任务里的大量中低难度步骤。很多企业任务虽然整体是 long horizon，但拆开后，大量 step 只需要 GPT-4 level intelligence。

30. 一位做 ToB 场景的开发者提到，他团队内部 bench 显示，DeepSeek V4 可能已经接近 GPT-4o mini 水平。因此，只要低价模型能够稳定提供 GPT-4 级别的智能水平，就有机会在 ToB 场景中承接大量任务。

31. 虽然 frontier lab 也可以通过蒸馏把小模型做得很好，但在推理算力稀缺、高价客户供不应求时，frontier lab 缺少动力去卷低价模型市场。

32. 专门打高性价比的模型，也可能在 training、架构和推理 infra 上做不同选择，比如 Google 这类拥有芯片、Infra、模型和产品线的公司，可能通过 Flash 等路线把成本优化做到极致。

33. 国产半导体供应链和国产模型会一起进入“自主可控”叙事。国产模型的机会来自两方面：

•后发蒸馏和低成本推理；

•大量普通场景只需要足够好的智能。

34. 但如果头部模型公司愿意优化同等智能小模型，国产模型的单位成本优势能否长期保持，还需要观察。

35. Routing 的商业机会可能更集中在 harness 层：

•Coding 可能是特殊场景，因为 coding agent 能看到仓库、sandbox、日志和测试，比较容易端到端闭环。很多 vertical agent 只知道一次 LLM API call 给了什么 context，并不知道任务 ROI 最高的模型是哪一个。

•真正有价值的 routing，需要理解任务目标、上下文、验收方式、用户偏好、成本约束和可用模型池，因此可能成为 intelligence allocation 的核心位置。

Insight 04

Eval 和任务设计决定下一代模型迭代方向

36. Fable 在 implicit intent 上的表现更强，包括什么时候改代码、什么时候不改、什么时候拒绝危险请求；这种能力可能来自大量用户 trace 和 trajectory 的分析、清洗和再训练。

37. 从模型训练角度，到了 Fable 5 这一代，Eval 和任务设计会更直接地塑造模型迭代方向。过去 6 到 12 个月，用户还能凭日常体感感受到模型迭代，但现在，即使用户在日常使用中没有 aha moment，也不能直接说明模型能力没有提升，可能只是用户的任务想象力、需求定义能力和工作环境没有跟上。

38. 对模型公司来说，选择什么 eval、把什么行为定义成“好模型”，会直接决定下一代模型擅长什么。

39. ToC 和 ToB 可能走向两套模型优化体系：

•ToC 场景需要围绕用户体验建立商业模式。用户更关注快（速度）、好（效果）、省（成本），模型推理成本需要接近微信、抖音等头部 C 端应用能够承受的用户成本，AI 才能大规模进入生活场景。工作提效只是其中一部分，陪伴、娱乐、学习和个人服务等场景同样重要。

•ToB 场景会继续追求更高水平的智能。企业愿意为大型工程、高价值业务流程和决策支付溢价，因此模型能力、可靠性和可控性仍然是核心竞争力。

40. 从长期看，市场划分可能进一步从 ToC / ToB 演变为 To human / To agent，未来机器人也可能成为巨大的智能消耗终端。

41. Anthropic 和 OpenAI 的差异，既体现在模型大小，也体现在训练方向、产品 harness 和商业打法上：

•Anthropic 更相信 scaling，也更聚焦 text / code based data、企业级场景和大模型规模；OpenAI 的 RL、产品矩阵、迭代速度和商业打法更强；

•Anthropic 的 harness 让模型更会组织任务、调用工具、维护上下文、分配 sub-agent、把中间结果汇回主 agent。GPT-5.5 还没有像 Claude 那样训练 dynamic workflow 能力，如果 OpenAI 补齐 multi-agent 和 workflow，与 Fable 5 在 multi-agent 任务上的差距可能收窄。

42. 理想情况下，模型需要先理解用户真实意图，再判断自己有没有能力完成。但很多用户无法把真正想要的东西说清楚，隐性意图、使用习惯、工具偏好和项目背景都需要模型推断。

43. 需求定义能力正在成为新的瓶颈，很多 token 浪费来自需求本身不清楚。“一句话让模型完成复杂任务”往往难以奏效，就像人类团队也无法仅凭老板的一句话就准确交付复杂项目。

44. 随着任务复杂度提升，需求需要被结构化表达，包括背景、目标、边界、验收标准和迭代方式。OPP（Objective - Problem - Proposal）等框架，本质上是在将需求对齐工程化。无论是人与 AI，还是 AI 与 AI 协作，缺少清晰的需求对齐机制，产出都难以稳定复现。

45. 这个判断也能放到 GPT-5.5 与 Fable 的工程对照里看。有团队把 GPT-5.5 长期用在真实代码库中，发现它并非不能跑长程工程；只要任务被拆得足够清楚，并配套规范、AGENTS.md 和验收条件，GPT-5.5 也能连续跑几十个小时，交付出可接受的结果。

•测试体系迁移就是一个例子。有一个项目里原来有 3000 多个依赖 mock 的测试用例，需要迁移到真实环境，当团队把目标拆成“把 mock 用例改成真实测试用例”后，GPT-5.5 基本完成了迁移，上线可控性明显提高。这说明，当任务足够小、验收足够明确时，GPT-5.5 也能跑完数量很大的长程工程。

•大文件重构则提供了反向参照。团队让 GPT-5.5 自由重构时，它会改一小部分就停下来；后来团队加入“文件行数必须降到 1000 或 2000 行以下”这类硬约束后，模型才连续跑了接近两天，把 8 到 9 个大文件拆得更细。

Insight 05

Tokenmaxxing 减速 ≠ AI 泡沫

46. Tokenmaxxing 可能是阶段性难题，本质原因在于企业暂时选错了 KPI。

•如果企业把 token 用量当成 AI 转型排行榜，就会出现 reward hacking，大家为了证明自己 AI-native 而狂烧 token；

•更健康的 KPI 应该转向 valuemaxxing：哪些人、哪些 practice group、哪些 workflow、哪些任务消耗了 token，它们是否流向更高价值工作。

47. 数据库和 Snowflake 时代已经出现过类似问题：大量 query 带来高账单，企业需要 dashboard 看清查询是否支持了业务价值。AI 时代的 dashboard 更复杂，可能需要 FDE 或现场工程团队为客户定制。

48. 普通用户和重度用户的成本差异过大，订阅制会越来越难支撑。重度用户会把每月固定订阅迅速用完，普通用户又不愿为高额度买单。

49. Codex 和 Claude Code 自身也在承受高 token 成本压力，未来可能出现更细的任务计价、额度控制、模型路由、企业预算包和结果导向定价。

50. 企业 token dashboard 的核心，未必是直接衡量价值，第一步是让用户知道 token 花在哪里。很多 vertical 场景中，供应商无法准确知道某次输出给客户创造了多少价值，这只有客户自己知道，客户如果认可 token 流向更值钱的工作，就更容易接受预算增长。如果 token value 能被 dashboard 展示清楚，AI 行业增长可能回到更健康的状态，甚至出现二次加速。

51. 国内 token 压力还没有全面爆发，原因是客户铺开程度和成本结构不同：

•真正有钱的客户还没有全面铺开 token 消耗；

•在电商、招聘、广告等场景中，token 使用更容易形成明确的价值正反馈；

•国内 token 成本更低。

Insight 06

RSI ：AI Labs 共同的“高价值任务”

52. 对前沿模型公司来说，价值最高的一类任务可能发生在内部，也就是让模型参与并加速下一代模型的研究、训练、评估、方向选择。Recursive Self Improvement 是下半年最重要的技术主题之一。

53. RSI 和 tokenmaxxing 是一体两面：能 close loop 的任务更容易证明 token 价值。人和 agent 共同协作时，很难拆清价值到底来自人、模型、工具还是组织流程，只能粗略看 token；因此容易评估的任务可以通过 RSI 或 closed-loop eval 直接优化，不容易评估的需要先构建 benchmark 和 KPI。

54. 目前头部 labs 基本都在做 closed-loop research 或 automated research。如果内部模型持续领先于外部模型，并率先用于研究自动化，模型能力与研发效率之间就会形成飞轮。一旦飞轮转起来，最强模型可能长期优先服务于内部研发。这会拉大实验室之间的差距，也解释了为什么 labs 内部研究者对 Mythos / Fable 的评价更积极。

55. 未来可能出现的两个发展路径是：

•某一家实验室率先把模型自己的迭代速度提高，建立领先优势；

•所有头部实验室都在一定程度上用 RSI 解决更难的 research 问题，但因为实验资源和边际收益限制，提升速度逐渐放缓。

56. RSI 也会改变组织架构：当模型能端到端跑研究或工程任务，人类的瓶颈从操作执行转向目标定义和结果评估。真正重要的是写清 loop、goal 和 eval rubrics，让 agent 知道什么算完成，什么算有价值。这也会反过来要求企业建立更强的任务环境、数据接口、权限体系和安全边界。

Insight 07

AI 基建瓶颈：算力与存储

Sub-agents 对存储的影响

57. Mythos 最大的特点之一是 Sub-agents workflow，它训练的难点在于，从“同一个模型分饰两角”走向“主模型调度小模型”后，算法和 training infra 都会变复杂。

58. 当前更直接的做法是 end-to-end 训练同一个 checkpoint，让它在同一环境里同时扮演主 agent 和 sub-agent：主 agent 偏规划，sub-agent 偏执行，相当于用两个 loss function 一起优化。这种做法的前提是二者共享同一套模型架构和参数。

59. 更复杂的下一步，由大模型主 Agent 调度一个或多个小规模的 sub-agent 模型，这样就从训练单一模型，升级为同时训练和对齐多套模型。小模型如果只学执行，可能会损失必要的 planning 能力，因此还需要额外任务设计、数据清洗和评估体系。

60. Sub-agentsworkflow 其实可以看成一种 memory scaling：

•主 agent 不再把所有细节都塞进自己的 context window，任务会先被拆给多个 sub-agent；

•每个 sub-agent 在自己的上下文里处理一部分信息，完成后只把结论、代码改动或关键结果汇总回主 agent。

•这种设计会减慢主 agent context window 的消耗，也能缓解 1M context window 继续扩大带来的硬件和 batch size 压力。

61. 这个结构的关键成本在共享 context。主 agent 分配任务给多个 sub-agent 时，往往会重复传递用户背景、项目约束、工具偏好、任务目标等信息；

•如果这些内容能作为 shared prefix 复用，prefix caching 和 batch inference 就能显著降低 KV cache 转移成本。

•一个例子是，50K token 的 KV cache 如果作为 shared prefix 复用，batch inference 中的 KV cache 转移开销可能下降约 20 倍。

62. Sub-agent 也会提高 batch size，从而改善推理侧毛利：

•普通场景下，一个用户同时打开的并行 thread 数量有限，batch size 可能只有 34 到 35 左右；

•agents-workflow 一次拉起几十个 sub-agent 后，可以让 batch size 长期维持在更高水平。

对模型公司来说，batch size 更高意味着单位推理成本下降；对用户来说，这表现为任务并行推进更强，但 token 消耗和底层资源开销更不容易被感知。

63. Sub-agents workflow 对存储的影响存在 Jevons paradox。

•单位任务的存储成本可能下降。更多 sandbox runtime 可以放在 NAND 里，利用率提升后，单次任务的存储成本可能下降；多个 thread / sub-agent 反复读取共享状态，也会让 CXL 内存池更有用。

•但总存储需求可能反而上升。高价值任务会持续增加存储和内存消耗，而这类硬件供给更接近线性增长，未必追得上智能需求扩张。workflow 把单次调用做得更省后，用户可能会运行更多任务，最终推高总存储和内存需求。

Jevons Paradox（杰文斯悖论）指的是当一种资源的使用效率提高后，人们往往会更多地使用它，结果导致该资源的总消耗反而增加，而不是减少。

算力供给决定能否打价格战和 ARR 上限

64. 算力供给决定了模型公司短期 ARR 的天花板，也影响模型公司能否打价格战。因此，相比 Anthropic，OpenAI 不仅更有动力，也有充分的算力空间通过降价来抢夺市场份额。比如最近 GPT-5.6 传出降价预期，可能也是为了抢企业 ARR 和市场份额。

•Anthropic：Anthropic 非常缺算力，有市场消息，Anthropic 的算力量级大概在 2-3GW，其中约一半用于 training，真正用在 inference 上的供给更紧；

•OpenAI：OpenAI 算力更充足，有人猜测 OpenAI 的算力可能超过了 5GW，因此更有空间用降价抢份额。OpenAI 的价格空间主要来自两点：

1）B 卡带来的推理效率提升；

2）如果 OpenAI 的模型激活规模能做到小于 Fable，那么单位推理成本就会更低。

65. 一个潜在的趋势是，旗舰模型长期会变便宜：虽然模型的 reasoning token 和参数量在增加，但 API 价格仍在下降。事实上，模型在生命周期内的降价并不罕见，例如 GPT-4o 发布时 API 价格较 GPT-4 Turbo 低约 50%，相比之下，Anthropic 的降价频率较低。

66. Anthropic 短期能否盈利，关键看算力采购是否匹配收入增长。如果算力买少，模型供给会受限，企业 ARR 增长会受到压制；如果算力买多，短期折旧和租赁成本会拉高亏损。

67. 长期看，如果头部模型公司的 ARR 能做到 3000 亿美元级别，即使每年 training cost 达到 300 亿到 500 亿美元，inference 毛利维持在 60% 左右，盈利模型仍然可能成立。

68. 在每 GW 能支持多少收入这个问题上，市场的估算范围在 25-45B 之间，估算差异很大。

69. Fable / Mythos 的访问限制和监管风险，可能会增加企业对备用模型和硬件的需求。如果企业担心前沿模型因监管或安全风险被限制访问，会更重视备选方案，包括自研模型、基于开源模型微调、内部模型储备和多供应商部署。即使不考虑 Fable 5 这种最前沿模型，仅 Opus 4.6 到 4.8 这一代的需求也已经很旺盛，硬件产业链仍然处在瓶颈状态。

本文来自微信公众号“海外独角兽”，作者：拾象 Best Ideas，36氪经授权发布。