Message Batches API 为非紧急的大批量处理提供 50% 的成本节省。代价是：处理窗口最长 24 小时，没有延迟 SLA 保证。结果保留 29 天。
什么时候用 Batch
Batch： 非紧急的批量处理——每晚报告生成、每周文档分类、批量数据提取。延迟容忍度按小时算。
同步： 实时交互、多轮 tool calling 工作流、任何需要即时响应的场景。Batch 不支持多轮 tool calling——每个请求是一个单独的消息-响应对。
一个团队正确分类了 3 个工作流（实时聊天用同步，每晚提取 + 每周报告用 batch），在每月 $9,000 的账单中省了约 33%。
永远按 24 小时做预算
平均处理时间不固定（某数据集中 2-19 小时，30 次运行平均 6.2 小时）。但没有 SLA 保证。按满额的 24 小时上限做预算，不要按平均值。如果你的 SLA 要求 30 小时周转，24 小时的 batch 只留了 6 小时的故障恢复余量。
custom_id 是一切
Batch 结果以任意顺序返回。custom_id 是唯一可靠的关联机制。设计有意义的 ID：
batch-20260327-003_doc-INV-4521这让你能做到：结果到请求的匹配、选择性失败重试、审计可追溯——全靠一个 ID。
一句话总结： Batch API 在非紧急批量工作上省 50%，但最长需要 24 小时且不支持多轮 tool calling——根据延迟需求选择 API。