模型选型与成本
先用 eval 守住质量，再让 token ledger 与 cache breakpoint 守住账单

本章把两个容易混在一起的开发决策拆开：TS 5.3 用 quality / latency / cost 三轴选择 Opus、Sonnet 或 Haiku，并把换版本当成 breaking migration；TS 5.4 则把 token 预算、usage 计数、cost model、prompt caching 与 cache check-pointing 变成可计算、可观测的工程账本。

一、先定质量门槛，再比较 latency 与 cost

模型没有脱离 workload 的统一名次。先写出实际 prompts、数据、允许失败的 edge cases 与质量门槛，再在同一 evaluation set 上测准确率、p95 latency 和单次成本。官方选型建议同样把 use-case benchmark 放在模型升降档之前；因此「更强」或「更便宜」都不是单独的答案，只有满足约束后的最优折中才是答案。

截至 2026-10-16，下面按官方当前型号与定价页冻结一个可复检快照。表内只比较 blueprint 点名的 Opus / Sonnet / Haiku；官方当前阵容还列出面向 demanding reasoning 与 long-horizon agentic work、API ID 为 claude-fable-5-1 的 Claude Fable 5.1，但它不改变本章三档取舍方法。上一版快照（2026-09-27）之后，官方在 2026-09-28 发布 Claude Sonnet 5.5、2026-10-07 发布 Claude Haiku 5.5；Claude Sonnet 5 与 Claude Haiku 4.5 随之与更早的 Claude Opus 5、Claude Fable 5 一起列为 Legacy：仍可调用，官方建议迁移到同系列新型号。Legacy 不等于 deprecated——截至同日的 deprecation 表里这几个 ID 都还是 Active。本书题目里出现 claude-opus-5、claude-sonnet-5、claude-haiku-4-5-20251001 时，按「仍在服役的 pinned 旧型号」理解。

「相对排序」是官方型号总览对当前阵容给的 comparative latency，官方同时说明实际延迟取决于 prompt 长度、输出长度与 thinking effort，所以它只是起点，不能替代下面的实测。Haiku 4.5 是本表唯一不支持 adaptive 的型号：同为 Haiku 档，Haiku 5.5 已经 adaptive 且默认开 thinking，「Haiku 档不支持 adaptive」不再是一条档位规律，只是 Haiku 4.5 这个型号的事实。

一种稳健的 selection loop 是：先从能满足最难质量 gate 的档位建立 baseline；再向更经济的档位做相同 eval，只有质量仍过线才降档。反过来，若 Haiku 档已过质量与 latency gate，换成 Opus 只会改变成本与运行特征，不会自动解决 cache miss、错误计费或版本迁移问题。这里对应 P1：把 quality、latency、cost 与 thinking compatibility 逐项对表，而不是按模型名做价值判断。

二、Pinned ID 不等于无迁移风险

每个 Claude model ID 标识一个 pinned version，使用该 ID 时 underlying model 在它的生命周期内保持不变。这让回归结果有可追踪的版本锚点，但不意味着把配置中的 ID 换成下一代后仍会保持行为等价。P8 的做法是：生产配置钉住明确 ID；升级时把请求 contract、tokenization、thinking 与 eval baseline 一起当 breaking surface 审查。

Claude Sonnet 4.6 → Claude Sonnet 5 就是一个具体反例：同一份没有 thinking 字段的请求，会从不 thinking 变成 adaptive thinking；同时，新 tokenizer 对同一文本产生的 token 数约多 30%，实际增幅依内容而定。即使 API shape 看起来可直接替换，原有 max_tokens、成本估算与 latency baseline 也不能照搬。

三、Token ledger：把预算写成四类用量

成本管理不能只看 input_tokens。一次请求的总 input token 数是 input_tokens + cache_creation_input_tokens + cache_read_input_tokens；三类输入的计费单价又不同。再加上 output，基础 cost model 是：

total_input = input_tokens
            + cache_creation_input_tokens
            + cache_read_input_tokens

cost = (input_tokens                × base_input_price
      + cache_creation_input_tokens × cache_write_price
      + cache_read_input_tokens     × cache_read_price
      + output_tokens               × output_price) / 1_000_000

