Fable 5.1 在 max effort 下登顶了智能指数，但独立评测同时给出一个相反的信号：每任务成本比 Fable 5 高约 20%。能力更强、单任务更贵，这两个数字放在一起，逼着我重新想清楚一件事——到底该给任务开哪个 effort 档位。
这一期我不谈"哪个模型最强"，只谈"怎么用 Fable 5.1 才不白花钱"：从登顶读数与成本读数出发，把 effort 档位、缓存命中、任务复杂度拆成可选的策略，并在 4sapi（https://4sapi.com）上做了分档实测。
一、开篇：登顶与涨价是同一枚硬币
评测机构把 Fable 5.1 在 max effort 下打出 66 分，放到智能指数第一的位置；同一份数据里，max effort 的每任务成本比 Fable 5 高出约 20%。这不是矛盾，而是同一枚硬币的两面：把推理强度拉满，能力和成本一起往上走。
工程上的正确反应不是"这么好就全部上 max"，也不是"太贵了全用低档"，而是先搞明白：哪些任务值得 max effort，哪些任务开低档效果几乎一样。档位选对了，才能既吃到能力上限，又避开 20% 的涨价。
二、开篇痛点：单任务成本失控的三个来源
单任务成本为什么容易失控，我归结为三个来源：
- 全部任务都开最高 effort，把"偶尔需要深度思考"的任务也当成"每次都要极限思考"；
- 忽略了缓存命中对成本的影响，同一个模型、同一段上下文，命中率不同账单完全不同；
- 没有按任务复杂度分配档位，把简单任务喂给最强档位，等于花高价钱买过剩能力。
这三个来源叠加，就是"模型很强但账单很贵"的典型路径。下面逐个拆解。
三、原理速览：effort 档位到底在调节什么
effort 档位（Light / Medium / High，最高档另有 max 之类）调节的不是模型参数，而是推理时愿意花多少"思考预算"。档位越高，模型越倾向于做更长链路的推理、自我校验与回溯；档位越低，越倾向于快速给出答案。
请求流上的区别：
同一次请求，不同档位
│
v
输入解析（固定）
│
v
推理预算分配 ← effort 档位决定这一环
├── Low ：快速路径，少推理，省 token
├── Medium ：平衡路径，常用档
└── High/Max：长链路推理，多 token，更贵
│
v
输出与计费（按 token 计费）
档位越高，单位任务的输出 token 往往越多、思考耗时越长，成本随之上升。登顶读数里的 66 分和 20% 涨价，正是 max effort 这一档的成本画像。
四、Fable 5.1 的一个隐藏改进：切换 effort 不破缓存
这一版有一个容易被忽略但对成本很关键的改进：切换 effort 不再破坏 prompt cache。过去我在高低档之间来回切换，缓存会被清掉，导致重复计费的输入 token 变多；现在切换档位后缓存仍在，重复上下文继续按缓存读取价计费。
这个改进的实际意义：档位路由变得更安全了。过去为了省钱切换档位，可能因为缓存失效反而更贵；现在可以放心地把不同任务路由到不同档位，不用担心缓存被频繁清空。
五、能力读数怎么用：不是所有任务都需要登顶档位
66 分登顶，说明能力上限确实拉高了。但工程选型的正确问题是：我的任务落在能力曲线的哪个位置？
我把任务按"需要验证的程度"和"边缘用例的数量"分成三类：
| 任务类型 | 特征 | 建议档位 |
|---|---|---|
| 低验证任务 | 结果直观、错误易自查 | Low / Medium |
| 标准任务 | 有明确规范、常规复杂度 | Medium |
| 高验证任务 | 需要长链路推理、多步校验 | High / Max |
官方实测建议与我的观察一致：对需要较少验证、边缘用例较少的任务，用较低 effort 几乎不损失效果；只有真正需要深度推理的任务，才值得开最高档。
六、为什么 max effort 单任务成本会高 20%
独立评测给的成本口径是"每任务成本"，不是"每 token 成本"。单任务成本 = 单任务 token 消耗 × 单价。max effort 抬高的是分子：更强的推理意味着更多的思考 token、更长的输出、更多的自我校验。
单任务成本公式
每任务成本 = （输入 token + 输出 token）× 单价
↑ max effort 主要推高输出与思考 token
所以 20% 的涨价，本质是"更强能力"的计价方式。它不是一个 bug，而是推理预算市场化之后的必然结果。问题的关键从来不是"贵不贵"，而是"这笔预算花在什么任务上"。
七、接入 4sapi：按任务动态切档位
实操环节。我在 4sapi（https://4sapi.com）接入 Fable 5.1，并在调用层根据任务特征动态选择 effort 档位。请求流向：
我的应用
│
v
任务类型判断（低验证 / 标准 / 高验证）
│
v
4sapi 网关（https://4sapi.com）
│ 统一格式 / 鉴权 / 限流 / 计费
v
Claude Fable 5.1（按档位路由）
接入代码，Python 示例：
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["4SAPI_API_KEY"],
base_url="https://4sapi.com/v1",
)
# effort 与价格档位映射（单位：元/百万 token，示意）
EFFORT_PRICING = {
"low": {"in": 10.0, "out": 40.0},
"medium": {"in": 12.0, "out": 50.0},
"high": {"in": 15.0, "out": 60.0},
}
def task_effort(task_meta: dict) -> str:
"""按任务特征决定 effort 档位。"""
if task_meta.get("needs_verification") and task_meta.get("edge_cases") >= 3:
return "high"
if task_meta.get("complexity") >= 7:
return "medium"
return "low"
def call_fable(task_meta: dict, messages: list):
effort = task_effort(task_meta)
resp = client.chat.completions.create(
model="claude-fable-5.1",
messages=messages,
extra_body={"effort": effort},
)
usage = resp.usage
price = EFFORT_PRICING[effort]
cost = (
usage.prompt_tokens / 1_000_000 * price["in"]
+ usage.completion_tokens / 1_000_000 * price["out"]
)
return resp, effort, cost
关键点是 task_effort：把"需要验证程度"和"边缘用例数量"变成档位路由规则，让简单任务走低档、复杂任务走高档。成本随档位浮动，能力也随档位浮动，两者同时挂到任务 ID 上。
八、分档实测：什么任务省得最多
我拿三类真实任务做了对照，记录每任务成本与完成质量：
| 任务样例 | 低档成本 | 高档成本 | 结论 |
|---|---|---|---|
| 重命名变量、格式化 | 最低 | 高 | 低档足够，省大头 |
| 常规代码生成 | 中 | 高 | 中档性价比最好 |
| 复杂重构、多步调试 | 高 | 最高 | 高档值得，质量差异明显 |
结论很直接：低验证任务切低档，成本可能下降明显且质量几乎不掉；高验证任务开高档，多花的钱换来可感知的完成度提升。中间的"常规任务"用中档兜底。档位选择的本质，是让每笔预算花在能产生质量差异的地方。
九、成本与风险提示
- max effort 的 66 分是能力上限读数，不代表业务需要全部跑在那一档。
- 每任务成本口径包含输入与输出两侧 token，评估时不要只看单价。
- 切换 effort 不破缓存是本版改进，但缓存命中率仍取决于会话结构是否稳定。
- 价格表要按实际生效版本填写，档位映射写进代码前先确认计费口径。
- 这里讨论的全部是合法接入、档位路由与计费优化，不涉及绕过官方限制。
十、effort 档位接入清单
- 给任务打标签：需要验证程度、边缘用例数量、复杂度
- 建立低/中/高三档的 effort 与价格映射
- 简单任务默认低档，复杂任务开高档
- 固定系统提示与上下文，保住缓存命中率
- 按任务 ID 记录档位与单任务成本
- 上线前用小流量验证分档后质量是否可接受
- 每周出一份"档位-成本-质量"对照表
总结
Fable 5.1 登顶与 20% 涨价是一体两面：能力上限和推理成本同步抬升。工程上的答案不是"全开 max"或"全用低档"，而是按任务特征动态切档——低验证任务省成本，高验证任务买质量，中间用中档兜底。缓存切换不失效的改进，让档位路由变得更安全。我在 4sapi（https://4sapi.com）的分档实测里看到，档位路由做对后，成本曲线和质量曲线可以同时保持合理。欢迎在评论区发表想法，一起聊聊 Fable 5.1 的档位怎么切最划算。