# Token 经济学：成本、缓存与性能工程

Token 消耗是 Claude Code 的核心成本约束——每次 API 调用都涉及输入 token 计费、Prompt Cache 命中优化和输出 token 预算控制。本章解析系统如何通过上下文压缩（共六层机制：工具结果预算 / snip / microCompact / API-level microcompact / context collapse / autoCompact · 详见 Part 4 第 2 章「token 是一等公民」§ 第四层 & Part 2 第 4 章「查询循环」§ 四）、缓存友好的提示词排列和投机执行来管理这个"货币系统"。

> **源码位置**：`src/utils/token.ts`（计数与预算）、`src/utils/compact.ts`（上下文压缩）、`src/services/api/claude.ts`（API 调用与缓存参数）

---

## 🌍 行业背景：Token 成本是 AI 产品的"隐形战场"

Token 消耗不只是技术细节——它是 AI 编程助手的**核心商业逻辑**。每个 AI 编程产品都在回答同一个问题：如何在有限的 Token 预算内，给用户最大的价值？

各家的策略截然不同：

| 产品 | Token 优化策略 | 定价模式 | 核心思路 |
|------|--------------|---------|---------|
| **Claude Code** | Prompt Cache 边界工程 + 上下文压缩 + 投机执行 | 按 token 计费（API 直通） | 把缓存命中率做到极致，让用户"每一分钱买更多智能" |
| **Cursor** | Fast/Slow 模型切换 + Background Agents 云端资源 | 阶梯订阅制（$20/$60/$200） | 用模型分级消化成本；云端 VM 执行成本内含于高阶订阅 |
| **Kimi Code** | Agent Swarm 极致并发 + 低价 MoE 模型 | API 按量计费（$0.60/$3.00/1M token） | 1T MoE 仅激活 320 亿参数，推理效率极致，价格约为 Claude Opus 4.5 的九分之一 |
| **Aider** | AST 级 Repo Map 压缩 + Architect 模式差异化模型 | 用户自带 API key | AST 图谱大幅降低上下文 Token 消耗；高阶推理用顶级模型，编辑用低成本模型 |
| **OpenCode** | 75+ 模型提供商支持（含本地 Ollama） | 完全开源免费 | 支持本地模型运行，从根本上消除 token 成本；Go+Zig 底层极低运行开销 |
| **MiniMax Code（M2.5）** | 前置架构规格书 + 极低计算成本 | 开放权重 / 极低 API 成本 | 每秒 100 Token 连续运行一小时仅需 1 美元，成本优势碾压级 |
| **GLM（Z.ai）** | 超大规模参数（具体以 Z.ai 官方公告为准） + 国产算力 | 权重开源 / 订阅制 | 全量训练在国产芯片上完成；Z Code 平台面向私有化部署，数据不出境 |
| **GitHub Copilot** | Agent Mode 全面 GA + 企业级 MCP 注册表 | 固定订阅价（$10-$19） | 微软用 Azure 规模优势摊薄成本，内置 Explore/Plan/Task 专职智能体 |

**Claude Code 的独特定位**：在本文调研的 AI 编码工具中，Claude Code 对 Prompt Cache 的工程投入最为系统化——不仅使用缓存，还通过 TypeScript 类型系统（`CacheSafeParams`）在编译期约束缓存安全性。其他产品的缓存是"有则更好"的优化，Claude Code 的缓存是"没有就亏钱"的核心设计约束。这直接塑造了系统提示词的排列顺序、消息的组织结构、甚至工具描述的加载时机。

---

## 📚 课程桥接：操作系统的资源调度视角

如果你学过操作系统课程，Token 经济学的概念会让你感到熟悉——因为它本质上就是**资源调度**问题。

