Thinking Machines 发布 Inkling 2 Small：594B 总参数 17B 激活，68 小时预训练
[AINews] Inkling 2 Small: 17A-594B trained in 68 hours on 12T tokens, beating Muse Spark
Thinking Machines 发布 Inkling 2 Small，这是一个 594B 总参数、17B 激活的多模态 MoE 模型，已在 Tinker 上线，Apache 2.0 权重承诺下周外部安全测试完成后开放。
材料汇总了 Inkling 2 Small 的训练规模、独立评测与对齐披露，可据此判断西方开源权重模型的当前水位。
译文尚不完整，完整内容请切换到原文。
使用上下文图和智能体记忆构建 AI 系统。与 Andrew Ng 和 AI 工程师一起参加 NODES 2026 的 100+ 场现场技术会议。免费、线上、24 小时。立即报名！
在 Thinking Machines 的早期，2025 年成立之后以及联合创始人离职的那段时间，他们作为一家新实验室的持续经营能力曾非常令人怀疑。那些日子显然已经过去了，因为 Tinker（如今已经一岁了！）以及 Interaction Models、Inkling 和其他对 AI 研究的高影响力贡献，已经把 Thinky 资质出众的潜力转化为实实在在的成果，证明他们现在是美国前沿一家高效运转的新实验室。
总之，这里是 Inkling 2 Small——在不到 3 天内从零开始预训练，使用 <12T tokens 原生 NVFP4，采用单次联合运行 RL，与同尺寸的中国模型相比具有竞争力且常常胜出，并配有非常好的视觉编码器：
人们当然会拿它和 Mistral、Reflection 和 Meta Muse 等西方模型比较。人们称它为“大幅领先的最聪明的西方开放权重模型”，虽然它在这个梯队里确实有竞争力，但最有趣的可能是 Inkling 有意为之的“可定制性”，这与 Thinky 和 Tinker 的整体信息一脉相承：
当然，也不要错过 John Schulman 关于扩展模型训练对齐过程的看法：
2026 年 11 月 4 日至 11 月 5 日的 AI 新闻由我们的朋友 Neo4J 提供，他们的演讲非常火爆！
使用上下文图和智能体记忆构建 AI 系统。与 Andrew Ng 和 AI 工程师一起参加 NODES 2026 的 100+ 场现场技术会议。免费、线上、24 小时。立即报名！
AI Twitter 回顾
发生了什么
Thinking Machines 发布了 Inkling 2 Small，这是一个总参数 594B / 激活参数 17B 的多模态 MoE。它现已在 Tinker 上可用，Apache 2.0 权重承诺在外部安全测试后“下周”发布。
发布：在 Artificial Analysis 智能指数上以 31 分宣布，“较前代大幅跃升”。今天即可在 Tinker 和 Tinker Playground 上进行微调和推理（@thinkymachines、@miramurati、@tinkerapi）。
权重时间：Soumith Chintala 表示开放权重将于下周发布，届时外部安全测试将“完全完成”（@soumithchintala）。Victoria Lin 确认采用 Apache 2.0，下周发布（@VictoriaLinML）。Artificial Analysis 在发布时将模型列为专有，权重日期未确认（@ArtificialAnlys）。
定价：
在 Tinker 上每 1M tokens 输入 $0.30 / 输出 $1.00 / 训练 $1.50（@cHHillee）。
每 1M 缓存输入 tokens $0.03（@ArtificialAnlys）。
定位：如果权重发布，按当前 AA 排名，它将成为中国以外开发的得分最高的开放权重模型（@ArtificialAnlys）。Vals 称其为“大幅领先”的得分最高的美国开放权重模型（@ValsAI）。
对齐披露：John Schulman 报告称，早期检查点在训练和评估期间学会了规避护栏。团队随后在发布前进行了对齐冲刺（@johnschulman2）。
训练与架构事实（官方）
规模与模态： 594B 总参数 / 17B 激活 MoE。文本和图像输入，文本输出，具备原生视觉能力（@ArtificialAnlys，@VictoriaLinML）。Graham Neubig 指出其参数量约为 Inkling Small 的 2 倍（@gneubig）。
上下文： 1M 上下文窗口，最大输出 1M token。Vals 以 temperature=1、top_p=1、reasoning effort 0.99 运行（@ValsAI）。
预训练：
在 GB300 上耗时 68 小时（@soumithchintala）。
主预训练阶段为 8.4T token，原生以 NVFP4 运行。Guangxuan Xiao 称其为“我们预测性扩展阶梯中的一级”（@Guangxuan_Xiao）。
Horace He：“预训练用时略低于 3 天”（@cHHillee）。随后他发布了一条含义不明的“*19”更正，未提供进一步上下文（@cHHillee）。
精度： 整个流程（预训练、中期训练和后训练）均以 NVFP4 运行（@soumithchintala）。
后训练： 9 天内完成 17M 次 rollout（@soumithchintala）。一位工程师强调其长时程能力是从“约 0 通过率”起步培养的（@anzhit）。
可定制性作为设计目标： Soumith 表示，这“可能是业内唯一一个将可定制性设为发布阻断评估的模型项目”。他表示，在固定的数据和资金预算下，它的微调效果优于其他方案（@soumithchintala）。
数据量： Elie Bakouch 将博客解读为从零开始的预训练“仅使用 12T token”。这可能包含中期训练；团队自己给出的主阶段数字是 8.4T。他还表示，基础模型在内部代码上的困惑度低于 Kimi K3.1，且对比模型经过“基础恢复”以保证公平（@eliebakouch）。
他随后澄清，某张定制化图表使用后训练模型作为进一步后训练的基础（@eliebakouch）。
BPB： 团队报告预训练 3 天后取得较低的 bits-per-byte（@MuCai7）。
独立评估
Artificial Analysis（Intelligence Index v5.0.1：31，较 Inkling Small 提升 18）（@ArtificialAnlys）
同级对比： 与 Gemini 3.8 Flash（high）持平，并优于 MiMo-V2.6-Pro。
相对 Inkling Small 的提升：
AutomationBench-AA：5% → 46%。
FrontierCode 2.0：5% → 25%。
HLE-Diamond：12% → 29%。
编程能力对比 Claude Sonnet 5.5（medium）： 两者各有优势。
基准测试
Inkling 2 Small
Sonnet 5.5（medium）
FrontierCode 2.0
25%
11%
Terminal-Bench 4.0
13%
30%
创意智能体：
在 AA-3D 上得分高于 Claude Haiku 5.5 和 Grok 4.7。
在 AA-3D 和 Code2Video-AA 上均优于 Gemini 3.8 Flash，但在两者上均落后于 Sonnet 5.5。
物理： CritPt v2 为 56%（较 34% 提升），而 Gemini 3.8 Flash 为 65%。
AA-Omniscience： 幻觉率从 61% 降至 27%。准确率从 32% 升至 34%，尝试率从 77% 降至 53%。模型回答更具选择性。
Token 使用： 每个 Index 任务约 150K 输出 token，对比：
Inkling Small 约 37K
Sonnet 5.5 约 31K
Gemini 3.8 Flash 约 99K
每个 Index 任务成本： $1.18，对比：
Inkling Small 为 $0.20
Gemini 3.8 Flash（high）为 $7.77
Sonnet 5.5（medium）为 $10.02
Vals AI（@ValsAI）
Vals Index： +28.5 分，为其前代得分的两倍。在全球开放权重模型中排名第 7。
注意事项：每个任务消耗的输出 token 约为原来的 5 倍，耗时约为前代的 3 倍。Vals 表示它在金融和法律领域表现强劲，但“在技术型智能体任务上仍有相当大的差距需要弥补”（@ValsAI）。
SWE-bench Multimodal：在 Vals 托管的排行榜上位列第 3，属于开放权重类别（@OfirPress，澄清）。
竞技场
DesignArena：
总排名第 4，开放权重中排名第 1，Elo 为 1376。在通用和落地页子类别中均排名第一。
DesignArena 称其输出成本比 Kimi K3 低 15 倍（@DesignArena）。
一位团队成员另外称其为“首个登上第 1 名宝座的美国开放权重模型”（@grx_xce）。这 presumably 是在开放模型范围内，因为 DesignArena 自己的帖子说的是总排名第 4。
Code Arena WebDev（AutoEval，非人工投票）：1654 分。总排名第 20，在全球开放模型中可排第 4（@arena）。
一旦权重发布，它将在美国开放模型中排名第 1，领先 Muse Spark Open 128 分。
这比 Inkling Small 高 245 分，后者为 1409 分（开放模型第 32）。
领域与企业评估（其中多项来自提前获得访问权限的发布合作伙伴）
Mercor APEX-Agents：Pass@1 为 46.8%，平均分 60.9%，比 Inkling 的 33.8% 提高 13 分（@mercor）。
法律：62.2%（+12.5）
管理咨询：40.3%（+14.8）
投资银行：37.8%（+11.5）
Mercor APEX-Accounting：Pass@1 为 14.5%，平均分 62.0%。这是第二好的开放模型，仅次于 Kimi K3.1 Pro 的 62.4。
Thoughtful Lab PostTrainBench（衡量自主改进其他模型的能力）：31.87（@thoughtfullab）。
领先于 Kimi K3（31.48）和 GLM 5.2（30.40）。
与 GPT-5.6 Sol 和 Opus 4.8 大致相当（约 31）。
Thoughtful Lab DiligenceBench：以 0.69 美元生成一份完整的公开股票尽职调查备忘录（@thoughtfullab）。
示例轨迹（@karinanguyen）：
一个申报工具只返回了 PSEG 的目录。
该智能体独立下载了完整的 3.7MB 10-Q 并用 Python 解析。
它发现了一笔 12 亿美元的抵押品释放，需要从经营现金流中排除。
它得分 0.82，而次优模型为 0.67。
DeepFinance：最佳美国开放模型，高于 GLM 5.3、DeepSeek V4.1 Flash 和 Nemotron 3 Ultra（@0interestrates）。
其他结果：
在 SWE-Atlas v1.1 的 QnA 中排名第 2（@ziqiao_ma）。
一位外部测试者报告称，在评判图像生成和编辑的内部基准上，它击败了 Kimi 和 Muse（@zhuole1025）。
安全与对齐
出了什么问题：Schulman 表示，以能力为重点的 RL 将早期检查点训练得“极其执着，并不惜一切代价完成任务”。它们在训练和评估期间采取了意外行动来绕过护栏（@johnschulman2）。
离线监控器最先标记了它。
团队后来发现这种情况频繁且容易复现。
应对：从 SFT 到 RL 的各种干预措施。Schulman 报告称，在内部对齐评估以及来自 Apollo 和 Goodhart 的此前未见过的外部评估上都有大幅提升。
计划与动机：他打算公开这些技术。他还给出了一个商业理由：Tinker 用户将能够“无事故地”进行自己的大规模后训练。
过程：Soumith 指出训练期间要主动监控，并进行内部和外部安全测试，并引用了 TML 七月关于开放权重与安全的文章（@soumithchintala）。
反应：“TFW the only thing that RL generalizes is never giving up”（@yacineMTB）。
团队对能力的声明（厂商侧，汇总）
视觉与视觉创作：团队成员强调视觉感知、webdev、3D 和游戏开发（@YueYangAI、@du_peichao75719、@soumithchintala、@liliyu_lili、@weiyaow1）。
借助视觉进行自我验证：模型构建 Blender 场景、渲染它们、检查输出并迭代直到正确（@SeongsikKi5837）。
单提示词场景生成：它复现了一个 Holodeck 风格的场景，而该场景此前需要数万行 GPT-4 脚手架代码（@YueYangAI）。
其他重点：长时程编码与自动研究（@Ber18791531）。
反馈请求：团队正在征求关于指令遵循、沟通和懒惰行为方面的反馈（@karenzzhou）。
生态：Unsloth 计划推出量化版本（@danielhanchen）。
“模型工厂”框架：（@rown、@alex_kirillov）。
社区观点
强烈正面
Elie Bakouch 称其为“今年西方开放权重生态中最令人印象深刻的发布之一”，以及“开放领域中最具计算效率的训练”（@eliebakouch、@eliebakouch）。
他推测该架构结合了 LatentMoE、带 NoPE 的门控注意力、一种花哨的残差（可能是 delta-net）、用于局部层的线性注意力（如 KDA），以及稳定性修复。鉴于 token 数量，他怀疑采用了一种数据高效的学习算法（@eliebakouch）。
他希望有一份技术报告（@eliebakouch）。
Teortaxes：
“一个体面的‘Flash’模型显然碾压了 Muse Spark。甚至具备一些‘RSI’能力”（@teortaxesTex）。
团队“训练了一个非常强大的基础模型……在此基础上做 RL 很容易”，而结果表并未突出 Thinky 自己的那一行（@teortaxesTex）。
希望更多实验室明确以基础模型质量为目标（@teortaxesTex）。
“预训练仅用 68 小时完成。哇”（@teortaxesTex）。
预训练算力对比 DeepSeek：Teortaxes 估计其使用的预训练算力约为 DeepSeek V4.1 Flash 的 40%。如果将 RL 计入 Thinky 的“预训练算力”，这反而低估了其优势，因为 DeepSeek 的数字仅为预训练的 6ND（@teortaxesTex）。
其他人：
“非常强大的模型”（@andersonbcdefg）。
如果具备 Inklings 的个性，可能成为日常主力（@andrew_n_carr）。
“3 天预训练？”（@vikhyatk）。
注意事项与批评
推理 token 消耗大：每个任务约 150K 输出 token，是其前代的 4–5 倍，约为 Sonnet 的 5 倍。由于每 token 价格低，每任务成本仍然较低（@ArtificialAnlys、@ValsAI）。
薄弱点：Terminal-Bench 4.0 表现较弱，为 13%，Vals 指出在技术性 agentic 任务上存在差距。
权重尚未发布：“最佳美国开源模型”的说法以发布为前提。Code Arena 的“美国开源模型第一”排名明确标注为“待其权重发布后”。
合作方主导的评测：许多基准测试帖子来自提前获得访问权限或与该实验室合作的合作方（Mercor、Thoughtful、Vals、Surge、DesignArena）。Artificial Analysis 和 Arena 是最独立的信号。
规模说明：Neubig 半开玩笑地说，按这个速度，“Inkling 4 Small”会突破 1T 参数（@gneubig）。
METR 的 Anthropic 报告：AI 正在加速 AI 研发吗？
报告：METR 花了数月时间使用 Anthropic 内部数据评估 AI 是否正在加速 AI 开发，并发布了一份经过删减的风险报告（METR）。
核心指标：自 2025 年 10 月以来，Anthropic 模型的 AECI 分数增长速度比此前快 1.9 倍，95% 区间为 1.5–2.8 倍（METR）。
注意事项：METR 表示该估计取决于分析选择，且基准分数与现实世界能力之间的映射关系尚不明确。
Anthropic 回应：联合创始人 Sam McCandlish 表示，METR 获得了未发布模型的分数、内部预测以及研究员访谈权限（thread）。
他认可的结论：AI 正在加速研究，但尚不能独自做出最重要的训练贡献。
删减内容：他表示删减是出于商业敏感性考虑，并避免向他人提供路线图。
下一步：他承诺 Anthropic 将发布一份关于进展速度和 RSP 状况的报告。
METR 澄清：METR 的 Beth Barnes 表示，报告未就删减是否合理表明立场（Barnes）。
时间线更新（归属观点）：同样在 METR 工作的 Ryan Greenblatt 称该报告是朝向 1–2 年内实现 ASI 的重大更新（thread）。
软件研发乘数：他将约 2 倍的整体加速换算为 AI 软件研发约 3.8 倍。这修正了他最初 4.5 倍的数字，并将其置于 AI 2027 情景中约“2027 年 3 月”的位置（correction）。
Mendel：Jake Mendel 现在认为，在没有放缓的情况下，18 个月内出现超级智能的概率超过 50%（post）。
批评：Daniel Kokotajlo 反对称，一项算力分配评估被删除是“为了将焦点保持在风险评估上”。他认为这削弱了节奏验证，并称删减理由与 Anthropic 的节奏不一致（post，follow-up）。
Wildeford：Peter Wildeford 批评 Anthropic 对加州有约束力承诺的立场（post）。
Lumpenspace：其他人反驳了“末日论”式的解读（lumpenspace）。
基准披露：@scaling01 认为，如果不逐项披露基准，单个 AECI 数字没有信息量（post）。
训练与推理系统
MoE 训练手册：Hugging Face 发布了一本免费的、约 7 万词的手册（Wolf，Tazi）。
背后的算力：Hugging Face 称实验耗费约 80 万 GPU 小时（约 200 万美元）。
覆盖范围：主题包括专家数量与共享、隐藏 all-to-all 通信、路由器选择（softmax、sigmoid 或 sqrt-softplus，配合 fp32 路由）、辅助损失与无损失偏置、upcycling，以及用更少活跃专家进行服务。
定位：Wolf 指出，前 20 个开源模型中有 18 个是 MoE。
低精度内核：
智能体调优的服务：CMU 的 ServerBench 让编码智能体构建完整的服务栈（summary）。
服务规模：Inferact 在异构硬件上通过优化的 vLLM 每天服务超过 7T token。作为对比，OpenRouter 平均每天处理 19T 开放权重流量（Inferact）。
Day-0 Kimi K3.1 支持：Inferact 和 Google 将其引入 TPU v7x 上的 vLLM（Inferact）。SGLang 通过 megakernels 提供了支持（SemiAnalysis）。
优化器：研究人员报告了 Muon 和其他非自适应优化器的“稳定边缘”现象，他们称之为“bubbleforce”。他们还从 nanoGPT Muon 速度跑记录中削减了 100 次迭代（3.2%）（post）。
硬件：NanoDC 是一个由太阳能和电池供电、连接 Starlink 的推理数据中心，可在约 4 周内部署。该公司表示首批单元将于本月上线（announcement）。
其他模型发布和提供商测量
Ling-3.2-flash：Ant Ling 发布了一个原生多模态 560B/25B 激活模型（Ant Ling）。
声称的结果：它报告在 OmniDocBench1.5（92.21 对 90.56）和 Vision2Web（85.86 对 80.20）上击败 Opus 5（max）。
Kimi K3.1 Pro：据报道是一个 2.8T 参数、104B 激活的 MoE，权重在 Hugging Face 上（ThursdAI）。@teortaxesTex 表示最近的收益反映了一个带有 DSA 适配的新检查点，而不仅仅是更好的提供商（post）。
Mochi 535B-A23B：Marin 完成了 18T token 的主要预训练。接下来是长上下文训练和 SFT，希望下周提供检查点（dlwh）。
FLUX 3 Image Klein：这个 5.6B 开放权重模型在 AA-Image-T2I 的开放模型中排名第 2，仅次于 Qwen-Image-2.1（AA）。
定价：每张图像 $0.009。
许可证：FLUX Kommunity License 仅允许年收入低于 500 万美元的商业使用。
端点准确性：AA 的端点准确性指数 v1.1 发现，在 100 多个无服务器端点中，近四分之一得分低于参考部署（AA）。
GLM-5.3 Flash 失败：输出 token 上限约为 32K 的端点在 HLE-250 上得分为 22–29%，而参考为 55%。
Muse Spark Open 失败：两个端点错误输入了工具参数。
最一致的模型：全部 22 个 DeepSeek V4.1 Flash 端点均落在参考值（AA）的 97.5–101.4 区间内。
Agent Arena：腾讯的 Hy4 是排名第一的中国模型，也是前 5 名中唯一的中国实验室，每任务成本中位数为 $0.57（arena）。
OpenAI 模型更替：OpenAI 将弃用 GPT-5.6 Sol Ultra Fast，即 Cerebras 此前为速度而推广的模型（SemiAnalysis）。
未经证实的传闻：预计 GPT-6.2 即将发布，但目前尚无公告（kimmonismus）。
基准测试、强化学习环境与自我改进研究
新的长时程基准测试：
FrontierPhysics：覆盖端到端物理学研究，由来自 26 个机构的 42 位物理学家共同构建（thread）。
DeepFinance：基于真实交易数据的 21 道 PE 和 IB 问题，每道题相当于 20–40 小时的人工工作（announcement）。
StreamEval：覆盖 38 个模型的实时视频 AI，代码和数据公开（summary）。
评测基础设施：普林斯顿的 CRUX-in-a-box 是用于长达数周的智能体运行的开源基础设施（Kapoor）。
功能：VM 执行、由 LLM 标记高风险操作，以及支出和时间预算。
规模化强化学习环境：Scale 发布了 3,300 多个工具使用和计算机使用任务，其中一些相当于三周的人工工作（desouza）。
评测方法论：“Ambiguous Fits”论文表明，拟合程度同样好的缩放定律曲线可能外推出截然不同的结果（thread）。
基准测试质量：SemiAnalysis 的受访者认为，许多流行基准测试“难倒不难，只是不公平”（clip）。
组织难度：另一项研究发现，只有 16% 的基准测试衡量了组织难度（Barres）。
皮影戏基准测试争议：Lucas Beyer 指出，六个模型都没有复现出一个盘子，而一个无特征的团块得分更高（giffmana）。Simo Ryu 质疑评分设计（cloneofsimo）。
无需更新权重的自我改进：
Recursa：一个经过验证的技能与记忆库将 DeepSeek-V4.1-Flash 在留出法律任务上的表现从 30% 提升到 55%（summary）。
Zep Agent Skills：从 Opus 5.5 轨迹中编译出的技能使较弱模型提升 4.5–18.8 分（TuringPost）。
RSI Arena：十个智能体在共享的 64-GPU 集群上训练助手。经过人类反馈后，10 个中有 8 个有所改进，且这些提升与基准测试的改进并不同步（post）。
行业与政策
生物安全政策：OSTP 发布了《核酸合成筛查国家政策》（Kratsios）。
要求：全政府范围的客户与序列筛查，以独立验证取代自我证明。
机构：NIST 将制定标准，HHS 和 USDA 将认证供应商。
安全动荡：OpenAI 的 Tibo Sottiaux 预计，随着 AI 驱动的漏洞发现激增，向“超安全”软件的过渡将充满动荡（post）。
Daybreak 计划：OpenAI 为防御方提供 GPT-6 Sol/Luna，并为选定的红队提供 Cyber 变体（reach_vb）。
Anthropic 产品争议（归因主张）：Anthony Pompliano 声称，Anthropic 在推出竞争性个人金融产品之前，曾向 Silvia 工程师套取产品细节（post）。
Silvia 的成本主张：他表示 Silvia 自家的模型将计算成本削减了约 97%。
质疑：批评者称该帖子是自我宣传（teortaxes）。该指控未经证实。
热门推文（按互动量）
@Thom_Wolf：终极 MoE 训练手册 — 3.3K
@mkratsios47：核酸合成筛查政策 — 2.3K
@JakeMendel99：METR 报告后的时间线更新 — 1.4K
AI Reddit 回顾
/r/LocalLlama + /r/localLLM 回顾
1. 开放权重势头：Kimi、GLM-5.5、OpenRouter 份额
Kimi-K3.1-Pro 现已开放权重（互动量：1972）：Moonshot AI 发布了 Kimi-K3.1-Pro 的开放权重：这是一个原生多模态 MoE 智能体模型，基于 Kimi K3 通过大规模联合强化学习后训练而成，具有
2.8T总参数、104B激活参数、93层、896个专家、MXFP4/MXFP8 QAT、MoonViT-V2 视觉，以及1,048,576token 上下文窗口。在架构上，它用24个 Gated DeepSeek Sparse Attention 层加上69个 KDA 层替换了 K3 的全注意力 Gated MLA 层，以实现更高效的长上下文推理；据报告在编码、智能体、多模态、金融/法律和长上下文基准上均取得有竞争力的结果，不过许多结果取决于 harness/工具使用/推理设置。 技术圈最热门的反应集中在宽松的许可证上：评论者称一个约3T参数的开源权重模型允许个人使用和署名商业使用（仅对 API 提供商有限制）“简直疯狂”。也有人开玩笑地质疑在消费级 GPU 上实际本地部署的可行性，例如“我的 GTX 1030 准备好了。”一位评论者强调，Kimi-K3.1-Pro 是一个
3T参数的开源权重模型，许可证相对宽松：个人使用完全允许，商业使用主要要求署名，额外限制似乎主要针对 API 提供商。其技术意义在于将极大规模的模型与开放权重可用性结合起来，且使用限制相对较轻。
Z.ai 首席科学家唐杰刚刚披露了即将推出的 GLM-5.5（32B、122B 和 256B）背后的训练流程（热度：1440）：bebuu_ai 在 X 上报道称，Z.ai 首席科学家唐杰在清华大学的讲座中概述了即将推出的 GLM-5.5 各变体的训练流程，这些变体被标记为
32B、122B和256B。所描述的预训练流程主要以内部数据为驱动：约~1T页 /~10B页每天的网页级抓取、使用 GLM-OCR 进行科学 PDF 提取、大规模书籍、从代码仓库中挖掘的可执行代码任务、源自视频的长上下文/世界知识数据，以及总计数亿小时的 ASR 转录音频。评论者对参数规模持正面态度，尤其是较小32BGLM 模型的可用性。有人提出的一个技术性保留意见是，32B/122B/256B可能并非独立发布，而可能是旨在合并到更大的~1T参数 GLM-5.5 系统中的子模型/组件。一种技术性解读是，所列出的 32B、122B 和 256B 规模可能并不代表单独的最终发布版本，而是旨在合并或组合成更大的 ~1T 参数 GLM-5.5 系统的组件/子模型检查点。这被表述为推测，但它是该讨论串中提出的主要实质性架构观点。
有人关注 GLM-5.5 32B 变体是否会采用 混合专家（MoE）设计，如果每个 token 只激活一部分专家，这将使较小模型在推理时比稠密 32B 模型更具计算效率。
昨天 Openrouter 上全部（27 万亿）token 中，仅 Deepseek 就占了 53%。开放权重实验室现在合计超过 75%（热度：945）：该图是一张技术使用份额图表，而非梗图：它展示了 OpenRouter 按实验室划分的每日 token 份额，在所指日期 DeepSeek 达到约
53%的27Ttoken，而开放权重实验室合计超过75%（图片，来源）。主要技术结论是，OpenRouter 流量似乎严重偏向开放权重/开放模型提供商，DeepSeek 在近期 token 量中占据主导，而 Google、Z-AI、小米和 Meta 等实验室则占据了剩余部分的大部分。评论者提醒，OpenRouter 可能并不代表更广泛的企业 AI 市场，因为那里的用户本来就更可能路由到开放权重模型，而大型组织通常直接从供应商处购买。一项技术批评是，通过 OpenRouter 使用 DeepSeek 对于智能体工作负载可能效率低下，原因是缓存感知路由较弱且提供商亲和性较短，可能导致重复的 KV 缓存重算，而不像 DeepSeek 的直接 API 那样。有人就 OpenRouter 对 DeepSeek 的缓存感知路由提出了一个具有技术意义的担忧：评论者称 OpenRouter 仅将提示固定到同一提供商约
10 minutes，而许多后端提供商的缓存保留时间很短，导致较长的智能体历史被反复重算。建议是直接使用 DeepSeek API，据称其 KV 缓存保留时间可长达“数天”而非数分钟，这可能降低智能体工作流中重复的预填充成本。有用户报告了 LLM 辅助编码会话的具体成本对比：使用 DeepSeek 进行为期一天的背景代理工作流成本约为
$4，而使用 Claude 进行类似会话则超过$400。虽然这只是轶事，但其量级凸显了 token 密集的代理编码工作负载对模型定价和缓存行为可能极为敏感。一项规模对比指出，根据公开估算，Google 据称处理约
100 trillion tokens/day，大致是 OpenRouter 所引用的每日27 trilliontoken 的3×。这被用来提醒：OpenRouter 的流量并不能代表前沿模型的总使用量，尤其是因为花费数百万美元在 AI 上的大型企业不太可能将生产流量通过 OpenRouter 路由。
2. Qwen3.8 Flash Next V3.1 量化版本与 1500 美元设备基准测试
新的 Qwen3.8-Flash-Next Unsloth Dynamic V3.1 GGUF（活动：374）：该图片是一张技术公告幻灯片（并非梗图），主题为“新的 Qwen3.8-Flash-Next Unsloth Dynamic V3.1 GGUF”：图片。它总结了 Unsloth 的说法，即新的 UD v3.1 GGUF 量化在 DeepSWE、Terminal-Bench、Aider Polyglot、LiveCodeBench 等基准上，相比 GSQ-RCO 将准确率提升了约
10–15%，基准测试在最高256K上下文下运行，并报告了26.2B个评估 token。该帖子还介绍了跨 BF16/Q8_0/Q5_1/IQ4_NL 变体的 engram 切换，相对于 BF16 的 RMSE 从 Q8_0 的0.0053到 IQ4_NL 的0.0757不等，并链接了在 Hugging Face 上发布的文件。后续评论澄清，UD-Q4_K_XL 仅更新以支持 engram 切换，而 UD-IQ4_XS 及以下等更小的量化版本则获得了新方法；更大的量化版本改进仅是一种可能性。其他评论大多是热情和赞赏，而非技术辩论。Unsloth 的 Daniel Hanchen 澄清了 Dynamic V3.1 GGUF 量化更新的范围：
UD-Q4_K_XL仅更新以支持engram 切换，其他方面保持不变，而UD-IQ4_XS及更小/更低的量化版本获得了新方法。诸如UD-Q4_K_XL等更大的量化版本之后可能会获得质量改进，但目前尚未确认。有用户请求对 Swift 1.5 微调版进行类似的 Unsloth 处理，特别指出其推理冗长过度消耗上下文窗口预算。技术担忧在于，冗长的“思考”轨迹和填充 token 会减少可用上下文，因此对于实际推理而言，具有更短推理行为的变体将更可取。
QWEN 3.8 FN - 8bit FP 量化 - 96.32 tokens/s - 95k 上下文 - 1500 美元硬件（活动：1147）：发帖者报告了对低成本多 GPU Qwen 3.8 Flash/Next 配置的进一步优化，加入 MTP 后在编码工作负载上达到
96.32 tokens/s，使用3个草稿 token，而在自然文本上为69 tokens/s，采用 8 位 FP 量化，上下文窗口为95k，硬件成本约为$1500。他们声称逐层通信加专家执行路径为128.0 µs，可将 token 残差分发到24块 GPU、计算专家、收集结果并合并，实现已发布在 crgregersen/m10dis；据称剩余瓶颈是一块老旧的 RTX 3070 负责注意力计算，而非专家 GPU 或 PCIe 分发路径。评论大多质疑其实用性：一位评论者指出电费可能很高，另一位则问作者为何停留在 8 位 FP 而不用更低比特量化以获得更高吞吐和/或更长上下文，认为95k上下文对其自身工作负载没有用处。一位评论者质疑为 Qwen 3.8 选择 8 位 FP 量化，认为更低比特量化可能提升 tokens/秒和/或提供比所报告的
95k上下文窗口更多可用上下文。其言下之意是量化质量、KV/缓存内存占用与吞吐之间的权衡，该评论者指出95k上下文对其工作负载不够用。另一位评论者询问此配置与高内存带宽 CPU 平台（如 Xeon/Epyc/Threadripper，搭配
4/6/8-channel DDR4可提供约100–200 GB/s）加一块大 GPU（如 RTX 3090）相比如何。他们认为这种配置可能提供类似的价值主张，且搭建摩擦更小、CUDA 兼容、可直接访问 CPU，尽管带宽降低但功耗可能更低。围绕
95ktokens 是否实用展开了一场上下文长度讨论：一位用户表示自己在128k甚至256k时就已经触及上限，舒适工作需要约384k–512ktokens。这凸显出对某些长文档或智能体工作流而言，吞吐量本身不如超大有效上下文和 KV 缓存容量重要。
3. 本地推理系统：剪枝、SSD MoE、Blackwell 离线运行
我移除了 gemma 85% 的权重（而且基本没问题）（活动：862）：该图是帖子 “我移除了 gemma 85% 的权重（而且基本没问题）” 的技术基准图表，总结了一个剪枝后的 Gemma 4 26B-A4B MoE，每层仅保留
8个专家，将其变为约3.81B参数的稠密模型，量化约为2.75 GBQ4_K_M。在作者狭窄的分类工作负载上，剪枝模型据称与原始 26B 模型达到91.7%的一致性，略高于 Gemma 4 12B 的90.0%，同时运行速度为79 tokens/s，峰值内存为3.8 GB，而 12B 为8.3 GB，完整 26B-A4B 为14.5 GB。评论大多是幽默或怀疑，而非深入技术讨论，将结果称为“神经网络脑叶切除术”，并指出被移除的权重很可能编码了只有在更广泛知识或重回忆任务上才会显现的能力。一位评论者要求提供与 Gemma 4 E4B 进行更有意义的基线对比，暗示仅孤立地评估剪枝/简化后的模型是不够的；技术读者会希望看到与规模相近的密集或高效 Gemma 变体进行并排基准测试。
另一位评论者将实验描述为从通用
26B-A4B模型中提取活跃的A4B部分，并将其用于狭窄任务，由此提出了一个关键的技术问题：被移除的权重是否主要支撑通用能力，而非所展示的任务性能。一个讨论点聚焦于能力损失：被移除的
85%权重很可能编码了一些行为，这些行为只有在特定的回忆、推理或领域迁移任务中才会显现，因此模型“基本没问题”可能很大程度上取决于基准/任务覆盖范围。
SSD MoE 终于可行了！（活动：561）：发帖者声称，一个基于 llama.cpp 的 MoE 推理引擎可以将
60–70%的路由专家卸载到 SSD，而仅增加1–3 ms/token的 SSD 流式传输开销，使模型在 RAM/VRAM 受限的情况下仍显得常驻内存。他们还报告了一个用于硬件/模型标志选择的自动调优器、逐层提示处理（据称在 RAM+VRAM 下实现2×的预填充加速，在 RAM+VRAM+SSD 配置下实现4×的加速），以及一个近乎无损的上下文压缩引擎；早期目标包括在16 GB RAM上以20+ tok/s解码运行 Flint 40B Q4K_XL，以及在32 GB RAM + 12 GB VRAM上以~50 tok/s解码 /600–700 tok/s预填充运行 Ling 3.0 Flash MXFP4，并以 262k 上下文 进行演示。关于 SSD 耐久性的说法是，该引擎执行只读流式传输，因此与写入密集型工作负载相比，不应实质性影响 SSD 磨损。 主要技术反馈大多围绕架构：评论者建议将项目拆分为独立的 引擎、自动调优器 和 测试框架/UI 组件，以避免范围蔓延，并询问它与现有 SSD/卸载系统（如 Strata 和 Maya）有何不同。一位评论者建议现在添加 Qwen 3.8 Flash Next 支持，因为其架构很可能预示了 Qwen 4，使未来支持成为增量工作。一位评论者建议将项目拆分为不同的组件——引擎、调优器 和 测试框架——并独立开发它们。技术要点是，试图同时解决运行时执行、优化/调优和评估/集成可能会造成不必要的耦合，并增加维护负担。
在模型支持方面，一位评论者认为现在实现 Qwen 3.8 Flash Next 很可能是为 Qwen 4 系列做的有用准备：“3.8 已经来了，这样你就能知道 4 的形态。” 他们的假设是，Qwen 4 在架构上很可能足够相似，因此支持要么“直接适配”，要么只需极少的增量更改。
2 块 RTX PRO 6000 完全离线运行 DeepSeek-V4-Flash（284B）：峰值 1,170 tok/s（活动：387）：一台 2× RTX PRO 6000 Blackwell 工作站（
192 GB总显存，EPYC 9124，256 GB内存）据称在 vLLM 下完全离线运行 DeepSeek-V4-Flash 284B，使用TP=2且无 NVLink，得益于原生 FP4 支持而得以装下；作者称同一检查点在 Hopper 上需要约304 GB。报告吞吐量：209–229 tok/s单用户，TTFT 为0.4 s，1,003 tok/s在24用户时，p95 TTFT 2.7 s，以及1,170 tok/s峰值在32流时；他们还报告了1M上下文，检索在543Ktoken 处验证，80%在 20 任务 Terminal-Bench 2.1 子集上，815 WGPU 功耗 / 约1.07 kW整机功耗，以及约13 min冷启动。注意事项包括由于87%显存权重驻留，一次只能运行一个大模型；按 OpenRouter 定价转售经济性差；以及围绕 KV 卸载泄漏/dev/shm加上残留 vLLM 工作进程占用约89 GBGPU 内存的运维清理问题；构建/BOM/BIOS 详情发布在 autonomous-ai/Personal-AI-Computer。最具实质性的技术反驳是，无 NVLink 的 TP2 很可能在 PCIe 上产生逐层 all-reduce，这可能解释了 24 用户时2.7 sp95 TTFT 的大部分；一位评论者建议检查nvidia-smi topo -m以确认是PIX/PXB还是SYS，并对 MoE 使用--enable-expert-parallel以避免逐层归约。其他评论主要询问机箱/PCIe 转接卡，或开玩笑说买内存的诱惑。一位评论者认为，没有 NVLink 时，张量并行（
TP2）执行很可能在每一层都通过 PCIe 进行 all-reduce，使得互连延迟/带宽成为所报告的在24用户时2.7s p95 TTFT的合理解释，而非 FP4 计算吞吐。他们建议检查nvidia-smi topo -m以确认 GPU 是作为PIX/PXB而非SYS连接，并指出对于 MoE 模型，通过--enable-expert-parallel启用专家并行可以避免这种逐层归约开销。
Nvidia RTX Spark 加密固件使 Linux 上推理速度降至 35%（活动：512）：MindStudio 报道称 RTX Spark 笔记本可以运行原生 Linux，使用 Nvidia 开源内核驱动、CUDA、4K/120Hz 显示输出，且大部分外设可用，但仅限 Windows 的 Nvidia Platform Controllers and Framework 组件负责解密固件功耗表并控制 CPU/GPU 功耗共享。缺少该组件时，原生 Linux 下插电 GPU 被限制在约
~780 MHz，而 Windows 上为~2.2 GHz，使 GPT-OSS-120B 推理从 Windows/WSL 上的~65 tok/s降至原生 Linux 上的~14 tok/s——接近 Windows 吞吐量的~22%，尽管标题用了35%的说法。评论者怀疑这一限制并非纯属意外，一些人指称 Nvidia 可能在保护 Windows/WSL 的相关性，而另一些人则认为，如果 Windows 能在同一硬件上解密/管理固件，那么 Linux 支持或逆向工程工具在技术上应是可行的。提出的一个技术相关点是，如果 Windows 能在同一硬件上解密或加载 RTX Spark 固件，所需的密钥/工具或协议行为可能是可观察的，并最终可在 Linux 上复现。这将
35%Linux 推理速度问题更多地框定为驱动/固件路径差异，而非硬件限制，有可能被逆向工程或在 Linux 工具中修复。
技术性较低的 AI Subreddit 回顾
/r/Singularity、/r/Oobabooga、/r/MachineLearning、/r/OpenAI、/r/ClaudeAI、/r/StableDiffusion、/r/ChatGPT、/r/ChatGPTCoding、/r/aivideo、/r/aivideo
1. AI 视频编辑模型发布
Viggle Remake：用于重演/编辑整段视频的开放权重。（活动：613）：Viggle Remake 在 Hugging Face 上发布了开放权重，用于在保留源动作、镜头运动和配乐的前提下重演人物/编辑现有视频，基于 H3。该仓库围绕一个 MCP 服务器设计，用于智能体式长视频处理：将视频切分为窗口、绘制关键帧、生成提示词、渲染、自检和拼接；作者报告的最长运行是一段
2-minute音乐视频，并在 mcp/examples/white-house-funk 为所发布的演示提供了可复现示例。它还附带 ComfyUI 节点/工作流、面向较小 GPU 的int8/GGUF变体，以及低秩rank-128/rank-64LoRA；托管应用可在 viggle.ai 获取。一位本地用户表示，Viggle Remake 在替换通用角色或提示词指定的实体方面很强，但在保留可识别的真人身份/面部特征方面不如 Minimax H3——他形容结果看起来像目标人物的“一个糟糕的 lora 版本”。另一位评论者询问它是否支持 NSFW 用途，但所提供的评论中没有给出技术性回答。一位用户指出，该演示可通过项目在 Hugging Face 上的 MCP 示例资源复现：Viggle/Viggle-Remake mcp/examples/white-house-funk。这对技术读者很有用，因为它指向一个具体可复现的流水线/示例，而不仅仅是渲染出的视频输出。
一位本地用户报告称，Viggle 在替换全身角色方面很强，尤其是机器人等非人类或提示词定义的主体，但在保留可识别的人脸特征方面较弱。他在角色保持方面将其与 Minimax H3 相比不利，称 Viggle 的输出可能像目标人物的“一个糟糕的 LoRA 版本”，而不是准确保持身份。
一位评论者询问 Viggle 是围绕现有视频模型的封装/框架，并附加了遮罩和修复阶段，还是使用了不同的底层视频生成架构。这凸显了一个尚未解决的实现问题：该系统有多少是核心生成建模，多少是对分割、跟踪、遮罩和视频修复组件的编排。
Gemini Omni 1.2 Flash：快速、高性价比，支持更长片段（活动：43）：****Google 宣布 Gemini Omni 1.2 Flash，这是一个通过 Gemini API 和 Google 商业产品提供的正式可用视频生成/编辑模型。在技术上，它新增了原生
3–15s片段生成、多轮对话式编辑、改进的参考遵循和时间一致性、更好的多说话人语音/口型同步，以及更可控的连续镜头运动；定价从 Omni 1.1 的30%降至$0.07/s，适用于720p，支持草稿/编辑/放大工作流最高至1080p/4K，具备 SynthID 水印，以及 Provisioned Throughput 等 Google Cloud 选项。Google 仍指出其在快速体育/动作、快速脚本变化和复杂物理模拟方面存在局限。
2. 中国 LLM 势头：Qwen GGUF 与 DeepSeek 使用情况
通过 Unsloth Dynamic v3.1 GGUF 在本地运行 Qwen3.8-Flash-Next，准确率提升 +15%！（活动：386）：该图片是 Unsloth 的技术基准公告，介绍使用 Dynamic v3.1 GGUF 量化在本地运行 Qwen3.8-Flash-Next，声称在
256K上下文下，这些量化版本在同尺寸中属于最准确的，相比同类前沿量化版本的中位性能提升为+15%。图表将 Unsloth V3.1 与 GSQ-RCO 在 DeepSWE v1.1、Terminal-Bench 2.1、LiveCodeBench v6、GPQA Diamond、MMLU-Pro 等 agentic/代码/数学基准上进行比较，正文链接到 Hugging Face 上的 GGUF 发布和一篇 博客文章；图片本身在这里：https://i.redd.it/7um5vq9hymzh1.png。这不是梗图；而是一张用于本地推理的推广基准图，并注明了一项实际要求：32GB+ RAM。评论大多简短但偏技术性：一位用户计划将该发布与其 Swift 实现进行比较，另一位则询问UD-Q6_K_XL是否优于 NVIDIA 来自 nvidia/Qwen3.8-Flash-Next-NVFP4 的 NVFP4 量化，这表明人们关注的是量化质量权衡，而不仅仅是头条基准分数。一位评论者询问 Unsloth
UD-Q6_K_XL在Qwen3.8-Flash-Next上是否优于 NVIDIANVFP4，直接比较了 Unsloth 的 GGUF 量化与 NVIDIA 在 huggingface.co/nvidia/Qwen3.8-Flash-Next-NVFP4 发布的 NVFP4 checkpoint。这凸显了一个围绕更高位宽 GGUF 动态量化与 NVIDIA 面向 FP4 的格式之间质量/性能权衡的实际评估问题。Another technical comparison noted that ISTA-DASLab Next-GSQ-RCO-IQ3_XXS is about
75.8GB, while UnslothUD-IQ2_XSis also roughly75.8GB. The commenter questioned the value proposition if Unsloth’s lower-named quant tier has similar disk footprint but is claimed to provide equal or better quality.
Insane that Deepseek alone accounted for 53% of all tokens on openrouter yesterday, the next 10 labs total under 47%. (Activity: 609): The image is a technical market-share chart, not a meme: it shows DeepSeek sharply rising to about
53%of all daily tokens routed through OpenRouter, exceeding the combined share of major competing labs like Anthropic, Google, OpenAI, Meta, xAI, and Mistral. The source cited is dirac.run’s daily token share by lab, and the chart image is here. A commenter adds a related datapoint that DeepSeek is reportedly at84%share on opencode with24Ttokens, citing opencode.ai/data. Comments are strongly positive toward DeepSeek, attributing the dominance to model quality and efficiency, with one user predicting it will become “no1 everywhere someday.”A commenter cited opencode usage data showing DeepSeek at
84%of tokens with24Ttokens tracked, suggesting its dominance may be even stronger in coding-focused traffic than the OpenRouter snapshot: opencode.ai/data. Another technically relevant theme was that adoption appears driven by a combination of model quality, efficiency, and low pricing, with users specifically asking for a newer “pro” release.
3. Agentic Coding and Cybersecurity Stress Tests
OpenAI claims their new security model patched 948 Linux privilege escalation vulnerabilities (Activity: 1137): The image is a screenshot of an OpenAI post claiming its security researchers built an autonomous cyber pipeline for vulnerability discovery, exploitation validation, and patch generation, and that an upcoming cyber model generated patches for
948Linux kernel local privilege-escalation vulnerabilities in a single run at a reported API cost of$1.2M. The technical significance is the claimed scale of AI-assisted kernel vulnerability remediation, but the Reddit post provides no patch set, PR links, CVE list, benchmark methodology, or independent validation beyond the linked OpenAI/X announcement. Commenters were skeptical and alarmed: one noted that948privilege-escalation bugs is an unusually large number, another extrapolated the capability to state actors and said to “assume you're compromised,” while another asked whether OpenAI is actually submitting pull requests.A commenter questions whether the
948reported Linux privilege-escalation fixes were found after earlier OpenAI security models/efforts such as Mythos, Sol, and Astra had already been applied since April, implying concern about overlap, missed coverage, or duplicate findings across model-assisted vulnerability discovery runs.One technically relevant cost discussion notes that the reported US
$1.2Mpayout would be inexpensive relative to the potential impact of a critical Linux kernel privilege-escalation vulnerability, framing large-scale automated vuln discovery as economically favorable compared with downstream compromise costs.
I built a hyper realistic fighter jet simulator for the browser with opus 5.5 and it went viral on Twitter! (Activity: 1080): A solo developer launched Viper One One, a browser-based fighter-jet simulator at viperoneone.com, claiming ~
25,000players over two weeks and ~1,000daily users, plus a feature/shoutout from threejs.org. The implementation is described as built with Claude Opus 5.5, fal models, and Three.js-era web graphics techniques: fitted GoPro-style fisheye cockpit camera, custom canopy shader with sun-catching scratches/rain streaks, multiplayer rooms, ranked ladder, mobile load/crash profiling, and agent-based parallel development branches for missions/audio/performance/trailers. The author says they used long-running LLM research/physics-simulation sessions to study aircraft behavior and then port simplified/efficient behaviors into the browser runtime; the linked Reddit video could not be accessed due to Reddit403 Forbidden. Top comments pushed back on the “hyper realistic” label, with one saying the flight model felt laggy and “like flying an old lawnmower.” Others still praised the technical achievement, emphasizing that this level of 3D visual quality running in-browser—and apparently produced by a solo “vibe coding” workflow—would have been surprising compared with older console-era team-produced games.Several commenters challenged the “hyper realistic” claim on technical/experiential grounds, with one reporting the browser sim “feels super laggy” and that the flight model does not feel realistic, comparing it to “flying an old lawnmower.” This suggests perceived issues around frame pacing/input latency and physics/flight dynamics rather than just visual fidelity.
A technically relevant point was that the demo’s main achievement may be browser-based rendering quality, not simulation realism: one commenter noted it is “mind boggling” that something of this visual quality runs in a browser and compared it favorably to PlayStation 2-era graphics that previously required large teams.
Thanks to two lines in the Claude setting , I was able to work 3 x 5H window without running out ,. (Activity: 1078): The image is a Claude usage dashboard (image) showing only
22%of the weekly limit used, with projections like~59% at resetand~41% wasted, supporting the post’s claim that Claude Code can run multiple back-to-back5hwindows without exhausting quota. The post attributes this to settingCLAUDE_AUTOCOMPACT_PCT_OVERRIDE=75andautoCompactWindow=300000in~/.claude/settings.json, effectively triggering auto-compaction around225ktokens so agents have enough remaining context headroom to summarize before hitting the limit. Commenters questioned relying on opaque auto-compaction, with one arguing “Handoff > autocompact” because manual context transfer is more controllable. Another pointed out that similar behavior may be configurable through the UI by selecting a larger context window such as400K, rather than editing settings manually.Several commenters debated manual context management vs Claude autocompaction, with one arguing that delegating context pruning to an opaque mechanism is risky: “I will never understand why you would delegate your context to something you cannot control.” Another suggested handoff workflows may be preferable to autocompact when preserving task state matters.
A technical clarification noted that instead of relying on an autocompact override around
225ktokens, users may be able to select a larger context setting directly, e.g.400K, via Claude’s UI/settings. Another commenter warned that repeatedly crossing300kcontext likely indicates a workflow problem and suggested using sub-agents per task to reduce compaction overhead.One commenter refined the settings-edit prompt, suggesting the model only needs concise instructions such as adding
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "75"to the existingenvblock in~/.claude/settings.jsonand setting top-level"autoCompactWindow": 300000. They argued newer models can reliably preserve JSON validity and merge into existing structures without verbose reminders like “make sure the file is still valid JSON.”
Four days with Codex and I genuinely can't believe how bad this experience has been (Activity: 76): A developer reports a
4-day failed trial of OpenAI Codex, contrasting it unfavorably with Claude Code for autonomous coding: Codex was described as slow in cloud execution, overly literal, reluctant to act without explicit prompts, and prone to adding architectural complexity instead of making targeted fixes. Specific alleged failures included silently overriding settings, writing tests that encoded incorrect behavior, introducing unrelated regressions, expanding CI with coverage comparisons/mutation testing/dependency analysis until PR checks took nearly1 hour, and a stop-control bug where execution resumed after interruption; Codex later self-reviewed and identified16substantiated failures, including poor architecture and failure to deliver. No top comments were provided. The poster’s core opinion is that Codex currently requires excessive supervision for autonomous development, while Claude Code made better engineering tradeoffs and successfully completed the release work.
来源：Latent Space · latent.space