opencode 免费额度收紧观察：触发变频繁、恢复时机在变，规则却没有公开口径

最近不少人发现 opencode 免费模型的额度更容易用完了。我核对了官方数据和自己的使用记录，情况如下：

核心发现

1. 免费额度确实在收紧，而且限流触发频繁。我的账号 10 月 28、29 日连续两天额度用完。
2. 可用恢复的时长不固定：被限后多久能继续用，我自己用下来观察到 24h、12h，还有一次看起来像是 36h——从当日首次触发限流的时刻起算，不是固定的某个时长。
3. 官网统计与本地记录对不上，每日上限的重置疑似按 UTC 时间：官网的请求数和本地成功调用记录对不上号。

注意：第 2 条（可用恢复）和第 3 条（每日上限重置）是两回事——前者说“被限后什么时候能继续用”（从首次触发限流起算 + N 小时），后者说“每天能用多少、上限在 UTC 0 点重置”。社区 issue 的 retry-after 指向 UTC 零点说的是上限重置时间，不是可用恢复时间。

以下是我逐条核对的结果

社区反馈：GitHub 官方仓库近两周 429 相关 issue 80 条、免费档位相关 179 条。典型如 #59847——新版 deepseek 免费 1-2 条消息就触发上限；#59027——同一账号 v2.1.4 被挡、换回 v1.19.4 正常，限流判定不一致。

我碰到的限流情况：28 日官网用量统计显示 deepseek 407 requests、29 日显示 deepseek 1 + glm-5.3 171，以下是触发限流后截的图：

本地记录：28 日前主要用 deepseek，29 日起改用 glm，想验证限流是不是和具体模型有关：

每日上限重置与可用恢复是两回事：按我的观察，免费池每天有一个额度上限，这个上限在 UTC 0 点重置（社区 issue #59027 里 retry-after 注释指向“→ 00:00 UTC“，对得上）。但被限后什么时候能继续用（可用恢复）是另一套机制——从当日首次触发限流的时刻起算 + N 小时，不是等到 UTC 0 点上限重置。我自己用下来，这个 N 观察到 24h、12h，还有一次看起来像是 36h，不固定。

官网统计和本地对不上：28 日官网 407 requests，本地成功调用 183 次。比较合理的解释是我当时是半夜在用，官网的统计把 27 号深夜的部分请求也计入了 28 号——也就是官网的日期切分和我本地的时区切法不一样。