Nate Herk：Sol 的创意构建成本较低，但 Fable 更常赢得盲选

测试环境

• Agent 构建：相同 /goal 提示、给予完全创作自由；Fable 在 Claude Code，Sol 在 Codex；作者先盲看结果再揭晓模型。

• 三项构建：可玩自行车游戏、互动滚动网站、五个完全不同的视觉对象。

• API 回合：无 Agent 循环的快速、无状态任务，比较返回率、能力分数、速度和成本。

输入/配置

• 自行车游戏提示要求浏览器中的开放世界游戏、WASD 转向、空格跳跃、Q/E 空中特技、Shift 加速。

• 网站提示要求制作“最令人印象深刻的互动滚动网站”。

• 第三项只要求设计五个根本不同的视觉元素，并让模型返回 gallery 和五个 sister sites。

• 这些构建使用不同 harness，因此结果比较的是完整工作配置，而非裸模型。

结果数据

• API 快速任务的返回记录是 Sol 24、Fable 3；作者说明多数差异来自 Fable 拒绝回答。

• 在实际返回的答案中，Sol 能力分数 0.98，Fable 0.966；该批次花费 Sol $16、Fable $63。

• 作者的路由判断是 Fable 做经理/策略，Sol 做执行、验证和交付。

结论

在这组个人盲测中，Sol 的 token 和成本效率明显更好，且在“五个对象”这类开放任务中胜出；Fable 在创意构建的最终审美和完整度上更常被选中。这个结果支持“Fable 定方向、Sol 执行”的工作流假设，但不构成模型能力总排名。

局限

• 三个构建各一次，主观选择和作者设计偏好会影响结果。

• Codex 与 Claude Code 的工具链、默认提示和上下文管理不同，不能把成本差异全部归因于模型。

• API 24–3 的差距被拒答混淆；0.98 与 0.966 也不是公开标准 benchmark。

• 文章没有给出完整 API 输入、评分器、延迟分布或随机种子。

复现步骤

1. 在两个隔离仓库中固定同一 commit、同一 /goal 文本和相同资产权限。

2. 随机化模型运行顺序，清理 git 历史和缓存，避免第二个模型读取第一个模型的产物。

3. 对每个构建记录完成时间、输入/输出 token、工具调用、可玩性和盲评结果。

4. API 任务逐题记录“完成、拒答、错误、超时”，不要把拒答和能力失败混为一类。

5. 至少重复多轮并报告均值、离散程度和 harness 差异。

原始证据与数据

• 文章公开了三个构建的提示意图、耗时、成本和大致输出 token。

• 作者明确说 Sol 约为 Fable 一半 token 成本，并把 Sol 与 Opus 4.8 的价格层级视为更接近的比较。

适用边界

• 适合参考 Agent 构建的成本/质量权衡，不适合作为通用写作、数学或代码基准。

• “Sol 是 worker”是作者的经验模型；在其他 harness、任务边界或设计标准下可能反转。

• 涉及创意输出时，必须预先定义盲评 rubric，避免把个人审美写成客观胜负。

来源摘录或观察（仅做合规短引）

作者的核心路由比喻是 “Fable is the manager, Sol is the worker”。