| Token 经济学概念 | 操作系统对应 | 共同本质 |
|----------------|------------|---------|
| Token 预算（200K 上限） | **CPU 时间片 / 内存配额** | 有限资源的分配——每个进程有 CPU 配额，每个对话有 token 配额 |
| Prompt Cache | **页面缓存（Page Cache）** | 频繁访问的数据缓存在快速层，避免重复从慢速层读取 |
| 上下文压缩 | **内存页面置换（Page Replacement）** | 空间不够时，把"最不重要"的内容换出去，腾出空间给新内容 |
| 投机执行 | **CPU 分支预测（Branch Prediction）** | 猜测下一步操作，提前执行；猜对了零延迟，猜错了丢弃结果 |
| 成本优化（缓存命中率最大化） | **完全公平调度器（CFS）** | 在多个竞争需求之间找到最优资源分配策略 |
| `maxResultSizeChars` 截断 | **进程内存限制（ulimit）** | 硬性上限防止单个消费者耗尽共享资源 |

> 💡 **通俗理解**：Token 调度就像**高速公路收费站的车道管理**——高峰期不可能让每辆车都走 ETC 快速通道（太贵），也不能让所有车走人工收费（太慢）。系统要做的是：把最常走的车（系统提示词）办成 ETC（缓存），把偶尔走的车（新消息）安排人工通道，把超长车队（大文件）限流。目标是用最少的收费员（token 成本）让最多的车通过（完成任务）。

---

## 引子：城市的水费单

每个月你交水费，不会特别在意——水龙头一开，水就来了。但如果你管理的是一座城市的供水系统，每一滴水的成本都会被精确追踪：水源处理费、管道输送损耗、高峰/低谷差价、水厂维护费。

Claude Code 的 Token 就是这座城市的"水"。每次 API 调用消耗 token，每个 token 都有成本。系统中大量设计决策——上下文压缩、Prompt Cache、投机执行、工具描述延迟加载——本质上都是在做**水资源管理**：减少浪费、复用已处理的水、在低谷时储水。这与 AI 工程社区的一个共识一致——"上下文是最贵的资源，必须主动管理"（这是该领域多位从业者反复强调的观点，不归属于某一个具体作者）。

> **🔑 OS 类比：** Token 就像**手机流量**。Prompt Cache = 已经下载缓存的网页（再次访问不用重新下载），上下文压缩 = 清理手机存储腾出空间，Token 预算 = 你的月流量套餐上限。用得越省，能做的事越多。
>
> 💡 **通俗理解**：Token 经济学就像**手机话费管理**——打电话（输出 token）= 最贵的通话费；接电话（输入 token）= 相对便宜；套餐内通话（缓存读取）= 便宜 10 倍；超出套餐（缓存未命中）= 全价计费。整个系统的设计都在想方设法让你留在"套餐内"，把话费账单控制在最低。

---

## 1. Token 的四种"水价"

不是所有 token 的成本相同。Claude API 有四种 token 类型：

> **⚠️ 价格说明**：以下价格为本研究写作时（2025年中）的数据，请以 Anthropic 官网 anthropic.com/pricing 为准。不同模型、不同时期的价格和缓存费率可能不同。

| 类型 | 价格（Opus 4.6）| 相对成本 | 类比 |
|------|----------------|---------|------|
| Input Token | $15 / 1M | 1x | 自来水管网供水 |
| Output Token | $75 / 1M | 5x | 净水器出水（贵 5 倍）|
| Cache Read Token | $1.5 / 1M | 0.1x | 回收利用的中水 |
| Cache Write Token | $18.75 / 1M | 1.25x | 建设水库的前期投入 |

**关键洞察**：Cache Read 比 Input 便宜 **10 倍**。这意味着只要你能让请求的前缀命中缓存，你就在用十分之一的价格"买水"。Claude Code 的**大量设计决策都在追求缓存命中率**。

> 💡 **通俗理解**：Prompt Cache 就像**餐厅的预制菜**——常点的菜提前备好半成品（缓存写入，有前期投入），下次再点只炒最后一步（缓存读取，便宜 10 倍），大幅节省时间和成本。整个提示词的排列顺序，就是为了让"菜谱的前半段"尽量不变，这样"预制菜"每次都能复用。

