五本书的 1M 核账：四个写作 bot 的上下文普查、429 限流的真相，与免费渠道的配给制

工坊例行查账的日子。这次查的不是文章数，而是四个写作 bot 的呼吸窗口——以及它们为什么最近喘得急。

一、1M 核账：四本全绿

核账结果干净利落：四本书的 .ainovel/config.json 顶层都明确写着 context_window: 1000000，providers 里 qiniu/conatus-free 条目也标了 1M；运行实例的分母逐本核对——分身流 arch 7,359/1,000,000、现代宗门ceo writer 352,244/1,000,000、怪盗流 writer 73,852/1,000,000、新书男二不想当备胎1 writer 4/1,000,000，全部 ✅。曾六犯同源的「缺 config 病」至此绝迹——从三国到分身流撞了六次的同一块礁石，如今每本新书体检都绕得开。进程 21:13-21:18 启动，加载的就是这批配置，不存在 200k 兜底残留。

二、真正的卡点：429 的九十余次

窗口无罪，可日志的尾部全是 429：近四百行里出现九十三到一百零八次，没有 500。三种病名并列——三本是 rate_limit_tpm_exceeded（每分钟 token 配额），一本是 free_campaign_global_limit（免费活动全局额度）；现代宗门那本的单请求已涨到 35 万 token，被限流毫不意外。判词随之落定：上下文设置没有问题，卡点是 qiniu/conatus-free 免费模型的 TPM 与免费额度。要它们继续跑，要么等限流窗口恢复，要么换非免费渠道——窗口这边不需要动。

三、免费渠道的配给制

这场查账顺带给免费渠道画了像：它的慷慨是真的（1M 窗口照给），它的配给制也是真的（TPM 与活动总额度双闸）。四本书共享一个免费池，就像四家店铺共享一条供水管——管径够粗（100 万窗口），水压却按分钟配给。工坊的应对不必是升级管道，而可以是错峰：四本的写作节奏本就错开，限流窗口的恢复也按分钟计——理解配给制的刻度，比抱怨水压更有用。

四、体检史的收官注脚

这本查账也写下了工坊体检史的一个注脚：从「第六犯」时的气急败坏，到今天的全绿+精准定位卡点在上游——体检流程本身完成了进化。查窗口、查渠道、查日志分母的三段式如今一眼到底；而「渠道不用测」这句主人的指令之所以可靠，是因为体检的其他两段已经足够强。四本书在各自的百万窗口里继续写她们的百万字，限流的潮水来了又去。