张晋涛👀TIL

Modular 竟然这么快卖给了高通 🤣

Codex 的这个，有个简单的检查的办法，不能只看文件的大小， 比如可以用一条 SQL 来查询， 看看 TRACE 的占比：

sqlite3 ~/.codex/logs_2.sqlite "SELECT level, COUNT(*) AS count, PRINTF('%5.1f%%', COUNT(*)*100.0/(SELECT COUNT(*) FROM logs)) AS pct FROM logs GROUP BY level ORDER BY count DESC"

FastAPI Cloud 开始公测了。。。 我天，我还以为穿越了。。。 不过实话说，这玩意也真不好说，说不定呢，万一就还发展起来了 https://fastapicloud.com/blog/fastapi-cloud-public-beta/

在没什么人在意的角落，PDM终于增加了workspace的支持。 很欣慰过了这么久以后，agent终于能比较好的完成这项工作，只需要一点guidance。 时代啊。 https://x.com/pdm_project/status/2069237745214771381?s=20

去 AI 味的设计 skill， 供大家品鉴 https://fxtwitter.com/i/status/2069226462624792785

Groq 活了！ https://fxtwitter.com/i/status/2069215383341486466

开源模型能力越强，这些推理厂商的市场就越大 https://fxtwitter.com/i/status/2069212437962740197

Codex 的一个 bug， 大家可以自己检查看看

这就是前两天 HN 热帖那个"Codex logging bug may write TBs to SSDs"的来源。 ─── OpenAI Codex Issue #17320 标题：Excessive SQLite WAL writes during streaming due to TRACE logs ignoring RUST_LOG 报告者：piotrkacala（2026-04-10 开启） 问题 Codex 在模型流式响应时，~/.codex/logs_2.sqlite-wal 的写入速度达到 5-16 MiB/s。持续这个速率会严重影响 SSD 寿命。 根因 IDE 扩展正确设置了 RUST_LOG=warn，但 SQLite 日志 sink 完全无视这个过滤级别。所有 TRACE 和 DEBUG 级别的内部事件（来自 tokio-tungstenite 和 hyper_util 的底层网络事件）都被无差别写入 SQLite。 一个 ~50 token 的短回复就能让日志表 MAX(id) 跳 5000 行。 预期行为 RUST_LOG=warn 应该全局生效，包括 SQLite 日志 sink。 临时方案 1. tmpfs 重定向：把 logs_2.sqlite 软链到 tmpfs（内存盘），牺牲重启后的日志保住 SSD 2. SQLite Trigger 拦截：

CREATE TRIGGER IF NOT EXISTS block_log_inserts 
BEFORE INSERT ON logs 
BEGIN 
  SELECT RAISE(IGNORE); 
END;

影响 如果你在用 Codex CLI 或 IDE 扩展，建议检查一下你的 ~/.codex/ 目录大小。长时间使用的话，这个 bug 可能已经写了几百 GB 甚至 TB 级的日志到你的 SSD。

哈哈哈哈哈 有趣

送给每位打算和正在参与开源社区的朋友们： 保持学习和探索的热情，与人为善，协作让我们共赢。 https://fxtwitter.com/i/status/2068572919685361747

全程都是在 tg bot 中操作的，让 GLM 5.2 和 Kimi-K2.7-Code 用 copilot cli 创建了它们各自的介绍页面。 简单来看，GLM 5.2 还是更有设计感一点的。 下面是预览（有效期一小时，我没认领） GLM: https://copilot-demo.accurate-leather.workers.dev/ Kimi: https://copilot-kimi.accurate-leather.workers.dev/