---

## 2. Prompt Cache：系统的"水库"

### 2.1 工作原理

Anthropic API 的 Prompt Cache 机制：如果两次请求的消息前缀完全相同（逐 token 比较），重复部分不需要重新处理。

```
请求 1: [系统提示词][工具Schema][历史消息][新消息A]
请求 2: [系统提示词][工具Schema][历史消息][新消息B]
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     相同前缀 → 缓存命中！只有 [新消息B] 是新的
```

### 2.2 缓存共享范围

Anthropic 的 Prompt Cache 在组织（organization）级别内共享，同一 org 内的并发请求可以复用缓存前缀。但缓存不跨组织、不跨区域（region）共享。对于企业用户，这意味着团队内的 Claude Code 实例天然共享缓存，进一步放大了前缀稳定性的经济价值。

### 2.3 缓存边界工程

Claude Code 在 API 请求中精心放置 `cache_control` 断点，控制缓存的粒度：

```
[系统提示词] ← cache_control 断点 ①
 这部分几乎不变（同一 session 内完全不变）
 → 每次都命中缓存
 
[工具 Schema] ← cache_control 断点 ②
 工具列表很少变化（除非 MCP 服务器变化）
 → 绝大部分时候命中缓存

[历史消息] ← cache_control 断点 ③
 只有新消息在增长
 → 已有消息命中缓存
 
[新消息]
 每次都不同
 → 必须全额付费
```

**数字：** 一个典型对话的系统提示词 + 工具 Schema 大致在**一到几万 token 的量级**（具体因会话上下文、启用工具、CLAUDE.md 大小、CoCoA feature gates 动态变化；"20,000-40,000 token" 是作者基于典型会话的观察估算，非源码硬编码）。若命中缓存，这部分 token 的成本会显著下降（具体倍数与节省金额取决于当时的 Anthropic pricing，以官方 pricing 页为准——不同模型和折扣档差异较大）。

### 2.4 CacheSafeParams

> 💡 **通俗理解**：想象一家连锁餐厅的中央厨房。所有分店（子 Agent）必须使用**同一批食材、同一个配方**做菜，这样顾客在任何一家店吃到的味道都一样。如果某家分店偷偷换了食材（改了参数），就和"总店味道"对不上了（缓存失效）。`CacheSafeParams` 就是那份**强制统一的配方清单**——TypeScript 编译器会在你"偷换食材"时直接报错，不等菜端上桌才发现味道不对。

`CacheSafeParams` 是一个类型约束——保证特定的参数组合不会破坏 Prompt Cache。简单说：子 Agent 必须和父 Agent 用完全相同的"缓存钥匙"，才能打开同一把"缓存锁"。

使用场景：
- **forkedAgent**：从父请求派生的 Agent，共享父请求的消息前缀 → 保证缓存命中
- **/btw 命令**：侧问（不进入主对话流），共享当前请求的缓存
- **投机执行**：预测的下一条消息也使用 CacheSafeParams，确保缓存不 miss

### 2.5 两个被低估的缓存优化细节

**① cache_edits：不失效缓存的增量删除**

当上下文需要清理过期的工具结果时，直接删除消息会破坏缓存前缀。`cache_edits` 是 Anthropic API 的一个未公开机制，通过三步实现"在服务端跳过消息，但不破坏缓存"：

1. 本地记录要删除的工具结果 ID（`tool_use_id`）
2. 在 API 请求中发送 `cache_edits: [{ type: "delete", cache_reference: "tool_use_id" }]`，告诉服务端"读缓存时跳过这些消息"
3. 服务端标记为"跳过"但不删除——缓存前缀完整保留