Thinking 也必须进账：模型用于 reasoning 的 tokens 按 output tokens 计费，即使 thinking text 没返回，也与 response text 一起占 max_tokens。因此 telemetry 已把 thinking 纳入 output_tokens 时，不要再另加一份「thinking estimate」造成 double count；预算不足时则要检查输出截断与成功率，而不是只庆祝账单变小。

截至 2026-10-16 官方定价页，prompt caching 相对 base input price 的倍数是：5-minute write 1.25x、1-hour write 2x、cache read 默认 0.1x——但 Claude Opus 5.5 与 Claude Sonnet 5.5 的 cache read 是 0.05x，Fable 5.1 是 0.025x。把它与三档 base input / output 价格合并，可得到下面的可算表；价格属于高时效产品行为，复用前必须按日期重查。

例如一次 Claude Sonnet 5 请求有 120,000 uncached input tokens 与 12,000 output tokens，则按当前表计算为 0.12 × $2 + 0.012 × $10 = $0.36（Sonnet 5.5 的 base 单价相同，结果一样）。Haiku 5.5 要多留一个心眼：它按整次请求的 prompt 长度定档，prompt（含 cache read 与 cache write）超过 100,000 tokens 的请求整单走高一档价格。预算系统至少要同时保存 model ID、价格版本日期、四类 usage 与业务成功标记；最后一个字段让团队比较的是「每个成功任务成本」，而不是把失败重试也包装成便宜流量。

四、Prompt caching：复用 prefix，不是存一份任意 blob

Blueprint 点名 prompt caching 与 cache check-pointing。当前官方文档没有把后者作为独立 API 名称定义，而是把细粒度机制写成 explicit cache breakpoints：在 individual content block 上放 cache_control，明确可复用 prefix 的终点。本章只把这项已查证机制映射到 blueprint 用词，不额外虚构一个名为 checkpoint 的参数。

缓存 prefix 按 tools → system → messages 建立；某层改变会让该层及后续层失效。断点 hash 累积覆盖到 breakpoint 为止，所以 static tools、system instructions、长背景与 examples 应靠前，per-request timestamp、来信或动态 context 应在断点之后。把 breakpoint 标在动态 block 上，等于每次请求主动换 hash。

{
  "model": "claude-sonnet-5",
  "system": [
    {
      "type": "text",
      "text": "...stable policy and examples...",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [
    {"role": "user", "content": "...per-request input..."}
  ]
}

生效前还有三个硬条件。第一，default cache lifetime 是 5 minutes，命中会免费刷新；需要更长 reuse window 时可用定价表中的 1-hour write。第二，cached prefix 必须达到当前 model 的 minimum。第三，首个 cache entry 要等第一个 response 开始后才可用；并发同时发出的 cold-start 请求不能假定互相命中。

最后，把 thinking mode 也当 cache key 的一部分管理：切换 thinking mode 会让 prompt caching 失效。若一次 deployment 同时改 model、thinking config、tools 与 system text，cold-cache latency 与行为回归就缠在一起；更稳的 rollout 会把变量拆开并按 version/config 维度观察。

五、Cache economics：先算 reuse，再看 usage

Cache 不是「开启就省钱」。写入比 base input 贵，读取才便宜；官方当前经济学是 5-minute cache 在一次 read 后回本，1-hour cache 在两次 read 后回本。真正要估的是同一 prefix 在 TTL 内的顺序复用次数，并扣除动态 suffix 与 output——两者照常计费。

下面以 Claude Sonnet 5、100,000-token static prefix、每次 1,000-token uncached suffix、4 次相同 output 的 sequential requests 为例。由于两方案 output 相同，表中只比较 input；所有单价都来自上面的截至 2026-10-16 官方定价快照。

上线后不能用 spreadsheet 预测代替 telemetry。每个响应的 total input 要由 input_tokens、cache_creation_input_tokens 与 cache_read_input_tokens 相加：creation 上升表示正在付 write，read 上升才表示 reuse；两者都为 0 时，结合 minimum threshold、prefix diff、TTL 与 breakpoint placement 逐项排查。不要把低于门槛而静默未缓存的请求误判成「缓存免费」。

把整章收成一个顺序：用真实 eval 选能过 quality gate 的最低成本模型；用 pinned ID 和 canary 管 migration；用四类 usage 建 token ledger；最后只对稳定、够长、会在 TTL 内复用的 prefix 做 breakpoint。模型名回答「谁来做」，账本与 cache evidence 才回答「是否做得起」。

本章题组