最贵的不是一次失败，而是无声地继续重试
一个内容团队把夜间批处理交给脚本，第二天才发现渠道早已异常。脚本没有先查状态，也没有设置重复错误的停止条件；失败请求持续增加，人工还要在第二天重新拼出发生了什么。
这是典型自动化事故推演，不代表真实客户或成交。它揭示的冲突很具体：自动化本来要减少重复劳动，却可能在状态、用量和失败边界不可见时，把一次小问题放大成整夜成本。
批量启动前先查当前状态
第一道门是看当前公开渠道状态，记录检查时间、线路和可见异常。状态页不能保证下一次请求一定成功，但能避免在已经明确异常的时段盲目开跑大批量。
接着为这次批量使用独立 Key 或独立项目标记，让请求、用量、错误和最终费用能被归因。网页登录状态和 API Key 是两套不同的访问机制，脚本实际使用的 endpoint 和凭据必须单独确认。
用同一条路径跑一条最小真实请求
不要用截图或模型列表代替验证。用批量计划中的同一 endpoint、模型、Key 和输出格式跑一条代表性请求，并按批量验收标准检查结果。记录实际模型、时间、状态、用量、耗时和是否能交付。
失败先分类再决定是否重试。临时超时可以允许有限重试；Key 无效、分组被拒、余额不足、接口不支持或请求格式错误，应先修配置。重复同一类不可重试错误，只会增加成本而不增加证据。
在第一次调用前写下用量与熔断边界
至少同时设置请求次数或总费用上限、失败率上限和人工恢复时间上限。按 Key 与项目保存用量记录，把错误类型、提示词修改、配置变更、结果审核和第二天排查时间都算进完成成本。
达到任一边界，或同一错误在状态没有变化时重复出现，就暂停任务。保留证据后再判断是修配置、切到已有记录的回退路径，还是推迟批量。暂停是可控结果，不是需要用更多重试掩盖的失败。
先证明一条真实请求，再决定是否扩大
https://APIToken.Company 可以作为多模型统一入口示例：查看模型广场和公开状态页，创建独立 Key，设定小批量边界，完成一条最小真实请求，再通过用量记录复盘。具体模型、价格、分组和渠道状态以站内当前页面为准。
本文不承诺永久稳定、最低价格或夜间批处理一定成功。更保守的最小行动是：先让当前状态可见，跑通一条真实请求，把失败和用量记下来；预算或熔断条件触发时立即停止。
事实边界与来源
本文没有外部事实案例，全文为明确标注的典型自动化事故推演；不代表真实客户、成交或批处理结果，也不暗示任何案例团队使用过 APIToken。