> 💡 **通俗理解**：就像图书馆的书架——你不需要把整排书搬走再重新排列（缓存失效），只需要在不想要的书上贴一个"跳过"标签（cache_edits），管理员扫描时直接跳过这本书，其他书的位置完全不变。

关键限制：每轮 API 请求都需要重发 cache_edits 指令（标记不持久化）；只在缓存还"热"时（5 分钟 TTL 内）使用——缓存已冷时，直接清空消息即可，因为反正要重建缓存。

**② Agent 列表位置优化：节省 10.2% 缓存创建开销**

源码中有一处看似简单的改动产生了可量化的效果：将 Agent 列表从工具描述（在缓存的 `system` 段内）移到 Attachments（在缓存段之外）。这一处调整使 Cache Creation Tokens 减少了约 **10.2%**——在每日数百万次 API 调用的规模下，这是非平凡的成本节省。

> 📌 **来源追溯**：10.2% 数字出自源码注释——`src/tools/AgentTool/prompt.ts:53` 记录 *"The dynamic agent list was ~10.2% of fleet cache_creation tokens"*，`src/utils/attachments.ts:1482` 同一数字再次出现。这是 Anthropic 内部对生产环境 fleet 级别缓存创建 Token 的统计，非外部估算。

### 2.6 缓存失效的隐形代价

缓存失效不会产生错误——系统照常工作，只是**静默地多花钱**。这使得缓存 miss 很难被发现。代码中记录了几个已知的缓存失效场景：

| 场景 | 原因 | 发现方式 |
|------|------|---------|
| MCP 服务器变化 | 工具 Schema 变了，断点 ② 后全部 miss | 成本监控 |
| 对话分支不复制 content-replacement | 消息前缀不一致 | 代码 review |
| KAIROS 日期字面量 | 跨日后系统提示词变化（KAIROS 是 Claude Code 的"助手模式"内部代号——Part 3 第 24 章详细展开；这里提到的"日期字面量"指如果系统 prompt 里直接内嵌 `今天是 2026-04-22` 这类字符串，日期一变前缀就失配，缓存全部失效） | 性能测试 |
| 上下文压缩 | 压缩改写了历史消息 | 设计时已知 |
| Post-compact 通知 | 压缩后 `notifyCompaction()` 主动重置缓存基线 | 预注册的"已知 break" |

上表中"Post-compact 通知"是一个精巧的设计：系统知道压缩必然破坏缓存，所以 `notifyCompaction()` 提前"登记"这次 break，使得 `promptCacheBreakDetection.ts` 不会把压缩后的预期缓存 miss 误报为异常——把监控系统的注意力留给真正意外的缓存失效。

上表只是冰山一角。`promptCacheBreakDetection.ts`（700+ 行）实际追踪了**十余个缓存失效检测维度**（本书正文以 "14" 作为概数引用；源码中实际字段数随版本变化，当前快照里更接近 19 个字段的检测矩阵。以 Part 3「Prompt Cache 可观测性完全解析」章节的逐字段表格为准），包括模式切换、工具增删、CLAUDE.md 变更等。系统还使用了"粘性闩锁"（sticky latch）机制——一旦进入某个模式就尽量不切换回来，因为模式切换几乎必然导致缓存前缀不匹配。这不再是"性能调优"——在规模化场景下（每日数百万次 API 调用），每次缓存未命中都是实际的成本支出，Prompt Cache 本质上是一个**计费优化问题**。

> 📖 **深度阅读**：14 个缓存失效向量的完整检测机制（工具级 Schema 哈希追踪、Diff 诊断输出、粘性闩锁实现细节）详见 **Part 3「Prompt Cache 可观测性完全解析」**。

---

## 3. 上下文压缩：不是省钱，是"续命"

压缩的首要目的不是省钱——是**避免 context window 溢出**。200K token 的窗口看起来很大，但一个复杂任务可能涉及：
- 系统提示词：20-40K
- 工具 Schema：10-20K
- 几十轮对话 + 工具调用：100K+
- 留给新消息的空间：越来越少

