Token、上下文与定价
API 上的成本和限制都以 token（约为四分之三个单词）来衡量。有三件事要做对。
1. 正确地计算 token
不要靠猜，也 不要用另一个模型的分词器（例如 tiktoken）——token 数因模型家族而异。使用 Anthropic 的 token 计数 端点/SDK 辅助方法，在发送请求前测量它。粗略的规划法则：约 750 个单词 ≈ 约 1,000 个 token。
2. max_tokens ≠ 上下文窗口
max_tokens限制 回复 的长度。如果输出被截断，就调高它。- 上下文窗口 是输入 + 输出的总预算。大体量的输入会给输出留下更少空间。
把 max_tokens 设为任务所需的大小——过低会截断；无谓地调高并不会花更多钱（你只为生成的 token 付费），但可能让回复啰嗦。
3. 估算成本
你按 输入 token + 输出 token 计费，费率因模型而异（Opus > Sonnet > Haiku）。一个快速估算：
cost ≈ (input_tokens × input_rate) + (output_tokens × output_rate)
从 官方定价页面 获取当前费率——我们在这里有意不硬编码它们。
削减成本（而不损失质量）
- 为模型选对规格 — 从 Sonnet 开始；把 Opus 留给困难的部分（选择模型）。
- 提示词缓存 — 在多次调用间复用稳定的提示词前缀。
- 裁剪输入 — 只发送真正重要的上下文（这也是 RAG 发挥作用之处）。
- 在延迟无关紧要时对离线工作进行 批处理。
更多策略见 成本与延迟的权衡。