How do I keep coding agents from hitting rate limits overnight?

所谓让编程助手 overnight 不撞上限，是指在你睡觉的时间里，助手按你设好的节奏慢慢推进，而不是一股脑把请求全发出去、撞上限后集体停摆。撞上限的本质不是任务太多，而是请求在同一时间段里太密：重试、并行、长任务三者叠加，额度再多也扛不住。夜里没人盯着，节奏一旦失控，损失要到早晨才会被发现。本文先讲上限通常由什么触发，再讲怎么排节奏、怎么设熔断、怎么留早晨复查的余地，帮你在睡觉之前先把夜里的节奏定好。

限速通常由哪几种行为触发？

限速通常由四种行为触发，认清它们才能对症下药。第一是短时间内的请求密度过高，几个任务同时开火，瞬间冲过服务允许的速率。第二是单个任务的请求量过大，例如一次让助手读遍整个仓库、反复生成大段内容，单个任务就把额度吃掉大半。第三是失败后的无节制重试，某个接口一报错就立刻重发，重发又报错，几分钟内就能把剩余额度烧光。第四是并行数失控，任务数和助手数一起涨，总请求量远超你的预期。排查夜里停摆的原因时，先看日志里是哪一种行为占了大头，再决定是降并行、拆任务还是修重试，不要一上来就加额度。加额度只能推迟撞上限的时间，改不了节奏本身的问题。

具体步骤是怎样的？

第一步，睡觉之前先把夜里任务列成清单，按优先级排序，只把必须夜里跑的留下，能白天跑的不要塞进夜里。第二步，给任务定节奏：错峰启动、单任务设上限、两次请求之间留间隔，不要所有任务同一时刻开火。第三步，给失败设熔断：连续失败几次就停下来、记日志、等你早晨处理，而不是无限重试。第四步，给每个任务设好检查点和断点续跑能力，撞上限停下来后，早晨能从断点继续而不是从头重来。第五步，睡觉之前先跑一个极短的冒烟任务，确认节奏、熔断和断点续跑都管用，再放行整夜任务。第六步，早晨先看夜里日志再开新任务，确认夜里任务是正常完成、熔断停下还是撞上限停摆，三种状态的处理办法完全不同。步骤里最容易被跳过的是第五步和第六步，而恰恰是这两步在替夜里兜底。

夜里任务的节奏怎么排才合理？

夜里节奏的核心是错峰和分段，不要把夜里当成无限长的工作时间。错峰是指任务不要同时启动，而是按优先级依次启动，前一个进入稳定期再启动下一个。分段是指大任务拆成若干段，每段之间留出间隔，服务有喘息的时间，你早晨复查时也能按段定位问题。还有一个容易被忽略的点：夜里任务的总量要留余量，不要按额度上限排满，留出的余量是给重试和突发情况准备的，排满额度的计划只要出一次意外就全线停摆。节奏排好后写下来：哪个任务几点启动、每段大概多久、熔断条件是什么，早晨复查时对照这张表，立刻就能看出哪一段偏离了计划。

重试和熔断应该怎么设？

重试的原则是越失败越慢，而不是越失败越快。第一次失败后等一小会儿再试，第二次失败等更久，连续失败几次就彻底停下来，不要让重试本身变成新的请求洪峰。熔断要设两层：单任务层面的熔断，某个任务连续失败就停这个任务；全局层面的熔断，所有任务的失败总数超过阈值就停全部任务，防止一个坏任务拖垮整夜。熔断触发后一定要记日志：失败时间、失败原因、已经完成的进度，早晨处理时就靠这份日志定位问题。最忌讳的做法是重试不设上限、失败不记日志，早晨起来只看到一堆停摆的任务，却不知道从哪里开始查。重试策略写进任务配置里，不要只存在某个助手的默认行为里。

断点续跑为什么是夜里任务的前提？

没有断点续跑能力的任务，撞上限停摆就等于前功尽弃，早晨只能从头重来，夜里的时间全白费了。断点续跑是指任务按段保存进度，每完成一段就把结果和状态落盘，下次启动时从最后一个完成的段继续。实现办法不复杂：任务清单按段拆分、每段完成打勾、中间结果写文件而不是只存在内存里。检查断点续跑是否管用的办法是：故意中断一次任务，再启动，看它是不是从断点继续、而不是重做已完成的部分。夜里任务放行之前，这个中断测试必须通过，没通过的任务不要放进夜里清单。断点续跑还有一个附带好处：早晨复查时，已完成的部分一目了然，你只需要处理未完成的部分。

早晨复查应该先看什么？

早晨复查按固定顺序看三样东西，不要一上来就开新任务。先看夜里任务的状态清单：哪些正常完成、哪些熔断停下、哪些撞上限停摆，三种状态分开处理。正常完成的任务先抽查结果质量，确认不是“跑完了但结果不对”。熔断停下的任务看日志找失败原因，修好原因再续跑，不要直接重跑。撞上限停摆的任务先看是不是节奏问题，节奏没改就重跑只会再撞一次。复查完再决定今天的任务：夜里没跑完的任务优先续跑，而不是先开新任务堆上去。复查清单养成习惯后，夜里停摆就不再是惊吓，而是按流程处理的一件常规事项。

哪些任务根本不适合放夜里？

有些任务从一开始就不适合放夜里，再好的节奏也救不了。需要你中途做判断的任务不适合夜里，因为助手会在需要判断的地方卡住、空转烧额度。依赖外部服务状态的任务不适合夜里，外部服务夜里出问题时没人能及时处理。结果不可逆的任务不适合夜里，例如直接改生产数据、对外发布，夜里无人值守时出错的代价太大。还有一类任务：本身就不稳定、白天跑也经常失败，这类任务放夜里只会把失败复制到夜里。判断标准很简单：这个任务白天无人盯着能不能安全跑完，不能就不要放夜里，改成白天分段跑。

这篇教程有哪些局限？

本文只讲了夜里任务的通用节奏，没有针对任何一家具体服务写限速数值，因为各家服务的限速口径、计量方式和恢复规则差别很大，照搬某一家的数据到另一家没有意义。各家服务的限速规则也会随政策变化，动手时要以你所用服务的当前文档为准，本文的办法是帮你排节奏、不是替你查额度。另外，本文没有讨论团队共用额度时的分配规则，多人共用一份额度需要额外的配额管理和审批流程，那是另一套办法。涉及生产数据的夜里任务，建议先在测试环境里完整跑一夜，再决定要不要放行。

简而言之，怎样过夜才不撞上限？

过夜不撞上限的办法是清单先行、节奏错峰、熔断兜底、断点续跑、早晨复查：夜里任务按优先级列清单、错峰启动、分段推进、失败越等越久、连续失败就停、每段进度落盘、早晨按状态清单分开处理。额度留余量、重试设上限、并行数控制在你能复查的范围内。先在白天做一次中断测试，确认断点续跑管用，再放行整夜任务。夜里任务的目标不是跑得多，而是早晨起来时每一项都有明确状态，正常完成的能直接用、没跑完的能接着跑、失败的有日志可查。

来源与延伸阅读：FreeModel 关于页：它是什么、不是什么、FreeModel、Claude Code 官方文档、Cline 官方文档、实测免费网关对比、十四家网关公开模型清单实读。