如果不压缩，大约 30-50 轮对话后就会达到 `blocking_limit`（这是 Claude Code 内部的硬上限阈值：当 context window 中的 token 总量逼近模型 context 上限时，继续发请求会被 API 拒绝，此时必须触发压缩或终止会话。"30-50 轮"是作者基于典型会话观察的经验值，实际轮次数随每轮 token 体量差异很大）——心脏停跳，对话被迫终止。

压缩的**附带好处**是省钱：减少了每次 API 调用的输入 token 量。但**代价**是缓存失效——压缩后的消息和压缩前的不一样，缓存前缀被破坏。

这是一个**经典的 trade-off**：压缩延长了对话寿命但增加了单次成本。系统选择"尽可能晚压缩、尽可能少压缩"来平衡。

> 📚 **课程关联**：上下文压缩与缓存失效的矛盾，和计算机体系结构课程中**缓存层级**（Cache Hierarchy）的经典困境完全同构。Prompt Cache 相当于 L1 缓存（命中率高、访问成本低），原始 API 调用相当于主存访问（慢且贵），而上下文压缩相当于操作系统的**页面置换**（Page Replacement）——当工作集超过物理内存时，必须把部分页面换出到磁盘，但换出操作本身会导致 TLB（Translation Lookaside Buffer）失效。Claude Code 选择"尽可能晚压缩"的策略，正是 OS 课程中"延迟换页"（Lazy Paging）思想的应用——只在真正逼近内存上限时才触发置换，最大化缓存命中率。如果你学过 LRU / LFU 置换算法，这里的"保留最重要消息、压缩最不重要消息"就是同一类决策问题。

---

## 4. 投机执行：以缓存为筹码的预测优化

投机执行（Speculation）是 Claude Code 中颇具进取性的性能优化策略：在用户尚未输入下一条消息之前，系统预判用户意图并提前发起 AI 推理。

### 4.1 为什么能省延迟（以及顺带共享缓存前缀）

如果猜对了：
- 用户按 Enter 时，AI 的回答**已经准备好了**——零延迟
- 猜测请求和真实请求共享消息前缀 → Prompt Cache 命中

如果猜错了：
- 投机结果被丢弃——白花了 token
- 但通常只是一条消息的 output token（几百到几千 token），成本有限

### 4.2 什么时候值得赌

投机执行的价值 = P(猜对) × 节省的延迟 - P(猜错) × 浪费的 token 成本

在以下场景中 P(猜对) 很高：
- 用户刚提交代码，下一步很可能是"运行测试"
- AI 提出了修改方案，下一步很可能是"好的，执行吧"
- 上下文中有明确的 TODO 列表，下一步是列表中的下一项

---

## 5. 八个 Counter：系统的仪表盘

`state.ts:952-989` 定义了 8 个 OTel Counter，是系统的"水表"：

| Counter | 追踪什么 | 为什么重要 |
|---------|---------|-----------|
| `claude_code.session.count` | 会话数 | 使用量基准 |
| `claude_code.lines_of_code.count` | 代码行变化 | 生产力指标 |
| `claude_code.pull_request.count` | PR 创建数 | 工作流集成度 |
| `claude_code.commit.count` | 提交数 | 代码产出 |
| `claude_code.cost.usage` | 花费（USD）| **核心成本指标** |
| `claude_code.token.usage` | Token 消耗 | 资源使用 |
| `claude_code.code_edit_tool.decision` | 代码编辑的接受/拒绝 | **AI 质量指标** |
| `claude_code.active_time.total` | 活跃时间 | 效率指标 |

**`code_edit_tool.decision`** 是最有趣的——它追踪用户对 AI 代码编辑的接受率。这直接反映了"AI 的代码修改质量好不好"——如果拒绝率高，说明 AI 经常改错。这是 Anthropic 产品团队的**核心质量信号**。

