CLIProxyAPI 默认压缩一条 zstd 流吃 18 MB，修复还在 dev；上游承诺的重置落在北京今天下午三点前后
v8.0.45 默认开着响应压缩，一条 zstd 流约 18 MB、修复只进了 dev；同一小时里上游承诺了一次重置，落在北京 15 点到 16 点之间。
这个窗口从北京 10 点 09 分上一期发稿算起，到现在一个多小时。四件事，一件要等，三件今天就能动手。
一、重置落在北京 15 点到 16 点之间
10 点 42 分 53 秒，Tibo 在 X 上发了一条：「Day 23/ … Just kidding, today is a reset.」1
45 秒后他跟了一句：「Lands by midnight PST.」2
上一期正文发在北京 10 点 09 分，写的还是今天 UTC 内没有重置。33 分钟后，这句被他自己推翻了。
「midnight PST」要换算成本地时间。10 月 28 日太平洋时间仍在夏令时里（PDT，UTC-7），当地零点等于北京今天 15 点。
按字面 PST（UTC-8）算则是 16 点。窗口就是北京 15:00–16:00。
追踪站 codex-reset 收下了这两条，标记是未验证。
11 点 16 分那次抓取里，两条都是 scope=global、confidence=medium、effective_at 为空，reset_verification_status 为 pending3
同一站首页还留着旧口径：今天 UTC 内尚未重置，最近一次已验证的全局重置在 10 月 26 日 14 点 08 分（北京），距今约 45 小时。
累计 60 次全局重置、10 次预留。4
pending 的意思很具体：公告进了时间线，落没落地要等观测到。这个站的 FAQ 写着，全局重置分批推下去，Tibo 自己的帖常常还带着「正在扩散」。
还有两句要记住。公告里的 global 只覆盖这次选中的账号与限额，没被选中的账号额度照旧。
公告如果给的是一张 banked reset，那就只是发了一张券，不去兑换不会回流。4
到点之前照原样跑。别为验证花掉一张预留或买一次重置，FAQ 转述了 OpenAI 的说法：别拿它们去试第一张有没有生效4
自己确认只有两处：Codex CLI 的
/status 里那几行限流窗口，以及 Usage 页刷新后的剩余额度。二、v8.0.45 默认开着响应压缩，一条 zstd 流约占 18 MB
正在跑的 v8.0.45（10 月 27 日 23 点 27 分发布）里，下游响应压缩默认打开5
默认值写在代码里：配置整段省略时判断仍返回真。样例把
enabled 写成 true，旁边注着默认6这个功能从 v8.0.44 起。v8.0.43 及更早的标签里没有
internal/api/response_compression.go 这个文件7代价在写法上。每条被压缩的响应都现建一个编码器，zstd 走默认参数，8 MiB 窗口加缓冲约 18 MB8
SSE 也算在内。代码把
text/event-stream 单独摘出来，跳过最小字节数检查，编码器从第一个字节一直拿到流结束。乘一下就知道量级：1000 条并发 zstd 流按每条 18 MB 算，约 18 GB 常驻；gzip 那条路每流约 1 MB。
触发条件很松。客户端在
Accept-Encoding 里写 zstd 就够，协商时 zstd 排在 gzip 前面，同权重直接选 zstd。
第 299 行把事件流单独判出来，第 314 行在每条响应里现建一个 zstd 编码器；18 MB 乘以并发数就是从这两处来的。
修复已经在 dev。PR #7022 今天 10 点 31 分合入，合并提交
f6ee1e64，3 文件 +231/−119v8.0.45、main、tag 三个引用此刻仍全指向
ad8bdd3f，这一笔哪一版都还没带10改法是池化编码器，并把 zstd 窗口降到 1 MiB。
作者给的实测：500 个事件的整条 SSE 流，堆占用从 17.9 MiB 降到约 208 KiB，压缩后的字节数一字不差9
dev 分支同一文件第 171–200 行。第 181 行三个参数一起生效：并发 1、窗口 1 MiB、降低内存模式；第 176–178 行的注释自己写着默认编码器「每条流约 18 MB」。
今天有三条路，代价各不相同：
- 关掉：配置里把
server→response-compression→enabled设为 false。中间件每个请求读一次当前配置，热重载后生效，代价是出网字节变大。 - 只留 gzip：在反代层把
Accept-Encoding里的 zstd 删掉，每流约 1 MB，压缩率差一点。 - 不动：按每条 zstd 流 18 MB 预留内存，或者直接压住并发数。
自查一条命令：
curl -s -o /dev/null -D - -H 'Accept-Encoding: zstd, gzip' https://你的中转/v1/models | grep -i content-encoding。回 zstd 就说明这条路在你这里命中着。三、disable-cooling 开着时，被摘掉的模型会每秒重试一次
v8.0.45 里，模型不存在这类错误走
isModelSupportResultError 分支。正常情况拿到 12 小时冷却，或者按上游给的 retry-after 等11
下一轮选号，同一张坏凭证立刻又可选。PR 作者的描述是每秒一次请求。
第 1052 行按模型支持类错误分流，第 1054 行在 disable-cooling 时把冷却清成零，第 1058 行才是常规的 12 小时。第 1256 行随后把这张凭证标回可用。
触发场景不罕见：某个模型在上游被摘掉，本机映射还留着，客户端仍在请求，就变成每秒一次打同一张凭证。
PR #7019 正在改这一处，要求 12 小时冷却对
model_not_found 无条件生效。它今天 10 点 09 分补了第 5 笔提交
bb4c1d77。现在 4 文件 +510/−10，可合，基分支 dev，仍未合13今天能做两件事。
disable-cooling 只在确认所有失败都是瞬时的时候开。有模型被上游摘掉，先从账号映射与分组白名单里删掉，别让请求进来。
四、Claude 缓存写入的两档，现在只报一个总量
v8.0.45 解析 Claude 用量只读三处：缓存读取
cache_read_input_tokens、缓存写入总量 cache_creation_input_tokens、输出 output_tokens145 分钟与 1 小时两档的明细在这里就没了。整包搜
ephemeral_5m_input_tokens 与 ephemeral_1h_input_tokens，一处也没有。Redis 那头的数据结构也只有
cache_creation_tokens 一个总量。15
第 1226–1228 行就是全部输入：缓存读取、缓存写入总量、输出。上游另给的两档写入明细没有落点，后面几行只在算思考 token。
钱上的差要算清。官方 prompt caching 文档给的倍率是：5 分钟写入按基础输入价 1.25 倍，1 小时按 2 倍16
全按 5 分钟价结，1 小时的占比越多，少收得越多；全是 1 小时写入时，少收 37.5%。
PR #7061 今天 10 点 30 分新开，6 文件 +161/−0，可合，基分支 dev。
它把明细透出成可选字段
tokens.cache_creation，聚合那份保留17它还定了坏情况的兜底：没标 TTL 的写入按 5 分钟算，与 new-api 的做法一致17
在它合进去之前，账上把 Claude 的 1 小时缓存写入按 2 倍单独估一次。
五、窗口内其他读数
四个仓库这一小时都没有发版。
| 仓库 | 当前版本 | 发布时间（北京） | 本窗口发版 |
|---|---|---|---|
| CLIProxyAPI | v8.0.45 | 10-27 23:27 | 无 5 |
| sub2api | v0.2.18 | 10-23 15:44 | 无 18 |
| codex-proxy | v2.1.21 | 10-28 04:33 | 无 19 |
| codex2api | v3.1.2 | 10-28 04:39 | 无 20 |
三家状态页都干净。OpenAI 的 25 个组件全在运行21。
Claude 最近一条事故是昨夜的 Sonnet 5.5，北京 23 点 50 分恢复22。
GCP 那条 europe-west2 的事故在 10-20 就结束了，终报在北京 10-27 23:13 发出，10-28 08:38 又编辑过一次23
社区两条，都是用户自述、都没有官方回复。
一条是 Pro 用户说「Selected model is at capacity」已经持续两周，今天 11 点 17 分（北京）发帖，1 帖 1 浏览24
另一条是 Antigravity 里 Gemini 4 Argon 的计费。
一位用户用本地 RPC 与会话日志逐步核验，称每百万 token 扣 6 美元输入、30 美元输出，是宣传发布价的 3 倍，扣减来自共享的 5 小时额度池。1 帖 5 浏览25
数字先当信号看。跑 Antigravity 账号的，可以按 3 倍消耗估一下当前额度还能撑多久。
六、今天按这个顺序处理
- 记下到点时间：北京 15:00–16:00。到点后用
/status或 Usage 页自己确认，确认前照原样跑。 - 查
server.response-compression.enabled。并发流多、内存吃紧的，关掉或在反代层剥掉 zstd。 - 查
routing.cooldown的disable-cooling。开着的，把已被上游摘掉的模型从映射与白名单里清出去。 - Claude 的 1 小时缓存写入按 2 倍单独估，别混进 5 分钟价结账。
References
- 1thsottiaux：Day 23 帖子
x.com
- 2
- 3codex-reset 数据接口
codex-reset.com
- 4codex-reset 首页
codex-reset.com
- 5CLIProxyAPI v8.0.45 发行页
github.com
- 6v8.0.45 config.example.yaml 第 40–42 行
github.com
- 7v8.0.44 的 response_compression.go
github.com
- 8
- 9CLIProxyAPI PR 7022
github.com
- 10CLIProxyAPI 仓库引用
github.com
- 11
- 12v8.0.45 conductor_cooldown.go 第 1256 行
github.com
- 13CLIProxyAPI PR 7019
github.com
- 14
- 15v8.0.45 redisqueue/plugin.go 第 228–237 行
github.com
- 16Claude 平台文档：prompt caching
platform.claude.com
- 17CLIProxyAPI PR 7061
github.com
- 18sub2api v0.2.18 发行页\
github.com
- 19codex-proxy v2.1.21 发行页\
github.com
- 20codex2api v3.1.2 发行页\
github.com
- 21OpenAI 状态页
status.openai.com
- 22Anthropic 状态页
status.anthropic.com
- 23GCP 事件 Xs2XTHzAVC9YnafnPyzj
status.cloud.google.com
- 24Codex 分区：Pro 用户持续遇到容量拒绝
community.openai.com
- 25Antigravity 分区：Gemini 4 Argon 计费核验
discuss.ai.google.dev
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.