Claude API 成本优化：批处理、缓存与长上下文如何组合

先按任务约束分流

同样是处理一千份材料，用户等待中的问答与夜间分类不应走同一条路径。先写清最长可等待时间、质量门槛、敏感数据范围和失败重跑方式，再选择批处理、缓存、检索或较小模型。标题中的“1M”不是万能省钱开关：上下文容量描述可容纳的信息量，不代表把全部文档塞进去更准确或更便宜。

离线任务：修正批处理的请求结构

Message Batches 的每项需要 custom_id 和 params，不能把 Messages 参数列表直接当批请求。custom_id 是你与业务记录的对应键，不应含客户姓名或邮箱。下面创建两条演示分类请求；运行提交函数会产生真实任务及可能的费用，本文未执行。

def build_requests(items, model):
    ids = [row["id"] for row in items]
    if len(ids) != len(set(ids)):
        raise ValueError("duplicate_custom_id")
    return [{"custom_id": row["id"], "params": {
        "model": model, "max_tokens": 80,
        "system": "将工单分类为物流、退款、技术或其他。只输出标签。",
        "messages": [{"role": "user", "content": row["text"]}]
    }} for row in items]

def submit(client, model):
    requests = build_requests([
        {"id":"ticket-001", "text":"包裹还没有发出"},
        {"id":"ticket-002", "text":"启动时提示配置缺失"}
    ], model)
    return client.messages.batches.create(requests=requests)

assert build_requests([{"id":"a","text":"演示"}], "MODEL_ID")[0]["custom_id"] == "a"

结果归并比提交更重要

保存 batch ID、输入快照版本和提交时间，后台查询状态到结束或业务期限到达。结果可能乱序，必须按 custom_id 归并，分别处理 succeeded、errored、canceled、expired；批次结束不等于全部成功。只重跑允许重试的失败项，并记录新旧任务关系，避免重复收费和重复入库。

官方文档列有批处理 token 折扣，但异步队列并不保证立即完成，也不取消自身的批次与处理限额。价格与支持能力按当前渠道核对，不把折扣套到所有额外工具费用。

重复长前缀：先证实缓存命中

把稳定的说明、工具定义或文档前缀与变化的用户问题分开，按提示缓存文档设置缓存。文档更改、前缀不同、未达到要求或过期都可能影响命中。缓存是复用输入处理，不是保存上一次最终答案，也不替你更新过期事实。

分别采集 input_tokens、cache_creation_input_tokens、cache_read_input_tokens 和 output_tokens；三种输入量需按各自计费规则计算。第一次写缓存与以后读取的成本不同，低复用任务未必划算。批处理与缓存组合也要验证命中，不能直接相乘得到承诺的节省比例。

长文档与实时会话的实际选择

例：每天审阅同一份产品规范下的五百条变更。若无需即时答复，可把规范作为稳定前缀，变更作为逐项输入，批处理后按 ID 校验；规范升级即更换版本并评估缓存。若问题只涉及一章，则先检索对应章节，避免每次读完整本。

实时聊天要保留当前目标、约束和相关证据；直接裁掉最早若干条消息可能破坏工具结果配对或丢失重要条件。先统计哪些历史真的有用，再做摘要与回归测试。较小模型或更短输出也必须通过质量门槛。

验收看每个成功任务的总成本

用同一批脱敏任务比较优化前后：正确结果数、人工返工数、重试次数、端到端时延和真实账单。下面的构造例仅通过离线语法与断言，尚未测试账号权限、批次执行或缓存命中；上线前还需小规模授权试验。