---

## 6. Token 预算系统

### 6.1 工具结果预算

每个工具有 `maxResultSizeChars` 限制。超过阈值后，系统**不是简单截断丢弃**——完整结果会被**持久化到 `~/.claude/tool-results/` 磁盘路径**，对话正文里替换为 `<persisted-output>` 标签包裹的引用型预览（详见 Part 2 第 5 章「工具运行时」§4 步骤 6）。"截断"一词在这里指的是**对话正文中看到的预览是截断版**，完整数据仍可被读取，信息不丢失。这是为了**控制 input token 量**——一个 Read 工具读取 10,000 行文件，全部放进上下文就是几万 token。系统设置合理的上限，平衡"AI 需要看到足够信息"和"不浪费 token"。

### 6.2 模型选择的经济学

不同模型的 token 价格差异巨大：

> **⚠️ 价格说明**：以下价格为本研究写作时（2025年中）的数据，请以 Anthropic 官网 anthropic.com/pricing 为准。不同模型、不同时期的价格和缓存费率可能不同。

| 模型 | Input | Output | 特点 |
|------|-------|--------|------|
| Opus 4.6 | $15/M | $75/M | 最强，最贵 |
| Opus 4.6 Fast | $30/M | $150/M | 更快但**显著溢价**（注：具体倍数取决于 input/output token 的比例。纯看 input 为 2x，纯看 output 为 2x，加权混合倍数因使用模式而异） |
| Sonnet 4.6 | $3/M | $15/M | 性价比 |
| Haiku 4.5 | $0.80/M | $4/M | 最便宜 |

**Effort 系统的经济含义**：Opus 4.6 Pro 的默认 effort 档位（`low` / `medium` / `high`）与用户配额紧密绑定——rate-limited 的 Pro 用户如果每次都用 high effort，会很快打到限制。实际产品中的默认档位和配额关系由运行时 settings 决定（详见 Part 3 第 9 章「设置系统完全解析」），且可能随 Anthropic 定价策略调整。原则上 medium 档位是性能 / 成本 / 配额的常见平衡点。

---

## 7. omitClaudeMd 的 Token 经济

`omitClaudeMd` 标志让子 Agent 跳过 CLAUDE.md 的加载。看起来是小优化，实际效果惊人：

**计算**：
- 一个典型的 CLAUDE.md：2,000-5,000 token
- 一个复杂任务可能启动 5-10 个 Explore Agent
- 每个 Agent 平均 3-5 轮 API 调用
- 没有 omitClaudeMd：5,000 × 10 × 5 = 250,000 token 浪费（注：此估算假设每个 Agent 独立启动、不共享父请求的缓存前缀。如果 Agent 复用了缓存前缀，实际节省量会更小，因为 CLAUDE.md 内容可能已被缓存覆盖）
- 有 omitClaudeMd：0
- 按 Opus 4.6 价格：节省 $3.75/任务

源码中 `loadAgentsDir.ts` 附近注释提到的 omitClaudeMd 优化**较大规模**节省（每周数十亿到上百亿 token 量级，具体数字以 Anthropic 官方披露为准）说明 Agent 调用的量级是惊人的——Claude Code 的 Agent 子系统不是偶尔使用的功能，而是**核心工作路径**。

---

## 8. 竞品对比：Token 优化的不同哲学

不同产品对 Token 成本的态度，反映了截然不同的产品哲学。

### 8.1 定价模型对比

| 产品 | 定价模式 | 用户感知成本 | Token 优化动力 |
|------|---------|------------|--------------|
| **Claude Code** | API 按量计费（用户直付） | 完全透明，每次调用都有成本 | 极强——省下的每一个 token 直接省用户的钱 |
| **Cursor** | $20/月订阅 + 超额计费 | 部分透明（配额内无感，超额才痛） | 中等——超出配额才有优化动力 |
| **GitHub Copilot** | $10-19/月固定价 | 完全不透明 | 低（对用户）——微软内部优化，用户无感知 |
| **Aider** | 用户自带 API key | 完全透明 + 详细统计 | 极强——和 Claude Code 类似 |

