Token Budget — 200K 怎么分

200K 听起来很多，写两本《活着》够（中文小说 ≈ 12 万字）。但 production LLM 的 200K 永远不够用——5 层 context 抢同一池子，多召回少一轮历史，多挂工具少一段记忆。

200K 实际能用多少

JR omni-report 的 daily-jobs routine 跑到第 5 轮对话时：

# tested: 2026-04-26 · model: claude-sonnet-4-6 · max_context: 200K

Layer 1  System instruction              ~800 tok      (cached)
Layer 2  Tool definitions (6 tools)     ~1,100 tok     (cached)
Layer 3  History (5 轮对话 + scratchpad)  ~8,500 tok
Layer 4  Retrieved context              ~32,000 tok    (LinkedIn 30 jobs 全文)
Layer 5  User input                       ~120 tok
─────────────────────────────────────────────────────
                                       ~42,520 tok    (使用 21%)

Output budget (max_tokens)              ~4,096 tok
─────────────────────────────────────────────────────
Effective budget                       ~46,616 tok    (23%)

5 轮吃掉 23%。再跑 15 轮 history 翻 4 倍 + retrieval 30K，20 轮触顶。200K 不是「无限」是「轮次预算」。

每个 token 都不平等 — Pricing 决定 budget 策略

Anthropic 当前的 pricing 把 token 分四档（以 Claude Sonnet 4.6 相对比）：

system + tools 共 2000 token 不变，cache hit 后等于只占 200 token 预算。Anthropic 文档 明确说「caching can reduce costs by up to 90%」。Output 比 input 贵 5×，限制 max_tokens=4096 是直接砍成本。

5 个 budget 技术（按 ROI 排序）

1. Cache 固定层（ROI 最高）

system + tools 加 cache_control: {type: "ephemeral"}，5 分钟 TTL：

# tested: 2026-04-26 · anthropic@0.40.0
system=[
    {
        "type": "text",
        "text": SYSTEM_PROMPT,  # ~800 tok
        "cache_control": {"type": "ephemeral"}
    }
],
tools=[
    *[{**tool, "cache_control": {"type": "ephemeral"}}
      for tool in TOOL_DEFS]  # ~1100 tok
]

成本：首次 cache write +25%，之后 5 分钟内每次只算 10%。高频 workload（每分钟 ≥ 6 次）日省 60-90%。

约束：cache key 是 byte-exact match，改一个字符 cache 全部失效。

2. 摘要 history（ROI 次高）

History 最容易爆。做法：

• 最近 N 轮完整保留（5-10 轮）
• 更早的轮次用便宜模型（Haiku）压成摘要塞 system prompt 末尾，标 [历史摘要]

LangChain 的 ConversationSummaryBufferMemory 是这个封装。Mem0 / Letta 第 6 章详述。

约束：摘要有信息损失，精确数字/专有名词得保留原文或走 RAG 重新捞。

3. Lazy-load 工具

15 tool × 200 token = 3000 token 每次都吃，但 80% task 只用 2-3 个。

• Phase 1 给一个 meta tool「searchTools(query)」返回相关 tool 名
• Phase 2 决定调用时再把 schema 注入
• Claude Code 默认走这个模式，用 ToolSearch 按需加载

约束：需要 multi-turn flow，单次 API call 做不到。

4. Rerank retrieval（铺垫第 5 章）

Retrieval 是 token 最大头。bi-encoder 召回 50 段 → cross-encoder rerank 10 段 → LLM-as-judge 选 3 段。90% recall，token 从 25K 降到 1.5K。

5. Output budget cap

max_tokens=4096 vs 8192 看起来都没用满，但模型生成策略受 max_tokens 影响。给 8K 倾向 long-form；给 4K 自己压缩。

JR 经验：JSON 输出设 max_tokens=2048 比 8192 更容易拿到 valid JSON——长预算下模型絮叨混入解释文字破坏 JSON。

JR 真实案例：omni-report routine 的 budget 策略

omni-report 的 17 个 routine 跑在 Claude Code Remote，隐藏约束：stream idle timeout ≈ 10 分钟没输出会被切断。这迫使每个 routine 把大 task 拆成多 phase 强制 commit。JR AI Visibility Weekly：

Phase 0: 准备 + 读上游           (~30 sec, 5K tok)
Phase 1: 写骨架 + commit          (~1 min, 2K tok)
Phase 2: 4 batch × 5 query        (~6 min × 4, 30K tok)
  └─ 每 batch 完成 → Edit → commit + push
Phase 3: 仪表盘 + 洞察 + 行动清单  (~2 min, 10K tok)
Phase 4: Notion 全文同步           (~30 sec, 8K tok)

每 phase 输出 < 8K，合起来 60K+。一次 LLM call 做完触发 idle timeout——拆 phase 既是 budget 也是 reliability 策略。

Aggressive vs Generous — Trade-off

JR 内部规则：新应用先 generous，跑通 + 有 eval set + 跑过 100 真实 query 后再 aggressive。直接 aggressive 漏 context，eval 找不到根因。

一句话带走

200K context 不是预算，是 5 层抢同一池子的轮次容量。Token 成本不是均匀的——cache hit 1×、output 50×、cache write 12.5×。Production 应用的工程核心：让前 2 层（system + tools）走 cache、第 3 层（history）走摘要、第 4 层（retrieval）走 rerank。

---

引用来源

1. Anthropic. Pricing — input / output / cache 4 档计费.
2. Anthropic. Prompt caching documentation — 5 分钟 TTL ephemeral cache + 90% 成本节省说明.
3. Anthropic. Long context tips — 长 context 信息组织建议.
4. Anthropic. Models overview — context window 容量 + 模型对比.
5. LangChain. ConversationSummaryBufferMemory — 摘要 history 实现.

Production case: JR Academy omni-report routines — 「骨架 + 渐进填充 + 每段就 commit」的 phase 拆分模式，应对 stream idle timeout 的 budget 策略.