request-log 关着仍每天落盘约 17 GB；47 MB 的图被截成 20 MB、账单照算
关掉的日志仍每天往盘上写约 17 GB；超过二十兆的图片被截断后返回 200、账照算；Kimi 月配额探一次就从面板上消失。四条今天上午开出的单，都给了版本、代码位置、一分钟判定和今天能做的动作。
四个仓库这一小时零新版本，主干也没动。今天上午的窗口里开出四条单，指向同一类事：默认值或上限生效的时候不出声。
代价最大的一条在 CLIProxyAPI。
request-log 关着，每个超过 1 MiB 的请求体仍然先写到磁盘上，请求成功之后再删掉。sub2api 那边，超过二十兆的图片上传先被截断再送上游。请求照样返回 200，账照算。
关掉的日志仍把请求体写到盘上
报障人在自己的机器上数了 120 秒：25 个落盘目录来了又走，写入速度约 0.2 MB/s，按天算 17 GB 左右。
这些请求全部成功，
request-log 一直是关的。1这个设计原本为错误日志服务。请求体太大存不进内存，就先落盘；出错时再把文件内容取出来拼进错误日志。1
internal/api/middleware/request_logging.go 第 104–134 行：第 106 行的早退条件里只有 loggerEnabled 或 bodyCaptured 为真才跳过，第 117 行在日志关闭的情况下照样建了 request-body 的落盘源。请求收尾时
response_writer 会 defer 一次清理，目录随即消失。6 代价落在写入那一段：每次成功请求都实实在在写了一次盘，文件只是活得短。multipart/form-data 不走这一路。2 走这一路的是 agentic 客户端那种一两兆的 JSON 请求体，长上下文时几乎每个请求都够格。一分钟确认：在部署目录下数一遍
ls logs | grep -c request-log-parts，再跑一次 du -sh logs。数字跟着请求量一起长，就说明这台机器也在付这笔钱。今天能做的只有把日志目录挂到内存盘。报障人给的写法是
--tmpfs /CLIProxyAPI/logs:rw,size=512m；配置目录挂在 /CLIProxyAPI/conf 时，实际目录是 /CLIProxyAPI/conf/logs。1他量到的效果是宿主盘上新增目录从每分钟 8 个降到 0，代价是容器重启时错误日志一起丢。
报障人提议加一个
observability.logs.error-log-request-body 开关，默认保持现状，目前还没有对应的 PR。1WebSocket 那条路是另一件事，另有一张单：#6960 想把长连接上的延后落盘整个跳过，10-24 开出，仍未合并。7
二十兆以上的图片被截断，账单照算
sub2api 的图片编辑接口在 OAuth 账号上有一个二十兆的软顶。报障人拿 47,486,671 字节的 JPEG 打
POST /v1/images/edits，回来的是 200 和一张编辑后的图。8上游实际只收到前 20 MB，被编辑的是一张只剩上半截的图。
同一个接口换成 23,530,018 字节的 PNG，回来的是 400
invalid_image_file。截断之后 PNG 不再是合法图片，上游会拒；JPEG 截断后还能解，于是静默走完。上限本身是个常量，
openAIImageMaxUploadPartSize 等于 20 MiB。9问题出在读的那一行：
io.ReadAll(io.LimitReader(part, openAIImageMaxUploadPartSize)) 之后只判 err，没有再判这一 part 是否被截断。10
backend/internal/service/openai_images.go 第 350–362 行：第 355 行用 20 MB 的 LimitReader 读完一个 part，第 357 行只检查读取错误，part 是否还有剩余字节在这里没有判定。同一个请求落到 API key 账号上时走的是原样转发，
io.Copy 没有上限，所以能成。13 结果取决于这个请求被哪种账号接走。一分钟判定：查一下最近有没有超过二十兆的编辑请求，以及那批请求是不是走了 OAuth 账号。补丁给路由日志加了
upload_parts=[image/png:23530018] 这一行；不带补丁的版本里看不到每张图多大。8今天能做的：把单图压到二十兆以下；或者把大图请求固定指到 API key 账号；或者按 OpenAI 文档的 50 MB 上限自己改常量重编译。8
补丁是 #8348，四个文件 +80/−4，mergeable clean，今天北京 11:21 开出，还没有人评审。8
Kimi 月配额：探一次，月行就没了
Kimi Coding Plan 的
/usages 回来的是 usages.limit_5h、limit_7d、limit_month_total、limit_month_code 四档，每档带 used_ratio 与 reset_time。14
backend/internal/service/cn_provider_quota_service.go 第 380–412 行：函数注释只列 limits[].detail 与 usage 两路；usages 下面的四个新字段在这份实现里没有读点。新形状进来时这两路都取不到值，探测只写回一个
kimi_usage_updated_at 时间戳。16库里的旧月读数不会跟着消失，写回走的是 JSONB 合并。17 刚探完那一刻面板上月行不见了；重新打开账号页，它又带着探测前的旧数字回来。
补丁 #8347 把新形状补齐，并把 Kimi 加进那个函数。14 七个文件 +191/−41，base 是 main，open、mergeable unstable；贡献者 fork 上的 CI 与安全扫描全绿，上游 CI 还在等维护者批准。
修复落地前，月配额直接看上游那个接口：
GET https://api.kimi.com/coding/v1/usages。面板上的月行只能当历史值读。同一窗口的另两条
#6992 说的是 Anthropic 协议的
message_start.usage。这一路上它由 CLIProxyAPI 自己算：上游 Codex 的 response.created 不带用量，转换器先写 input_tokens: 0，随后 TranslateStreamWithClaudeInputTokens 用 O200kBase 分词器把原始请求数一遍填进去。2021
internal/runtime/executor/helps/claude_input_tokens.go 第 328–352 行：第 333 行认出 message_start，第 338 行取本地估算值，第 346 行把它写回 message.usage.input_tokens。这段估算里也没有
cache_read_input_tokens 与 cache_creation_input_tokens，中途看就是 0% 命中。影响面按代码走是全部执行器：凡把 Claude 格式发给客户端的路径都套了这层估算。22 账不受影响，末了的
message_delta 与非流式 body 都是真值。#6994 是内容丢失。Codex 的
commentary 消息被翻成无签名的 thinking 块回给客户端，下一轮再送回来时整块被丢掉。23 报障人在 v8.0.43 上复现，映射由 376015c 引入，从 v8.0.41 起就有。版本与上游
四仓本窗口零新版本：CLIProxyAPI v8.0.43（北京 10-25 23:37）、sub2api v0.2.18（10-23 15:44）、codex-proxy v2.1.20（10-23 03:56）、codex2api v3.1.1（10-17 05:42）。24252627
主干：CLIProxyAPI 的 v8.0.43 标签指着 main 头 3078035，dev 另外停在 10-26 03:25；sub2api main 停在 10-25 21:48；codex2api main 停在 10-26 00:39；codex-proxy dev 停在 10-23 03:54。
三家上游全绿。OpenAI 全部组件 operational，最近一条事件 10-23 已恢复；Claude 无进行中事件；Google Cloud 的八条里最新一次更新停在 10-22，还是 europe-west2 那次。282930
Codex 今天 UTC 还没重置；最近一次已验证的全局重置在 22 小时前（北京 10-25 14:10），官方信号还停在 10-22 那条。31
还没闭合
#6993 只有提议，没有 PR；#8348 与 #8347 都还没人评审；#6992 与 #6994 零评论。
CLIProxyAPI 这一侧，
request_logging.go 在 dev 与 v8.0.43 上逐字节相同，message_start 那处估算也一样；sub2api 的 main 头上，二十兆常量与只认老形状的解析函数都还在。下一个 tag 带不带这些，现在没人说。References
- 1CLIProxyAPI issue #6993
github.com
- 2v8.0.43 request_logging.go 第 104–134 行
github.com
- 3v8.0.43 request_logging.go 第 21–26 行
github.com
- 4v8.0.43 request_logging.go 第 298–313 行
github.com
- 5
- 6v8.0.43 response_writer.go 第 267–276 行
github.com
- 7CLIProxyAPI PR #6960
github.com
- 8sub2api PR #8348
github.com
- 9v0.2.18 openai_images.go 第 40–44 行
github.com
- 10v0.2.18 openai_images.go 第 350–362 行
github.com
- 11
- 12
- 13v0.2.18 openai_images.go 第 891–935 行
github.com
- 14sub2api PR #8347
github.com
- 15
- 16
- 17v0.2.18 account_repo.go 第 2733–2745 行
github.com
- 18
- 19
- 20CLIProxyAPI issue #6992
github.com
- 21
- 22
- 23CLIProxyAPI issue #6994
github.com
- 24CLIProxyAPI v8.0.43 发行页
github.com
- 25sub2api 发行记录
github.com
- 26codex-proxy 发行记录
github.com
- 27codex2api 发行记录
github.com
- 28OpenAI 状态
status.openai.com
- 29Claude 状态
status.claude.com
- 30Google Cloud 事故列表
status.cloud.google.com
- 31Codex 重置追踪接口
codex-reset.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.