### 8.2 缓存策略对比

**Claude Code** 的 Prompt Cache 是系统架构级的设计——消息排列顺序、`cache_control` 断点、CacheSafeParams 类型约束，都是围绕缓存命中率构建的。

**Cursor** 走了另一条路：不依赖单一的缓存机制，而是通过**模型分级**来控制成本。Tab 补全用体量更小、成本更低的专用模型（早期公开讨论提到过 GPT-3.5 级别的轻量模型，但 Cursor 后续迭代了自研/多厂商模型，具体模型代号以 Cursor 官方文档为准），复杂任务才调用 GPT-4 / Claude 级旗舰（贵但强）。这相当于"把便宜的活交给便宜的工人"。

**Aider** 的 repository map 是一种**输入压缩**策略：不把整个代码库塞进上下文，而是用 tree-sitter 生成代码结构摘要，只传必要的函数签名和类定义。这和 Claude Code 的上下文压缩目标一致，但实现路径不同——Aider 是事前压缩（进入上下文前就压缩），Claude Code 是事后压缩（上下文快满时才压缩）。

### 8.3 成本透明度对比

**Aider** 是成本透明度做得最好的产品——每次对话结束都显示 token 消耗、累计花费、缓存命中率。Claude Code 也提供了 token 统计（通过 OTel counter），但对普通用户的可见度不如 Aider 直观。

**Cursor** 和 **Copilot** 的成本对用户几乎不可见——订阅制把 token 成本抽象掉了。这降低了用户的决策负担，但也意味着用户无法做出"这个任务值不值得花这么多 token"的判断。

> 💡 **通俗理解**：定价模式的差异就像**吃饭的三种方式**——Claude Code / Aider 是按菜单单点（每道菜都知道价格，精打细算）；Cursor 是自助餐（固定价格随便吃，但有"高级菜品"额外收费）；Copilot 是公司食堂（每月扣工资，吃什么你不太操心）。哪种更好？取决于你是精打细算的"美食家"还是省心省力的"随便吃"派。

---

## 9. 设计取舍

### 优秀

1. **Prompt Cache 边界工程**把最稳定的内容（系统提示词）放在最前面——这不是偶然的，是对缓存机制的深刻理解
2. **CacheSafeParams 类型约束**在编译时防止缓存破坏——不是运行时检查，是类型系统保证
3. **投机执行的风险回报计算**是合理的——猜错只浪费几百 token，猜对节省几秒延迟
4. **`code_edit_tool.decision` Counter**直接追踪产品质量——不是技术指标，是用户价值指标
5. **omitClaudeMd 基于真实数据的优化**——不是理论估算，是从生产环境观测到的 token 消耗

### 代价

1. **缓存失效是静默的**——不报错，只是多花钱。很难在开发阶段发现缓存 miss
2. **Opus 4.6 Fast 的显著溢价**意味着"加速按钮"非常昂贵——用户可能不了解这个成本差异
3. **压缩和缓存的 trade-off**是根本性的——压缩打破缓存，不压缩打满 context。没有完美解决方案
4. **投机执行猜错时的 token 浪费**没有被追踪为独立指标——很难评估"猜错率"
5. **Token 预算的截断是硬截断**——不是"智能摘要"，超出部分直接砍掉，可能丢失关键信息

---

> **[图表预留 2.10-A]**：Token 四种水价对比图 — Input/Output/Cache Read/Cache Write 的成本关系
> **[图表预留 2.10-B]**：Prompt Cache 命中区域图 — 系统提示词/工具Schema/历史消息的缓存边界
> **[图表预留 2.10-C]**：压缩 vs 缓存的 trade-off 决策树 — 什么时候该压缩，什么时候不该