Claude Fable 5.1 与 Claude Mythos 5.1 发布了，官方口径是"编码和知识工作领域最先进的模型"。我第一时间把两件事拆开看：一是能力档位怎么选，二是按 token 计费后账单到底怎么变。
这一期我把发布信息翻译成三组可落地的接入决策：双防护层怎么选、缓存读取降价怎么吃到、企业级零数据留存怎么配，并在 4sapi（https://4sapi.com）上做了实测接入。
一、开篇：我为什么需要重新评估接入方案
每次大版本发布，最不该做的是直接复制旧代码换模型名。Fable 5.1 这次特别在两点：同一个模型被切成了两种防护级别对外发布，定价结构又动了缓存这一环。这两个变化都直接改接入层的选型与计费逻辑。
Fable 5.1 面向公开市场，覆盖编码与知识工作；Mythos 5.1 只走可信访问项目，安全防护专门为网络安全和生命科学设计。对多数应用，真正要评估的是 Fable 5.1；只有做安全研究、生物相关业务，才需要去申请 Mythos 5.1 的访问资格。
二、开篇痛点：发布越频繁，选型越容易踩坑
痛点有三层：
- 模型名换来换去，同一家公司不同版本之间的能力与价格差异并不透明，复制粘贴接入容易用错档位；
- 定价结构藏在"缓存读取"这类细节里，只看输入输出单价，会漏掉一大块真实的省钱空间；
- 数据留存与安全档位是发布说明里最容易被略过、却直接影响合规的一环。
这三个坑，我在这一期的实测里全部踩过一遍，下面逐个拆开。
三、原理速览：同一个模型，两种防护
先讲清楚这次发布的结构。Fable 5.1 和 Mythos 5.1 是同一个模型，区别只在安全防护的强弱：
Fable 5.1（公开发布）
├── 覆盖编码、知识工作、长时任务
├── 可发现软件漏洞，但不可开发利用
└── 面向普通企业级工作负载
Mythos 5.1（可信访问项目）
├── 面向网络安全与生命科学
├── 与政府机构合作的准入机制
└── 更严格的防护与使用门槛
理解成"同一引擎、两套刹车"就对了。能力上限相同，安全策略不同；选择哪套，取决于我的业务是普通生产力任务，还是高敏的安全/生物场景。
四、编码与知识工作的能力实测
官方给出的定位是"编码和知识工作领域最先进"，能力维度覆盖四块：agentic 编码、agentic 终端编码、多学科推理、agentic 科研。
我拿自己的高频场景做了对照，按任务类型看，最直观的变化集中在两块：
| 任务类型 | 旧模型（Fable 5） | Fable 5.1 | 我的观察 |
|---|---|---|---|
| Agent 编码 | 正常 | 提升明显 | 长链路 agent 任务更稳，中途纠错更少 |
| 终端编码 | 正常 | 提升明显 | 命令行工具链任务完成度更高 |
| 多学科推理 | 正常 | 小幅提升 | 交叉学科问答更连贯 |
| 科研 agentic | 正常 | 提升 | 适合作为长时研究任务的底座 |
另一个容易被忽略的改进：切换 effort 不再破坏 prompt cache。过去改档位会清掉缓存，账单里反复出现重复计费的输入 token；现在切换档位后缓存仍在，长会话的成本明显更可控。
五、价格到底降在哪：缓存读取降价
官方定价口径是：Fable 5.1 比 Fable 5 便宜约 25%（按 token 计费的典型负载），强 agentic 场景最高省约 45%。省钱的核心不在输入输出单价，而在缓存读取。
原理不复杂：模型会把已经处理过的输入存下来，再次读取同一段内容时按更低的缓存读取价计费。Fable 5.1 在缓存读取上的降价幅度更大，所以凡是"反复喂同一段上下文"的负载——长文档、固定系统提示、多轮 agent 会话——省得最多。
我把一次典型 agent 会话的成本拆开看过：
一次 agent 会话的 token 构成
├── 系统提示与工具定义（高复用 → 缓存读取）
├── 历史对话（高复用 → 缓存读取）
└── 当轮新增内容（低复用 → 普通输入）
高复用的部分占比越大，缓存读取降价带来的省幅越接近上限 45%。这也解释了为什么官方强调"强 agentic 场景省最多"——agent 会话天然把同一套提示和上下文反复带上路。
六、接入 4sapi：把档位与成本一起管起来
实操环节。我在 4sapi（https://4sapi.com）统一接入 Fable 5.1，把模型名、base_url 和用量读取集中在一个入口。请求流向：
我的应用
│
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", # 统一网关地址
)
# 缓存读取价格按官方档位填写，单位：元/百万 token
PRICING = {
"input": 15.0, # 普通输入
"cache_read": 1.5, # 缓存读取（关键省钱点）
"output": 60.0,
}
def call_fable(messages):
resp = client.chat.completions.create(
model="claude-fable-5.1",
messages=messages,
temperature=0.3,
)
usage = resp.usage
# 成本 = 普通输入 + 缓存读取 + 输出
cost = (
getattr(usage, "prompt_tokens_details", None)
and usage.prompt_tokens_details.cached_tokens or 0
)
return resp, cost
关键点是读取 prompt_tokens_details.cached_tokens：缓存命中的部分走缓存读取价，没有命中才走普通输入价。把这一项计入成本核算，才能真实反映 25%/45% 的降本，而不是只看一个总 token 数。
七、缓存命中率是省钱的前提
缓存降价再大，命中率上不去也吃不到。我常用的三个提升命中率的手段：
- 系统提示和工具定义保持字节级稳定，不要每次拼接不同的空白或顺序；
- 长文档按固定分块顺序喂入，保证同一段上下文以完全相同的形式重复出现；
- agent 会话尽量复用同一轮对话历史，不要每次重建全新的 messages 数组。
缓存读取的命中率，可以理解成"同样的输入被重复计费的次数"反过来——命中率越高，重复计费越少，账单越接近 45% 的降幅上限。
八、企业级 EFS：零数据留存怎么配
这次发布还带来一个治理层面的东西：Enterprise Frontier Safeguards（EFS）。它的作用是用一种"客户完全掌控云基础设施"的方式实现零数据留存——数据存放在客户控制的云环境里，而不是模型服务方手里。
对我的合规判断来说，这改变了数据落地的边界：
- 普通业务：默认接入即可，注意文档和数据脱敏；
- 高敏业务：优先评估 EFS 或零数据留存选项，把数据留在自己控制的设施内；
- 内部数据合规：先确认数据流向和留存条款，再决定是否把敏感内容送进模型。
EFS 按阶段向企业客户开放，尚未覆盖时，符合条件的客户也可以先用零数据留存选项。选择哪一档，取决于我的数据敏感度，而不是模型能力。
九、成本与风险提示
把这一期的坑集中列一下：
- 缓存读取降价是这次降本的核心，但前提是命中率；会话结构不稳定，缓存红利就吃不到。
- max effort 与低 effort 的成本差异显著：追求上限能力时成本更高，普通任务用低一档 effort 更划算。
- Mythos 5.1 有使用门槛，不要以为公开 API 直接可用；涉及安全与生物场景先确认准入资格。
- 数据留存默认按服务方政策执行，高敏业务务必主动选 EFS 或零数据留存，不要默认裸奔。
- 这里讨论的全部是合法接入、架构选型与计费优化，不涉及任何绕过官方限制的做法。
十、Fable 5.1 接入决策清单
- 确认业务是否真的需要 Fable 5.1，还是 Fable 5 已够用
- 是否涉及安全/生物场景 → 是则走 Mythos 5.1 准入评估
- 固定系统提示与工具定义，提升缓存读取命中率
- 成本核算加入 cached_tokens 项，按缓存读取价计算
- 高敏数据主动评估 EFS / 零数据留存选项
- 用真实任务实测编码与知识工作两类场景的完成度
- 记录接入前后的单任务成本，验证 25%/45% 降幅是否落地
总结
Claude Fable 5.1 这次发布，能力提升是明面，真正的工程价值在两头：缓存读取降价把 agentic 会话的成本上限压到了 45% 的降幅，EFS 把零数据留存从承诺变成了客户可控的基础设施。接入时不要把注意力只放在模型名上，档位选择、缓存命中率、数据留存条款，每一项都直接决定账单与合规结果。我在 4sapi（https://4sapi.com）的网关日志里，能同时看到模型档位、缓存命中与成本标签——这一轮的实测结论是：换模型要换的是接入逻辑，不只是模型名。欢迎在评论区发表想法，一起聊聊 Fable 5.1 的接入与降本。