Latent Space 汇总 PHP2Shell 事件：OpenAI Patch the Planet 与 Wiz 各自用 AI 模型独立发现 PHP 核心漏洞
[AINews] OpenAI’s Patch the Planet program is 1 of 2 parties to discover PHP2Shell vulnerabilities in core PHP affecting 70% of the web, using GPT-5.6 Sol; coordinated response over 2 months
Latent Space 的 AI News 汇总了 PHP 核心内存损坏漏洞 PHP2Shell（CVE-2026-109618、CVE-2026-109619）的披露：Calif 研究者在 OpenAI Patch the Planet 项目中用 GPT-5.6 Sol 发现。
原文梳理了 PHP2Shell 漏洞发现与两个月协同修复的时间线，并区分了有据事实与未经证实的传闻。
译文尚不完整，完整内容请切换到原文。
大约两个月前，OpenAI 推出了面向前线防御者的 Daybreak，这是一项 10 亿美元的补贴，用于获取 Daybreak 网络模型和产品。这笔资金几乎立即投入使用，因为 PHP 中的重大漏洞被两方独立发现：安全公司 Calif 的研究员 Ryan Austin，作为 OpenAI“Patch the Planet”项目的一部分，于 2026 年 8 月使用 GPT 5.6 Sol：
……以及 Wiz，该公司最近被并入 Google Cloud（使用 Gemini 4 Argon 和 GPT-5.6 Sol，以及他们自己的工具 Wiz Atlas）。
所有高调的网络安全披露都至少带有一点营销色彩，而这是否属于像 log4shell 和 Heartbleed 那样著名的严重警报级漏洞，尚存争议，但PHP 生态系统的协同响应无疑是开发者社区最理想的应对方式。
我们至少还要再经历一年这样的关键漏洞发现期；但责怪发现漏洞的报信者是错误的做法；相反，值得庆幸的是，我们的关键软件正在接受人类历史上规模最大的安全审计。
2026/10/20-2026/10/21 的 AI 新闻。我们检查了 12 个 subreddit、544 个 Twitter 账号，没有进一步检查 Discord。AINews 的网站可让你搜索所有过往期刊。提醒一下，AINews 现在是 Latent Space 的一个栏目。你可以选择开启/关闭邮件频率！
AI Twitter 回顾
头条：PHP2Shell——时间线、核心主张，以及紧急响应背后的复杂情况
发生了什么
研究人员披露了两个 PHP 引擎内存破坏漏洞，并演示了针对主流 CMS 的未认证利用，以及异常广泛的协同响应。
研究人员将这些漏洞命名为 PHP2Shell，并标识为 CVE-2026-109618 和 CVE-2026-109619。他们的技术描述将缺陷定位于 PHP 内部对内存不足状况和致命错误的处理——而非 WordPress 插件或应用程序的认证逻辑。他们报告演示了完整的远程代码执行和“Heartbleed 式”内存泄露。@sagitz_
披露的演示包括针对 WordPress、Drupal 和 Joomla 的预认证 RCE。研究人员的公告还单独声称可对任何 PHP 应用进行远程内存泄露。这些是研究人员报告的利用结果；不应被悄然扩大为“每个部署都存在相同的、可立即利用的 RCE 路径”这一主张。@sagitz_
OpenAI 称 Calif 研究人员使用其模型发现了这些缺陷，而二手报道称 Wiz 独立发现了相同的漏洞。帖子指出 Calif/OpenAI 一方使用了 GPT-5.6 Sol；一个与 Wiz 有关联的账号将发现、利用链开发、检测器创建和补丁验证归功于 Gemini 4 Argon。这是一个多方发现的故事，而非单一供应商独自发现并修复了该问题的证据。@TheRundownAI、@steipete、@ralucaadapopa
OpenAI 表示，在披露之前进行了大约两个月的协调修复工作。该公司称，该补丁需要对 PHP 引擎进行重大改动，并需要维护者、研究人员、安全提供商和政府之间的协调。一位参与其中的研究人员证实，他们与 PHP 基金会合作，以支持和加固该补丁。@OpenAI、@itszn13
Cloudflare 在计划发布补丁之前部署了初步的 WAF 缓解措施。其 CTO 表示，这些规则覆盖了已知的漏洞利用途径，所有客户（包括免费套餐）均可使用，并且随着早期攻击的出现而不断更新。他明确称这些规则是临时权宜之计，并指示运维人员在 14:00 UTC 打补丁。@dok2001
所提供的 NSA 账号建议为立即更新做好准备——如果无法及时缓解，则将系统下线。OpenAI 后来的消息称升级已可用；二手报道称细节在补丁发布前就已泄露。所提供的材料并未确切说明泄露了什么、何时泄露，或发布计划是否发生变化。@NSACyber、@OpenAI、@TheRundownAI
重建时间线
1. 发现与私下协调：公开披露前约两个月。
OpenAI 将这项工作归入 Patch the Planet，并表示它领导了一个准备修复和防护的联盟。其安全研究员 Eric Wallace 补充说，内部团队致力于打补丁和检测，而不仅仅是披露漏洞，并向政府和外部机构提供了保密的提前通知。Greg Brockman 重申了两个月的协调期。这些是参与者的说法，而非经独立审计的事件时间线。@Eric_Wallace_、@gdb
项目名称之间的区别很重要：这些帖子将该漏洞与 Patch the Planet 联系起来，而研究人员则将安全工作归功于 Daybreak 模型访问权限。这些是相关的角色——修复计划与访问机制——并非对同一项目的可互换描述。@OpenAI、@S1r1u5_
2. 提前公开警告和预定的补丁窗口。
日语帖子警告运维人员为 10 月 21 日 23:00 JST 的发布做好准备，这与 Cloudflare 的 14:00 UTC 公告一致。其中一个帖子正确地强调，PHP 核心漏洞不能仅仅靠等待插件开发者来修复。另一个帖子将这一事件描述为补丁发布后的“15 分钟”竞赛，但那个数字是预测——而非实测的武器化时间。@ds_nakajima、@expokun
3. 发布前过滤与观察到的攻击活动。
Cloudflare 的帖子是所提供记录中最有力的第一手运营证据：缓解措施已经部署，已知途径已被覆盖，并且“早期攻击”正在出现。它没有说明成功的入侵、请求数量、受害者数量、载荷来源，或流量代表的是原始的漏洞利用开发还是对泄露信息的再利用。@dok2001
4. 研究披露、政府警告与补丁可用性。
研究者的公开帖文描述了漏洞利用演示和错误处理方面的根本原因。NSA 的帖文呼吁紧急准备并有条件关停。OpenAI 随后表示每个 PHP 站点都可以安全升级。所提供的材料中不包含 PHP 基金会直接发布的公告、确切的修复版本矩阵、发行版软件包标识或补丁提交。这一缺失的一手来源层使得无法给出可靠的“升级到版本 X”的指令。@sagitz_、@NSACyber、@OpenAI
5. 据称的提前泄露与大规模服务中断。
The Rundown 报道称细节被提前泄露。随后一份病毒式传播的汇编补充称，据 Censys 统计，约 150 万台服务器运行着未修复的版本；报道还提到荷兰机构、欧洲其他地区的政府网站、Wikipedia、Archive.org、Asana、GOG 等出现关停；以及日本首相在 05:55 发出的警告。这些单独的说法均未在所提供的材料中得到其对应的公告、测量数据或状态页面的佐证。记录也无法确定每次中断究竟是预防措施、打补丁导致的中断、无关故障，还是遭到入侵。@TheRundownAI、@fiveoutofnine
SemiAnalysis 另行报道称，日本首相敦促 PHP 运营者立即打补丁，若无法做到则暂时断开连接。其报道将这一反应置于日本已有的入侵浪潮背景中，而非认定 PHP2Shell 导致了那些更早的事件。@SemiAnalysis_
6. 披露后提供了暴露情况检查协助。
OpenAI 发布了一个包含 Codex skill 的仓库，旨在指导运营者检查其站点是否受影响。这是一种协助流程，不能替代厂商公告、软件包验证，也不能作为所有存在漏洞的运行时都已被替换的证据。@OpenAI
AI 的作用：可信证据、存在争议的功劳归属与尚未厘清的因果关系
肯定性论据比仅凭基准测试的说法更有力。研究人员描述了可用的漏洞利用链、协同的补丁工程、检测工具和补丁验证。一位参与其中的研究者称 PHP2Shell 是他们协助发现的最具影响的漏洞。OpenAI 将其描述为“防御者窗口”的一个例子：先进模型在攻击者之前发现缺陷，为防御者争取准备时间。重要的是，其措辞是“据我们所知”——这并不能证明此前没有攻击者知晓这些漏洞。@itszn13、@OpenAI
功劳分散于人类、模型和基础设施提供商之间。Calif/OpenAI 和 Wiz/Gemini 作为各自独立的发现记录出现；PHP 维护者提供了上游修复路径；Cloudflare 提供了发布前过滤。Google 还宣传了 Wiz 的测试，其中 Gemini 4 Argon 发现的漏洞数量是基线模型的两倍多，但所提供的宣传帖未公开数据集、基线、预算或误报统计。这并非对 PHP2Shell 发现性能的独立对比评估。@TheRundownAI、@ralucaadapopa、@Google
研究者访问政策既获赞誉也遭批评。一位研究者将 OpenAI 的 Daybreak 访问权限归功于一系列发现，涵盖 PHP、GitLab、Chrome、WordPress 及其他目标。另一位则尖锐对比了 OpenAI 经过审查的访问权限与 Anthropic 的限制；所谓 Anthropic 贡献了“零价值”的说法只是该作者的笼统观点，并未由 PHP 记录所证实。还有一篇帖子批评了对 Astra 访问的限制，并主张为 1,000 名经过审查的研究者提供最好的可用模型并加以密集监控，而不是僵化的红/蓝之分。@S1r1u5_、@migtissera、@S1r1u5_
相反的安全理由出现在有报道称 Anthropic 将 Mythos 级模型的广泛访问推迟了四个月以加强网络防护。这为限制访问提供了背景，但并未解决其执行究竟是有助于还是阻碍了这次特定的修复工作。@kimmonismus
一波披露本身并不构成一波 AI 所致入侵的证据。所提供的 feed 混合了防御性发现、供应链攻击、凭据窃取、预防性关停以及无关漏洞。Ethan Mollick 将此刻解读为攻击与防御的加速已超出人类响应速度；John Allard 则描述了一种能力“相变”，同时承认许多近期发现来自白帽项目。两者都是对这一模式的解读，而非事件层面的因果归因。@emollick、@john__allard
操作层面的复杂问题：打补丁、关停，以及“修复一切”的诱惑
这场紧急状况在分发和归属上的分量不亚于发现本身。运营者需要在托管主机、容器、设备、后台工作进程和旧应用中定位 PHP；获取合适的软件包；部署它们；重启或替换受影响的进程；并验证正在运行的构建版本。一位运营者描述自己维护着众多 PHP/WordPress 站点，已被测试和更新弄得筋疲力尽。另一位则得出结论，补丁分发协调得很差。@ostrisai、@jd_pressman
部署 WAF 减少了即时暴露，但带来了虚假信心的风险。Cloudflare 自身的声明比后来将所有面向互联网的服务置于其后的建议要狭窄：已知攻击向量已被覆盖，防护措施仍在演进，打补丁仍是强制要求。代理覆盖、替代入口路径以及源站的暴露情况必须核查，而不能想当然。@dok2001、@threepointone
关停指导是有条件的，并不证明整个互联网都应断开。所提供的 NSA 帖子建议，在无法立即更新时，将系统下线，直到能够实现全面缓解。对特定运营者而言，相关问题在于受影响版本状态、暴露情况、可用缓解措施以及继续运行的后果——而不是一篇惊悚帖子的互动分数。@NSACyber
“用 RCE 自动修补每台服务器”只是一个提议，并非获授权的修复方案。Marc Köhlbrugge 提出了这一想法；J. D. Pressman 建议对尝试此事的实验室或白帽团队给予总统赦免。未经请求的漏洞利用仍会带来未授权访问、服务中断、错误修复、证据销毁以及跨司法管辖区责任等风险。推测性的赦免并不能提供普遍授权，也无法消除民事和外国法律风险。@marckohlbrugge，@jd_pressman
更新速度存在供应链权衡。一篇被广泛分享的帖子捕捉到了这一困境：持续更新可能让用户暴露于被入侵的软件包，而延迟更新则会让已知漏洞保持开放。Pressman 认为，除非新漏洞和高风险版本的出现速度下降，否则无休止的修补不可持续；他还指出，收不到补丁并发现被盗，比收到过多更新更糟。@xeophon，@jd_pressman，@jd_pressman
长期替代方案仍是未解问题。Sarah Guo 报告称，CVE 数量从大约每月 4,000 个增至自 4 月以来的 15,000 个，并询问形式化验证、更安全的发行版以及没有红队的组织该怎么办。此处未对这些数字进行独立核实，披露数量也不是成功利用漏洞的直接衡量标准。其他帖子询问对完整代码库进行安全扫描的成本，并将挑战重新表述为加固平凡的基础设施，而非只争论抽象灾难。@saranormous，@saranormous，@teortaxesTex，@mimi10v3
对于事件响应团队而言，可辩护的顺序是：获取权威的 PHP 和发行版公告，清点暴露的运行时，在合理时应用临时防护，部署经过认证的修复包，验证正在运行的进程，并单独调查漏洞利用的证据。更新能关闭漏洞；它并不能证明凭据或数据从未暴露。
公众反应：务实谨慎与无依据的升级
谨慎视角强调互联服务很脆弱，修复可能代价高昂。Joshua Achiam 将此刻比作2020 年 3 月，推测互联网封锁，建议备份有价值的互联网资料，并建议打印重要记录。Pressman 表示修复成本超出他的预期。这些是准备性判断——并非即将发生系统性崩溃的证据。纸质副本可能有助于连续性，但本身并非防篡改日志。@jachiam0，@jachiam0，@jachiam0，@jd_pressman
对警报持怀疑态度的视角要求具体说明。Alex Johnson 认为，关于银行账户被任意清空的警告模糊了未授权转账与客户授权付款的诈骗之间的区别。他援引美国《电子资金转账法》中及时报告的保护；这些保护取决于司法管辖区、账户和具体情况，并非普遍保证。Kelsey Piper 则另行警告长期生活在持续毁灭叙事下的心理代价。@AlexH_Johnson，@KelseyTuoc
广泛的个人安全建议需要与 PHP 修复分开。密码管理器、唯一凭据、强 MFA、打补丁、运营商 port-out 保护以及美国特定的信用或税务身份保护措施可以减少下游危害。但启用 2FA 并不能阻止未认证 PHP 引擎漏洞被利用。同样，病毒式传播的“第二天避免所有在线支付”的建议，也没有经过演示的范围评估支持。@peterwildeford、@StillMare_
更广泛的威胁背景是真实的，但不能与 PHP2Shell 混为一谈。SemiAnalysis 报道称，自 9 月 25 日以来，18 家日本公司披露了数据泄露事件，包括约 660 万个 Times Car 账户、1118 万条 Burger King Japan 应用记录以及可能多达 2250 万条 Sourcenext 记录的泄露。它将有关 AI 辅助扫描和 API 攻击的发现归因于 JPCERT/CC。另一篇帖子引用了 8 月 19 日的一份公告，内容涉及针对暴露在互联网上的 Siemens PLC 的 AI 辅助工具。这些是各自独立的已报告事件和公告；两者都不能证明 PHP2Shell 是它们的入口点。@SemiAnalysis_、@AndrewCurran_
关键的未解决证据缺口是具体的：确切受影响和已修复的版本；CVSS 向量；部署前提条件；独立发现时间线；发布前泄露了什么；成功利用与扫描的区别；经过验证的暴露数量；以及每次报告的关停的原因和持续时间。所提供的病毒式事件汇编仅仅通过将 PHP、GitLab、LiteLLM、Railway、证书颁发机构故障和政府警告放在同一叙事中，无法回答这些问题。@fiveoutofnine
其他新闻
Flint 与自动化研究：本地编码模型、更小的团队和科学工作流
Flint 发布，提供广泛的本地服务支持：Recursive 发布了一个 Apache-2.0 编码 MoE，总参数约 40B，激活参数 2.5B，上下文窗口 262K token。LM Studio 表示它需要约 24GB 本地内存。Recursive 将其定位为前沿云代理的端侧补充，而非替代品（发布、规格）。
声称的结果：Recursive 报告在 Terminal-Bench 2.1 上达到 54.9%，在 SWE-bench Pro v2 上达到 89.7%，在 SWE-bench Verified 上达到 74.2%。这些是发布声明，并非独立复现（结果）。
性能：宣传的短上下文速度在 MacBook Pro 上超过 125 tokens/s，在 RTX Spark 上超过 150 tokens/s。另一位用户在 M5 Max 上使用 int4 MLX 测得 114–132 输出 tokens/s；这是对速度的有用佐证，而非受控的能力评估（本地测量）。
研究贡献：Recursive 表示其 Eureka Machine 参与了构思、实现和验证，贡献了稀疏架构选择、低比特训练和内核。它声称尺寸缩减 71% 而质量几乎无损，并在不到四个月内从零开发完成（方法）。
可用性：首日集成涵盖本地框架和托管访问。vLLM 报告在单个 GB200 上以 100K 上下文使用 NVFP4 且无推测解码时达到 500 tokens/s；OpenRouter 提供免费发布访问（vLLM、OpenRouter）。
Mirendil 声称由单一研究者完成大规模预训练：Mirendil 表示，其首个基础模型由一名研究者在 3.5 个月内完成，算力成本低于 1000 万美元，其中包含研究实验和最终训练运行。它披露了异常宽泛的参数范围——Base 为 100B–500B，Large 为 500B–2T，XL 为 2T–10T——而非精确配置。独立评估、后训练结果和 API 访问仍未公布，因此这是一项有待外部验证的重大效率声明（公告）。
JOLT 联合训练教师与学生：Perplexity 与 NVIDIA 的后训练工作解决了自蒸馏中的一个弱点：拥有特权信息的教师可能利用学生无法获得的捷径。JOLT 使用结果奖励训练教师，同时惩罚其与学生之间的过度偏离。作者报告在 MATH 上以少 6.5 倍的训练 token 达到与 GRPO 相当的效果；加入学生结果奖励的 JOLT+ 在五个评估基准上均优于 GRPO（方法与结果，基准摘要）。
GPT-Rosalind 生成可检验的生物学假设：OpenAI 报告称，数千个智能体在 32 分钟内将数百万个小鼠脑细胞的基因表达结果与文献关联起来。其中一个提出的机制将 DCTN1 破坏与胆固醇转运受损联系起来；另一个则考察小脑神经元中 TSC1 与 TSC2 破坏之间的差异。这些是供实验后续验证的假设——并非已证明的治疗方法或经过验证的药物靶点（DCTN1 工作，TSC2 后续）。
推理系统：DeepInfer 经济性、原生 TPU 支持与功耗感知容量
DeepInfer 公开生产调度技术：DeepSeek 发布的框架结合了推测解码、动态预填充尺寸调整、按请求数和 KV 长度进行解码负载均衡，以及 CPU 调度与 GPU 执行的重叠。一个特别可复用的思路是利用预测的草稿接受率和实测硬件吞吐量来调整推测验证长度，使批次更加规整，而不是让慢速副本决定完成时间（技术分析）。
缓存核算：一份部署报告摘要称，每台预填充加速器每秒处理 150 万输入 token，包含缓存命中；在 96% 缓存命中率下，不含命中时为每秒 6 万。解码报告为每台加速器每秒 1.4 万输出 token。这些是实质不同的吞吐量指标（报告摘要）。
经济性说明：同一摘要将每加速器小时约 38 美元描述为收入，而非利润。服务器、电力、冷却和人员成本不包含在该数字内。
独立基准测试仍存争议：SemiAnalysis 表示，DeepInfer 未出现在 InferenceX 中，因为缺少关键服务组件，且重建这些组件需要过多假设。其随后的盈利能力比较因混合硬件代际、峰值与非峰值价格、以及收入与利润而受到批评。该批评本身是归属明确的分析，而非已确定的复现结果；实际要求是在比较经济性之前，匹配硬件、工作负载、缓存假设、SLO 和定价（基准局限性，比较批评）。
TorchTPU 开辟原生 PyTorch 路径：Google 开源了 TorchTPU，可通过熟悉的 PyTorch 工具链进行训练和推理服务。据报道，SGLang 的插件正在为 Meta 的生产推理提供支持，并支持多个当前的开源模型；其自定义 MegaKernel 在 8K 输入/1K 输出工作负载、批大小为 1 时，声称对 Muse Spark Open 达到 770 个解码 token/s。vLLM-TorchTPU 增加了前缀缓存、投机解码和分离式服务（Google、SGLang、vLLM）。
GTC 强调部署速度和功耗利用率：NVIDIA 的 DSX POD 将 AI 基础设施打包为容器化构建模块，并声称可在数天而非数月内完成容量扩展。更具体地说，Lambda 演示了 19 个 HGX B200 节点在 16 个节点的功耗预算内运行，使用的是 DSX MaxLPS。应将部署时间线视为产品声明，将节点结果视为概念验证，而非已经交付的全集群容量（DSX POD、Lambda 演示）。
评估完整性与智能体工程：衡量测试框架，而不仅仅是模型
医学推理揭示完整性与准确性之间的权衡：Artificial Analysis 修订了 MLCR-AA 的提示词、参考答案和由三个模型组成的评审小组。Sonnet 5.5 和 GPT-6 Astra 以 41.7% 并列，在完整性与准确性双重要求的综合标准下，没有模型超过 42%。Claude 在完整性上领先；OpenAI 在有记录依据的准确性上领先。修订后的分数与之前的方法论不能直接比较（结果、方法论）。
长度混杂因素：一项跨基准分析发现，Claude 的回答长度约为 OpenAI 的 4–6 倍；每增加一个主张，就多一次与记录相矛盾的机会。因此，原始评分标准分数、完整性和长度调整后的质量会产生不同的排名（比较）。
SWE-bench Multimodal 面临消融挑战：一项独立调查认为，v2 并不实质性地需要图像；另一位研究人员强调，在不使用图像的情况下运行该基准是必要的健全性检查。这是对该基准所衡量内容的实质性批评，而非证明其底层编码任务缺乏价值（调查、消融讨论）。
进化的测试框架和接口改进了固定执行器：两篇论文进一步支持了围绕智能体优化环境的论点。
SuperMimic 瞄准更廉价的人形机器人训练：研究人员报告称，使用一块 GPU 训练三小时即可完成 129,514 个动作的训练，而所引用的最先进方案需要 128 块 GPU 训练七天。该机制将学习得到的可微世界模型替代模型与时间反向传播相结合。所声称的 >1,000 倍 GPU 小时缩减针对的是这一运动控制训练方案，而非泛指的机器人学习（结果，机制）。
智能体产品、检索模型与 API 分发
Claude Duet 进入研究预览：Anthropic 开放了一款由 Opus-5.5 驱动的主动式助手的候补名单；据报道，初始访问权限面向美国 Pro 和 Max 用户。示例包括监控 Slack、准备问题以及在收到请求后进行购买。Stripe 描述了 Link 钱包购买以及基于 MCP 的开票、退款和收入分析。可用性处于预览阶段，所提供帖子中未披露单独定价（Anthropic 高管，访问权限，支付集成）。
Retrieval releases target precision and context cost: Cohere launched Rerank 5 in Pro and Fast tiers. Its opt-in Context Focus returns scored passages rather than whole documents, claiming up to 41% lower token consumption while maintaining accuracy. Separately, ParseBench reports NVIDIA’s sub-1B Nemotron 3.5 Parse taking first place across its document-understanding benchmark (Cohere feature, availability, ParseBench).
Kling 4.0 rollout reaches API access: fal initially announced UI/agent access with API support forthcoming; Kling subsequently announced its official API rollout. Claimed improvements center on complex-motion stability, reference consistency and cinematic control. The later announcement supersedes the earlier “API coming soon” status (fal launch, API rollout).
Enterprise model access expands while Claude versions its API: OpenAI announced frontier models and Codex workflows coming to Google Cloud Model Garden. Separately, Anthropic’s API version 2026-10-21 removes temperature, top_p and top_k from Messages; new major SDKs default to it, while 2023-06-01 remains supported. Teams upgrading SDKs should explicitly review migration behavior (Google Cloud distribution, version changes, SDK defaults).
Industry and Governance: Researcher Speech and Public-Benefit Oversight
Non-disparagement clauses draw scrutiny: Posts citing BBC reporting allege that Google employment contracts restrict public criticism indefinitely, discouraging discussion of AI safety and military uses. Former employee accounts and researcher commentary describe a chilling effect. These are attributed contractual and workplace claims; the supplied material includes no company response or legal determination (report excerpts, researcher account).
Anthropic updates benefit governance: Anthropic published its annual Public Benefit Report and appointed experimental physicist and former Harvard science dean Christopher Stubbs to its Long-Term Benefit Trust. This is a governance development, separate from the company’s model evaluations and product launches (report, trust appointment).
Top tweets (by engagement)
NSA: prepare PHP updates; take systems offline if mitigation is impossible — 80,000
OpenAI: coordinated PHP2Shell discovery and remediation — 19,600
OpenAI: Codex skill for checking PHP2Shell exposure — 10,500
Cloudflare CTO: free WAF mitigations are a stopgap—patch PHP — 7,000
Nous Research: Hermes orchestrates robot-training workflow at GTC — 6,400
AI Reddit Recap
/r/LocalLlama + /r/localLLM Recap
1. Open-Source Inference Speedups: DeepInfer, EAGLE-4, RTX 3090 BF16 Unlock
New from DeepSeek - DeepInfer - (Activity: 441): The image is a screenshot of DeepSeek’s X announcement that DeepInfer, its in-house large-scale inference framework, is now fully open source: image, GitHub repo, X post. DeepSeek describes DeepInfer as the production inference stack behind DeepSeek-V4.1-Flash, optimized for high-throughput, low-latency serving to reduce compute cost and energy use; a linked Zhihu source claims a single cluster reaches 155 trillion tokens/day and about $38/card/hour revenue at off-peak pricing. Commenters framed the open-sourcing as unusually aggressive compared with Anthropic, OpenAI, or Meta, with one saying those labs “would never do this.” Some users were still unclear on the practical role of the framework, asking simply: “What do it do?”
A linked Zhihu source claims DeepInfer enables high-throughput, low-latency inference for DeepSeek V4.1 Flash, reporting single-cluster throughput of 155 trillion tokens/day and revenue of $38 per card per hour at off-peak pricing:
https://zhuanlan.zhihu.com/p/2095560295930508953
. Commenters highlighted this as unusually aggressive public disclosure compared with companies like OpenAI, Anthropic, or Meta.
One technical concern was whether DeepInfer is a truly general-purpose inference framework or primarily tuned for DeepSeek’s own model architecture. A commenter noted that flashy framework launches tied to a flagship model often hide architecture-specific optimizations that may not transfer cleanly to other LLMs.
A performance figure mentioned in the thread was roughly 256 tokens/s × 100 users, which commenters characterized as extremely high concurrent serving throughput. The implication is that DeepInfer may be targeting production-scale multi-user inference rather than single-request latency benchmarks alone.
Eagle-4 Released: Faster than DFlash2 & DSpark (Activity: 306): EAGLE-4 is a source-available speculative decoding stack using hardware/workload-calibrated draft trees, with eagle-harness integration paths for SGLang, vLLM, and TokenSpeed; current reported support/benchmarks center on Qwen3.8-27B. The post cites speedups over vanilla decoding of 2.22× for MTP, 2.57× for DSpark, 2.80× for DFlash 2, and 3.59× for EAGLE-4, while the repo reports SPEED-Bench gains on 4× NVIDIA B300 of 3.42× SGLang, 2.83× vLLM, and 3.09× TokenSpeed at single-request concurrency; gains reportedly shrink at higher concurrency (EAGLE-4). Commenters also point to LiLiCorr, used by Nemotron Bolt, as a competing speculative decoder with more granular benchmark reporting (paper). Commenters questioned whether the DSpark/DFlash comparisons are representative because aggregate averages can hide workload sensitivity—e.g. MTP may do better on structured outputs such as code/JSON—and asked for breakdowns by workload type. Another concern was practicality: the EAGLE-4 draft model is reportedly about 3 GB larger than DFlash2, making it less attractive for VRAM-constrained deployments.
Several commenters questioned whether Eagle-4’s reported speedups over DFlash2 and DSpark are representative across workloads. One noted that averaged results may hide large variance, since MTP can perform better on structured-output tasks such as code or JSON, and asked for acceleration broken down by workload type rather than aggregate benchmarks.
A practical deployment concern was raised around memory footprint: Eagle-4’s draft model is reportedly about 3 GB larger than DFlash2, which may make it unsuitable for VRAM-constrained local inference setups already at capacity.
Commenters pointed to competing or adjacent speculative decoding work, especially LiLiCorr, used by Nemotron Bolt, whose paper reportedly provides more granular benchmark analysis: https://arxiv.org/pdf/2608.20530. There was also interest in comparing Eagle-4 against HyperQwen or whether HyperQwen could integrate it: https://github.com/syv-ai/HyperQwen.
Now that 3090 frenzy warning post makes sense. (Activity: 405): The image is a screenshot of an X/Twitter post claiming an RTX 3090 “gpu-unlock” kernel/module can raise BF16 tensor math throughput substantially, e.g. 82→155 TFLOPS for BF16 tensor pipe and 64→99 TFLOPS for cuBLAS BF16 GEMM, allegedly by removing an NVIDIA-imposed limitation on FP32-accumulate tensor ops. In context, the Reddit OP asks whether this explains a prior “3090 frenzy” warning and whether old anti-mining or product-segmentation restrictions might still affect LLM workloads, but commenters note that synthetic BF16/GEMM gains may not translate to real inference/training speedups. Commenters are skeptical of the market-hype angle: one calls predictions of used 3090s becoming more expensive than 5090s “delusional,” while another links a prior refutation arguing the hack has not shown practical workload gains. The dominant view is cautious: the benchmark claims are interesting, but “1.9× faster” may amount to much smaller end-to-end improvements.
Several commenters argued that the rumored RTX 3090 “hack” is being overhyped because the measured benefit appears limited to a narrow workload slice: roughly 10–12% prefill improvement, not a broad 1.9x real-world LLM inference speedup. One linked the prior thread’s top refutation, emphasizing that the apparent low-level BF16 gains do not yet translate into practical end-to-end workloads.
A technical concern raised was that BF16 operations may be only a small fraction of inference time, so accelerating or unlocking BF16 paths on RTX 3090 would have limited impact unless the bottleneck is actually BF16 compute rather than memory bandwidth, KV-cache access, sampling, or other kernels. Another commenter noted adoption would depend on whether the modification can be made safely and remain stable across CUDA and NVIDIA driver updates.
On pricing, commenters were skeptical that used RTX 3090 values would materially spike from this news, arguing that GPU pricing is driven more by broader industry supply contracts and new-card positioning than by niche LLM hobbyist demand. One comparison cited a new Radeon RX 9700-class 32 GB card around ~$2k as potentially better value than an inflated used 3090, though the exact product naming/value claim was not deeply benchmarked in the thread.
2. New Open Models: Ornith-1.5, Flint, Tiny Voice-Cloning TTS
ornith-ai/Ornith-1.5-122B (Qwen finetune) (Activity: 438): Ornith AI released Ornith-1.5-122B, a 122B MoE reasoning model fine-tuned/continued from Ornith-1.0 on a Qwen 3.5 / Gemma-derived lineage, with a self-improvement loop that jointly optimizes task generation, scaffold construction, and solution rollouts via RL rather than using only fixed human-curated tasks. Artifacts include GGUF, unsloth GGUF, and NVFP4 variants; the model card claims strong coding/agentic benchmark performance, 262K context with optional YaRN scaling toward ~1M, and serving support via vLLM/SGLang/OpenAI-compatible APIs plus llama.cpp/Ollama-style GGUF paths. Commenters questioned the choice of a Qwen 3.5 122B base versus newer “Next Flash”-style bases, arguing it may already be behind newer architectures. One technical concern was inference speed: because it is based on Q3.5 122B with A10B active parameters and lacks sparse attention, a commenter estimated it will be roughly 2× slower than Q3.8fn-style models with A6B active parameters.
A commenter notes the finetune is based on Qwen 3.5 122B, implying A10B rather than A6B behavior for q3.8fn users and no sparse attention, which they estimate will make inference roughly 2× slower for that setup.
There is technical skepticism about the base-model choice: one commenter asks why it was not built on Ornith Next Flash, arguing that while Qwen 3.5 is a strong base, it has been “left in the dust” relative to newer alternatives.
RecursiveSI/flint (40B A2.5B) · Hugging Face (Activity: 784): RecursiveSI/flint is an Apache-2.0 decoder-only MoE coding-agent model on Hugging Face, with 39.8B total parameters but only ~2.5B active per token. It uses 49 layers, 256 routed experts per MoE layer with 6 selected per token, mixed sliding-window/full attention, and a documented 262k context; Recursive reports 54.9% on Terminal-Bench 2.1, 89.7% on SWE-bench Pro v2, and 74.2% on SWE-bench Verified, targeting SGLang serving on B300/H200 GPUs with OpenAI-compatible tool use. Commenters framed it as roughly the “35B-A3B” class model people wanted from Qwen 3.8, but noted that the existence of Qwen3.8-27B makes the release feel less surprising; otherwise, the benchmark screenshot was the main technical discussion point.
Commenters position Recursive Flint as a 40B MoE with only 2.5B active parameters, roughly matching the class of “35B-A3B” sparse models some users wanted, but now competing against newer small-active MoEs like Qwen3.8-27B. The thread notes that without Qwen’s recent release, this would likely be viewed as a much more significant drop.
A technical NVIDIA GTC Berlin announcement frames Flint as a local coding model optimized for RTX Spark, claiming over 220 tokens/s on a 64GB RTX Spark and strong results on agentic coding benchmarks including SWE-Bench Pro v2, Terminal-Bench 2.1, and SWE-bench Verified: https://blogs.nvidia.com/blog/local-ai-gtc-rtx-dgx-spark-station-sync/
NVIDIA says Flint was built using Recursive’s Eureka Machine, an automated AI research loop that proposes ideas, implements them, runs experiments, and selects follow-ups. The cited post claims this system produced specialized kernels that improved Flint generation speed on RTX Spark by 55% without changing model weights, and notes Apache 2.0 open weights plus support for post-training via NeMo Automodel SFT/LoRA and NeMo RL GRPO.
Pocket TTS which supports voice cloning is now just 1.9 million parameters (Activity: 561): Kyutai released Pocket TTS-small, compressing a CPU-real-time voice-cloning TTS stack from ~100M parameters down to 18.2M, 6.9M, and 1.9M variants. The compression pipeline uses distillation from a ~300M teacher, single-pass baked-in classifier-free guidance, a PCA-derived 64-D backbone–head latent interface, structured transformer pruning, separate backbone/head/codec distillation, and optional reward fine-tuning; reported CPU throughput reaches ~9.9× real time for the 18.2M model and ~25× real time for the 1.9M model, with the 18.2M model matching or slightly exceeding the original on WER/UTMOS. Commenters focused less on the compression method and more on an apparent profanity filter in the released model/demo—e.g. “What the fuck” being rendered as “What the dee”—though an update says the team fixed the issue. Others asked for more rigorous benchmarks on naturalness, real-time factor, and cross-speaker voice similarity, especially for fully local inference.
Several users reported an apparent text censorship/regression in the TTS output: phrases like “What the fuck” were synthesized as “What the dee”. The top commenter later noted that the team addressed the issue and posted a fix, suggesting it was likely an unintended model/tokenization/filtering behavior rather than a permanent policy choice.
A commenter highlighted that the headline parameter count—1.9M parameters—is impressive, but asked for concrete evaluation data: naturalness, real-time factor, and voice similarity across speakers. They emphasized that tiny TTS models are most compelling when they can maintain fully local inference without sacrificing speaker cloning quality.
One user reported poor non-English language support, claiming non-English inputs were effectively rendered as English rather than the target language. This suggests multilingual capability may be weak or absent despite any broader TTS/voice-cloning claims.
3. AI Hardware Supply Crunch: Nvidia Orders and HBM/DRAM Pricing
EXCLUSIVE: ByteDance, Alibaba, Tencent place over $35 billion worth of Nvidia chip orders (Activity: 1047): Reuters reports that ByteDance, Alibaba, and Tencent have placed >$35B in Nvidia chip orders (Reuters). The Reddit post frames this as China ordering roughly 3M RTX PRO 5500 cards at about $11,400 each, likely targeting LLM inference and AI video generation, while a quoted source says Nvidia may fulfill only 5–10% of requested quantities and can produce at most 3M RTX PRO 5500 cards globally in 2027 versus > 6M requested by Chinese customers. Commenters argue that supply constraints mean the headline order volume is unlikely to be fully delivered, and some speculate Nvidia may deprioritize lower-margin workstation-class cards as datacenter demand dominates. There is also skepticism that future GPU generations will make current RTX PRO cards affordable for local LLM users, though some hope datacenter refresh cycles could depress used-market prices.
Commenters highlighted a reported severe supply mismatch: Nvidia may allocate only 5%–10% of requested quantities to partners, with one source saying it can produce no more than 3 million RTX PRO 5500 cards globally in 2027 while China customer orders exceed 6 million. This implies the $35B+ order book may be heavily supply-constrained rather than fully deliverable demand.
A pricing correction noted the implied unit cost is about $11,400 per card, not $11.40, aligning the order size with high-end professional/datacenter GPU pricing. Another technical concern was that high-margin enterprise demand could make even cards like the $16,000 RTX 6000 Pro less attractive for Nvidia to prioritize versus datacenter allocations.
Several commenters inferred that GB202-class silicon may be diverted toward professional or export-compliant SKUs such as RTX PRO cards, reducing availability for consumer GPUs like the RTX 5090. The underlying concern is that datacenter/professional demand could continue to crowd out gaming GPU supply until newer generations shift demand away from current silicon.
Be prepared, GPU price increase incoming --> Samsung sells out 100% of all 2027 HBM capacity - HBM prices expected to jump 200% next year, DRAM prices expected to see a double-digit price increase (Activity: 1227): GSMArena reports that Samsung has allegedly pre-sold roughly 70% of next year’s general-purpose DRAM output and 100% of its HBM capacity under large multi-year contracts with big-tech customers. The resulting memory supply crunch is expected to push HBM prices up 150–200% and DRAM prices by double digits in Q1 2027, increasing BOM pressure for GPUs/AI accelerators and downstream devices such as future Galaxy phones. Commenters expect the HBM squeeze to worsen consumer/local-AI GPU affordability, while noting the dependency loop: frontier models require hyperscaler GPU clusters, but local inference users compete for the same constrained memory supply. Some argue scarcity may force optimization toward smaller, more efficient models and longer hardware lifecycles.
Several commenters connect the reported Samsung 2027 HBM sellout and expected HBM/DRAM price hikes to worsening economics for local AI hardware: local inference users need GPUs, but hyperscalers and AI labs are simultaneously absorbing supply for training and datacenter expansion. One commenter notes that GPU acquisition appears to be accelerating even before matching datacenter capacity is built, implying inventory stockpiling could keep consumer/prosumer GPU supply constrained for years.
A technical-economic point raised is that the break-even point for local AI rigs vs. cloud inference has shifted outward as GPU and memory prices rise while some cloud AI services have become cheaper. The commenter specifically argues this is amplified by MoE models, since datacenters can multiplex sparse expert activation across many users more efficiently than an individual local machine can justify with expensive VRAM-heavy hardware.
One commenter argues that hardware scarcity may push model-side optimization, incentivizing smaller, more efficient models rather than simply scaling parameter counts and memory bandwidth. The implication is that high HBM/GPU prices could accelerate work on compression, quantization, distillation, sparse architectures, and improved inference efficiency.
When will we see these changes? --> China Is Doubling RAM Production to Keep Everyday Gadget Prices from Skyrocketing (Activity: 402): The post asks when consumers will see price effects from China reportedly doubling RAM/DRAM production, likely via domestic suppliers such as CXMT, in response to rising memory demand. Top technical comments argue the effect will be gradual: new DRAM capacity ramps over quarters/years, is absorbed by latent demand in areas like edge compute and datacenters, and may mainly reduce the rate of price increases rather than create an obvious consumer price drop. Commenters are skeptical that global buyers will see near-term savings: one view is that Chinese output will mostly satisfy domestic Chinese demand, reducing China’s imports rather than flooding export markets. Another argues manufacturers will not abandon high-margin enterprise/datacenter sales for low-margin consumer DRAM, so end-user gadget prices may remain elevated.
Several commenters emphasized that additional DRAM capacity will appear gradually rather than as a visible price drop: new fabs ramp over years, and added supply may be absorbed by latent demand from edge compute, datacenters, and consumer devices. One prediction was that the main near-term effect is slower price inflation rather than cheaper RAM, because vendors are unlikely to abandon high-margin enterprise/AI demand for low-margin consumer sales.
A detailed supply-chain comment cited CXMT’s target of 600,000 wafers/month by 2028 as the relevant timescale, arguing that memory capacity expansions triggered by the AI boom will start arriving from late 2025 onward and continue through 2030. The commenter also noted parallel global expansions: U.S. fabs in New York, Idaho, and Indiana tied partly to the CHIPS Act; Samsung adding 4th and 5th facilities at its memory hub; and SK Hynix investing roughly 35 trillion won in its Y2 plant plus 19 trillion won in its F17 fab.
Another technical/economic point was that China’s increased DRAM output may primarily displace imports rather than flood global consumer markets: CXMT could satisfy domestic Chinese demand first, especially with aggressive datacenter construction. Commenters framed memory manufacturing as highly cyclical and capital-intensive, where overbuilding can turn record profits into bankruptcy because trillion-dollar-scale fabs cannot be quickly repurposed or liquidated if demand falls.
Less Technical AI Subreddit Recap
/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo
1. Claude Agents for Personal and Data Workflows
Claude Duet: Anthropic just casually dropped the personal assistant calling it a proactive agent. This is the response to Muses, Bots and Dots (Activity: 1306): The image is a screenshot of an X/Twitter announcement from Claude introducing Claude Duet, a research-preview app positioning Claude as a proactive personal agent rather than a purely chat-based assistant. The post claims Duet can surface items needing attention, complete requested tasks asynchronously while the user is away, and request confirmation before acting on the user’s behalf; one commenter notes it will reportedly be available on the $20 plan. Commenters were mixed: one said this matches how they already use Claude and questioned what differentiates Duet from other agent/app concepts like Muses, Bots, and Dots. Another top comment was a non-technical joke and adds no substantive technical context.
Commenters noted that Claude Duet appears to be included in Anthropic’s existing $20/month plan, suggesting Anthropic is positioning the proactive-agent/assistant layer as part of mainstream paid Claude usage rather than a separate enterprise-only product.
Several technical critiques argued that current “assistant” launches from Anthropic/OpenAI-like vendors still look like thin chatbot wrappers over different frontier models, rather than fundamentally new agent systems. Users questioned what differentiates Claude Duet from existing personal workflows using Claude, Muses, Bots, or similar assistant abstractions.
One commenter argued that the missing piece is not necessarily model capability but structured personal-data integration and product orchestration: a useful assistant would need better schemas, context management, and integrations with external services. They suggested the required technology already exists, but needs to be packaged into a coherent assistant experience rather than another generic chat UI.
I used Claude to fix my Samsung TV (Activity: 3894): A user reports using Claude as an interactive agent to diagnose a Samsung TV as Tizen rather than Android, then work around the lack of webcam access by serving a local web page, generating a local-server QR code, and using the phone camera to capture TV screenshots every 4s for visual feedback (QR screenshot). The agent allegedly spent ~30 min changing privacy/telemetry settings, deleting the Samsung advertising ID, disabling unused apps, rearranging icons, then building a custom “Apple TV-style” launcher/home-screen app plus a companion settings app for shortcuts/backgrounds (launcher, settings UI). A top commenter describes a similar custom TV launcher pipeline for guests: pre-arrival preference intake, personalized Plex/media/news surfacing, music/background/welcome screens, itinerary/weather display, and Home Assistant controls for outdoor lights, pool aerator, and misters. Commenters were mainly surprised that the user even attempted this level of autonomous TV debloating/customization with Claude; one framed it as a practical example of agentic UI automation beyond standard coding assistance. The cat-video detour was treated humorously rather than as a technical failure.
A commenter described using Claude to build/replace a Samsung TV launcher with a custom guest-oriented interface: questionnaire-driven personalization for Plex movies, TV/news station presets, background music, weather, itineraries, and local recommendations. They also integrated the launcher with Home Assistant so guests could control outdoor lights, pool aerator, misters, and other smart-home devices directly from the TV home screen.
Another commenter suggested avoiding a custom Claude-driven workflow by installing cleanyourtv, a GitHub project with roughly 15,000 stars aimed at cleaning/debloating smart TVs. They framed it as a faster, lower-token alternative to having Claude manually guide or generate the TV-fixing process.
One technical detail called out was the removal of the TV’s Ad ID, implying the original Claude-assisted fix included privacy/debloating steps rather than only UI tweaks. This was viewed as a notable privacy-oriented modification for a Samsung smart TV.
I replaced my Samsung TV’s home screen with Claude Code (Activity: 1069): The image shows a custom Samsung TV launcher replacing the stock ad-heavy home screen with a minimal web-style interface: clock/date, selected app tiles, console shortcuts, settings, and remote-control hints. The author says Claude Code helped build the launcher and speed iteration by mocking Samsung TV APIs in a laptop browser; Home-button takeover reportedly uses a CleanFrame-like helper that edits undocumented TV settings, tested only on a 2022 Samsung Q70B. Code is available on GitHub, with a longer write-up. Comments were skeptical and polarized: one commenter praised the project as a way to avoid Samsung/LG telemetry and ads, while others suspected spam/scam reposting or dismissed it as repetitive.
Commenters raised privacy/security concerns around proprietary Samsung/LG smart-TV software, arguing that an open-source replacement UI/OS could reduce vendor telemetry and unwanted tracking. One technically relevant caveat was the risk that “vibe-coded” TV firmware or home-screen replacements could brick devices if deployed without understanding the platform’s boot/update constraints.
A security-focused thread warned that encouraging users to run unvetted TV code could create a large attack surface: compromised replacement launchers or scripts could enable synchronized remote control of many TVs, e.g. forcing playback of attacker-chosen video across devices.
One user asked whether replacing the Samsung home screen produced measurable latency improvements, noting that stock TV launchers feel “slow as a pig.” They also referenced using Claude to install Jellyfin, suggesting interest in whether an AI-generated TV launcher could improve responsiveness for local media workflows compared with OEM smart-TV software.
I handed Claude Code a database of 11 million news articles, it found some weird patterns (Activity: 1604): The image is a technical dashboard screenshot, not a meme: it shows CLSTR’s dark-themed “The world right now” map, where a news-ingestion pipeline visualizes current global event volume by country. In the post, the author says the system processes ~100k articles/day from 40k+ sources in 40 languages, clusters them into events, and exposes derived analytics after 11,079,667 articles; the screenshot reports 2,703 events across 161 countries in the last 3 hours and highlights a major cluster, “France implements curfews amid widespread civil unrest,” with 673 articles. The important clarification is that Claude Code did not read 11M full articles; it queried/exported aggregated cluster metadata produced by the author’s pipeline, which uses embeddings, heuristics, and an LLM judging step. Commenters debated whether the methodology supports the claims: one skeptical thread argued Claude likely only wrote heuristic analysis code and that source-selection/clustering biases could dominate the observed patterns. Others were more optimistic, viewing this as an example of LLM agents helping surface large-scale patterns in real-world data.
Several commenters questioned whether Claude Code actually processed 11M articles directly, arguing that full LLM-based analysis at that scale would be prohibitively expensive and slow. A more plausible implementation would be Claude writing auxiliary code or heuristics to aggregate/search the corpus, but commenters warned that such heuristics need to be documented because they may dominate the results.
A major methodological critique was the lack of detail on data collection, source selection, and sampling bias. Commenters noted that if sources came from Google News or another aggregator, the observed patterns could reflect ranking, regionality, click-history personalization, or source-availability bias rather than real media behavior.
Commenters also flagged potential language/source coverage issues, including the claim that unknown-language items were labeled as English and the apparent absence of major non-English corpora such as Russian, Chinese, or Korean. They argued that without source documentation and language-labeling validation, conclusions about global news patterns would be technically weak.
2. Robotaxis and Humanoid Robotics Scale-Up
Waymo’s robotaxis had 95% fewer serious crashes than humans. Now it plans a fleet of 20,000 cars (Activity: 1457): Waymo’s latest safety data reports 271.3M rider-only miles with 0.01 serious-injury/fatal crashes per million miles versus a modeled local human benchmark of 0.21/M, i.e. ~95% fewer serious crashes, plus ~82% fewer injury crashes. An IIHS analysis of 2021–2024 federal crash data over ~50M driverless miles found directionally similar reductions—68% fewer police-reportable crashes and 81% fewer injury crashes—but noted reporting limitations and an Austin result that was slightly worse than the human benchmark. Semafor reportedly says Waymo plans to scale from ~4,000 vehicles to 20,000 by end-2027, partly via a $5B debt raise. Commenters debated whether the benchmark is apples-to-apples: supporters argued serious crashes are common enough that the reductions are meaningful and that Waymos are rarely at fault, while skeptics noted Waymo’s current ODD is mostly dense urban, lower-speed, limited-highway driving—unlike rural/suburban or high-speed highway exposure where many severe crashes occur.
A commenter claiming experience in OEM crash-safety engineering argued that the reported Waymo safety results are consistent with a decade of AV studies: human driving is a high-risk daily activity, while autonomous systems have generally shown lower serious-crash rates. They emphasized that the reported metrics appear to be based on total crash volume rather than fault, noting that Waymos are often involved in crashes caused by human drivers rather than being the initiating party.
Another commenter raised an exposure-bias concern: Waymo vehicles reportedly operate mostly in dense urban environments and rarely on highways, where high-speed crashes and severe injuries are more common. They suggested that the 95% fewer serious crashes claim may not generalize to rural, suburban, or frequent highway operation where speeds exceed 50 mph more often.
A commenter noted that Austin-specific crash-rate comparisons may be statistically weak because the study period allegedly included only 2 Waymo crashes there. They argued this sample size is too small to support strong conclusions about whether Waymo is safer or less safe than human drivers in that market.
Unitree’s newest robot: H2-X Kung Fu Legend Guardian (Activity: 3907): Unitree announced the H2-X “Kung Fu Legend Guardian”, apparently a more rugged/high-force H2 humanoid variant, claiming maximum endurance of ~8 hours and framing it as a “serve and guard” platform in its X post. The post contextualizes it alongside other Chinese humanoid combat/entertainment robots, notably Engine AI’s T800, used in fighting-tournament demos per this writeup; the Reddit-hosted video itself was inaccessible due to a 403 Forbidden block. Top comments focused less on specs and more on safety/dual-use concerns, joking that the demo robot appeared to shove a child with more force than a slow car would and sarcastically hoping the technology would not be misused.
3. Open-Source AI Model and Kernel Policy Updates
Fibo 2 Edit is what Klein 3 should’ve been. (Activity: 1189): Reddit user reports Fibo 2 Edit (HF model) as a fast, out-of-the-box “uncensored” image editing model with no observed color drift/quality loss in simple edits, attributing some quality gains to the Flux 2 VAE. They link experimental ComfyUI support via PR Comfy-Org/ComfyUI#17240, but later update that it struggles with complex prompts and multi-reference edits, and is “not better than Qwen, just faster.” Comments frame Fibo 2 Edit as potentially “best edit model so far” largely because it is uncensored, with a side debate implying censorship may degrade model utility. Another commenter highlights rapid open-weight image-model progress, citing upcoming/available models like Ideogram 4, Krea 2, Qwen 2.1, LTX, and quantized Hunyuan Image 3 running in ComfyUI on consumer hardware.
Users highlight Fibo 2 Edit as a strong image-editing model and note that it is reportedly uncensored, with one commenter claiming it is the “best edit model so far.” The discussion frames this as part of a broader trend where less-restricted image models are perceived to outperform more heavily filtered alternatives in practical editing quality.
A technically relevant limitation was reported around output resolution: Fibo 2 Edit allegedly downscales source images to roughly 1MP, then processes them through the Flux 2 VAE, causing blurry results. This suggests the model or current pipeline may be bottlenecked by preprocessing/VAE resolution handling rather than edit semantics alone.
Commenters mention interest in ComfyUI support and broader open-weight ecosystem momentum, citing models such as Ideogram 4, Krea 2, Anima, Qwen 2.1, Moss Image, Ming Image, Minimax H3, LTX, and Hunyuan Image 3 quantized. The latter is noted as potentially runnable in ComfyUI on consumer hardware, implying quantization is making larger image models more accessible locally.
As of 3 hours ago, the Linux Kernel no longer requires the usage of AI to be declared for new code submissions. (Activity: 1071): A screenshot of torvalds/linux shows commit 14c8977 by Linus Torvalds, merging Linux documentation updates that include removal of the prior “Assisted-by” requirement for new kernel submissions. In context, this means contributors no longer need to explicitly declare AI assistance when submitting code to the Linux kernel, shifting the policy away from mandatory AI-use disclosure. Comments were split between approval and anticipated backlash: one commenter argued that assumptions like “AI code is all slop” are outdated, while another expected a community meltdown. A practical commenter suggested they might now submit a long-standing local driver fix using Claude, implying the change could lower the barrier for some contributors.
One commenter notes they have been carrying a local kernel patch across releases for a recurring driver bug affecting some motherboards with a specific chip, and the relaxed AI-disclosure rule may make them more likely to upstream the fix using Claude. The technical implication is that reducing disclosure/process friction could increase submissions of small, hardware-specific fixes that otherwise remain private local patches, though the comment does not identify the driver, chipset, or exact bug.
来源：Latent Space · latent.space