OpenAI 的 Patch the Planet 計劃以 GPT-5.6 Sol 發現 PHP2Shell 漏洞，Wiz 亦獨立發現；漏洞影響 70% 網絡，修補協調近兩個月

約兩個月前，OpenAI 推出 Daybreak for Frontline Defenders，提供 $1B 補貼，讓用戶使用 Daybreak 網絡安全模型及產品。這筆資金幾乎立即派上用場：PHP 的重大漏洞由兩方各自獨立發現。Ryan Austin 是安全公司 Calif 的研究人員，他在 2026 年 8 月參與 OpenAI「Patch the Planet」項目時，使用 GPT 5.6 Sol 發現了漏洞：

……此外，最近被 Google Cloud 收購的 Wiz 也有發現（使用 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 表示，在公開披露前曾進行約兩個月的協調修復工作。 OpenAI 表示，修補程式需要對 PHP 引擎作出重大改動，並由維護者、研究人員、安全服務供應商及政府協調合作。一名參與研究人員確認曾與 PHP Foundation 合作，支援並強化修補程式。@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 Foundation 直接發布的安全公告、確切的修正版本對照表、發行版套件識別碼或修補程式提交記錄。缺少這層第一手來源，便無法可靠地指示用戶「升級至 X 版本」。@sagitz_、@NSACyber、@OpenAI

5. 有關資料提早外洩及服務大範圍中斷的説法。
The Rundown 報道，相關細節提早外洩。其後一則廣泛流傳的彙整內容補充稱，有約 150 萬部伺服器仍在運行未修補版本，數字歸因於 Censys；荷蘭機構、歐洲其他地方的政府網站、Wikipedia、Archive.org、Asana、GOG 等據報關停；日本首相則於05:55發出警告。所提供的材料中，沒有相關公告、測量結果或服務狀態頁面可佐證上述任何個別説法。材料亦無法證明每宗服務中斷究竟是預防措施、修補期間的中斷、無關故障，還是遭到入侵。@TheRundownAI、@fiveoutofnine

SemiAnalysis 另有報道稱，日本首相曾敦促 PHP 系統營運者立即修補；如無法修補，則暫時斷開連線。該報道將這項回應置於日本當時已有一波網絡入侵事件的背景下，但並未證明 PHP2Shell 導致了那些較早發生的事件。@SemiAnalysis_

6. 披露漏洞後提供了協助檢查暴露情況的工具。
OpenAI 發布了一個程式碼儲存庫，內含一項Codex 技能，旨在引導網站管理員檢查網站是否受影響。這是一套協助流程，不能取代供應商的安全公告、套件驗證，也不能證明所有有漏洞的執行環境均已更換。@OpenAI

AI 的角色：可信證據、功勞歸屬各有説法，以及尚未釐清的因果關係

支持其實際成效的論據，遠較單靠基準測試的説法有力。研究人員描述了可運作的漏洞利用鏈、協調修補程式開發、偵測工具及修補程式驗證。一名參與其中的研究人員稱，PHP2Shell 是他曾協助發現的漏洞中影響最重大的。OpenAI 將此事形容為「防守者窗口」的例子：先進模型在攻擊者之前發現漏洞，讓防守者有時間作好準備。值得注意的是，OpenAI 的措辭是「據我們所知」，這並不能證明此前沒有攻擊者知道這些漏洞。@itszn13、@OpenAI

功勞分散於人類、模型及基礎設施供應商之間。 Calif/OpenAI 和 Wiz/Gemini 分別被列為獨立的發現來源；PHP 維護者提供了上游修復途徑；Cloudflare 則提供了預發布過濾。Google 亦宣傳 Wiz 的一項測試，當中 Gemini 4 Argon 發現的漏洞數量超過基準模型的兩倍，但所提供的宣傳貼文沒有披露數據集、基準模型、預算或誤報統計。這並非對 PHP2Shell 發現表現的獨立比較評估。 @TheRundownAI, @ralucaadapopa, @Google

研究人員存取權限政策同時引來讚揚和批評。 一名研究人員將涵蓋 PHP、GitLab、Chrome、WordPress 及其他目標的一系列發現，歸功於 OpenAI 的 Daybreak 存取權限。另一名研究人員強烈對比 OpenAI 經審核的存取權限與 Anthropic 的限制；聲稱 Anthropic「毫無貢獻」是該作者以偏概全的個人看法，PHP 相關紀錄並未證實這一點。另一則貼文批評 Astra 存取權限受限，並主張向1,000 名經審核的研究人員提供最好的可用模型並進行嚴密監察，而非採取僵化的紅隊／藍隊區分。 @S1r1u5_, @migtissera, @S1r1u5_

另一種安全考量見於相關報道：Anthropic 延後 Mythos 級模型的廣泛存取四個月，以加強網絡安全防護措施。這為限制存取提供了背景，但無法定論其做法在這次特定修復工作中究竟有所助益還是造成阻礙。 @kimmonismus

披露事件激增本身，並不足以證明由 AI 引發的入侵事件也隨之激增。 所提供的資訊流涵蓋防禦性漏洞發現、供應鏈攻擊、憑證盜竊、預防性停機，以及無關的漏洞。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 月起由每月約 4,000 宗增至 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 修補方案分開看待。使用密碼管理工具、為不同帳戶設定獨特密碼、啟用強效多重驗證、安裝修補程式、採用電訊商防止電話號碼被轉出的保障措施，以及美國特有的信貸或税務身份防護措施，都有助減低後續損害。但啟用 2FA 並不能防止未經驗證即可利用的 PHP 引擎漏洞。同樣，網上流傳的「翌日避免所有網上付款」建議，並無經證實的影響範圍評估支持。@peterwildeford、@StillMare_

更廣泛的威脅背景確實存在，但不能與 PHP2Shell 混為一談。SemiAnalysis 報道，自 9 月 25 日起，有18 間日本公司披露資料外洩事件，其中包括約660 萬個 Times Car 帳戶、1,118 萬筆 Burger King Japan 應用程式記錄，以及可能涉及2,250 萬筆 Sourcenext 記錄的資料外洩。報道將有關 AI 輔助掃描及 API 攻擊的調查結果歸於 JPCERT/CC。另一則帖文引述一份 8 月 19 日的公告，內容涉及利用 AI 輔助工具攻擊連接互聯網的 Siemens PLC。這些是分開報道的事件及公告，兩者都不能證明 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 將其定位為裝置端方案，用以補充而非取代前沿雲端 Agent（發布公告、規格）。

  • 宣稱的成績：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。另有用戶使用 int4 MLX 在 M5 Max 上測得每秒輸出 114–132 tokens；這可作為速度方面的有用佐證，但並非受控的能力評估（本機測量）。

  • 研究貢獻：Recursive 表示，其 Eureka Machine 參與構思、實作及驗證各階段，並貢獻稀疏架構設計、低位元訓練及核心程式。該公司聲稱尺寸縮減 71%，品質幾乎沒有損失，並在不足四個月內從零開始完成開發（方法）。

  • 可用情況：推出首日已整合本機框架，並提供託管存取。vLLM 表示，在單部 GB200 上以 NVFP4 執行、上下文長度為 100K，且不使用推測解碼時，速度達 500 tokens/s；OpenRouter 則在推出時免費開放使用（vLLM、OpenRouter）。

• Mirendil 聲稱一名研究員即可大規模預訓練模型：Mirendil 表示，首個基礎模型由一名研究員在 3.5 個月內完成，運算開支少於 $10M，當中包括研究實驗及最終運算。該公司披露了異常寬泛的參數規模範圍，而非精確配置：Base 為 100B–500B、Large 為 500B–2T、XL 為 2T–10T。獨立評估、後訓練結果及 API 存取仍有待公佈，因此這項重大效率聲稱仍待外部驗證（公告）。

• JOLT 聯合訓練教師與學生模型：Perplexity 與 NVIDIA 的後訓練研究，旨在解決自我蒸餾的一項弱點：具備特權資訊的教師模型可能利用學生模型無法使用的捷徑。JOLT 以結果獎勵訓練教師模型，同時懲罰其與學生模型之間過度偏離。作者表示，JOLT 使用少 6.5× 的訓練 tokens，在 MATH 上達到與 GRPO 相當的表現；加入學生模型結果獎勵的 JOLT+，則在五項已評估基準測試中均勝過 GRPO（方法及結果、基準測試摘要）。

• GPT-Rosalind 生成可供測試的生物學假説：OpenAI 表示，數千個代理在 32 分鐘內，將數百萬個小鼠腦細胞的基因表達結果與文獻連結起來。其中一項提出的機制，將 DCTN1 受幹擾與膽固醇運輸受損聯繫起來；另一項則探討小腦神經元中的 TSC1 與 TSC2 受幹擾後有何差異。這些是假説，供後續實驗研究，並非已證實的療法或已驗證的藥物靶點（DCTN1 研究、TSC2 後續研究）。

推理系統：DeepInfer 的經濟效益、原生 TPU 支援及電力感知容量

• DeepInfer 公開生產環境排程技術：DeepSeek 發布的框架結合推測解碼、動態預填充規模設定、按請求數量及 KV 長度平衡解碼，以及將 CPU 排程與 GPU 執行重疊。當中一項特別值得沿用的做法，是根據預測的草稿接受率及實測硬件吞吐量調整推測驗證長度，令批次更規整，而非讓較慢的副本決定完成時間（技術分析）。

  • 快取計算：一份部署報告摘要指出，每部預填充加速器的輸入吞吐量為 1.5M 輸入 tokens/s（包括快取命中）；快取命中率為 96% 時，不計命中則為 60K。據報解碼吞吐量為每部加速器 14K 輸出 tokens/s。這些吞吐量數據有實質差異（報告摘要）。

  • 經濟效益注意事項：同一份摘要將每加速器小時約 $38 列為收入，而非利潤。伺服器、電力、冷卻及人手成本均未計入該數字。

• 獨立基準測試仍存爭議：SemiAnalysis 指出，DeepInfer 未出現在 InferenceX 中，因為缺少必要的服務元件，而重建這些元件需要作出過多假設。其後的盈利能力比較亦因混用不同世代的硬件、尖峯與非尖峯價格，以及收入與利潤而受到批評。這項批評本身是有來源歸屬的分析，並非已成定論的重現結果；比較經濟效益前，實際要求是統一硬件、工作負載、快取假設、SLOs 和定價（基準測試限制、比較分析批評）。

• TorchTPU 開拓原生 PyTorch 路徑：Google 開源 TorchTPU，讓用戶透過熟悉的 PyTorch 工具進行訓練和服務。據報，SGLang 的外掛正為 Meta 的正式環境推理提供支援，並支援多款現有開放模型；其自訂 MegaKernel 在批次大小為一、輸入 8K／輸出 1K 的工作負載下，Muse Spark Open 的解碼速度據稱達到 770 tokens/s。vLLM-TorchTPU 加入前綴快取、推測解碼及解耦式服務（Google、SGLang、vLLM）。

• GTC 著重部署速度與電力運用：NVIDIA 的 DSX POD 將 AI 基礎設施整合成容器化模組，相關報道宣稱可在數天而非數月內擴充容量。更具體而言，Lambda 展示了 19 個 HGX B200 節點使用 DSX MaxLPS 運作，功耗仍在 16 個節點的電力預算內。部署時間表應視為產品宣稱，節點測試結果則應視為概念驗證，而非已交付整個機羣的容量（DSX POD、Lambda 示範）。

評估完整性與 Agent 工程：衡量執行框架，而不只是模型

• 醫療推理揭示完整性與準確度之間的取捨：Artificial Analysis 修訂了 MLCR-AA 的提示詞、參考答案及由三個模型組成的評審小組。Sonnet 5.5 和 GPT-6 Astra 同以 41.7% 並列，在同時要求完整性與準確度的標準下，沒有模型超過 42%。Claude 在完整性方面領先；OpenAI 在以紀錄為依據的準確度方面領先。修訂後的分數不能與先前方法得出的分數直接比較（結果、方法）。

  • 長度混淆因素：一項跨基準測試分析發現，Claude 的回答約比 OpenAI 長 4–6 倍；每增加一項主張，就多一次與紀錄內容矛盾的機會。因此，原始評分準則分數、完整性及經長度調整的質素，得出的排名各有不同（比較）。

• SWE-bench Multimodal 面臨消融測試質疑：一項獨立調查認為，v2 並未真正要求使用圖片；另一名研究人員則指出，不使用圖片執行基準測試，是必要的基本合理性檢查。這是對基準測試所衡量內容的實質質疑，並非證明其底層編碼任務沒有價值（調查、消融測試討論）。

• 改良執行框架與介面可提升固定執行器的表現：兩篇論文進一步支持優化 Agent 周邊環境的觀點。

  • OO-Harness：專門化子類別、從執行結果得出的設計經驗及路由機制，令 AutomationBench 在使用同一個 Gemini 3.5 Flash 執行器下，得分由 61.6% 升至 77.4%；Workspace-Bench 則由 25.5% 升至 39.5%（論文摘要）。

  • Agent S4：元代理利用沒有成功標籤的軌跡建構工具。據報告，open-27B 在 OSWorld V2 的成績達 21.3%，是同一模型配合手工建構介面時的 3.8 倍；ScienceBoard 的成績則由 41.4% 升至 58.6%。這些是論文報告的系統結果，並非只比較模型的結果（摘要）。

• SuperMimic 旨在降低人形機械人訓練成本：研究人員報告，使用一張 GPU、耗時三小時，便以 129,514 段動作進行訓練；相比之下，文中提及的最先進設定使用 128 張 GPU，耗時七天。其機制結合經學習且可微分的世界模型替代模型，以及時間反向傳播。所稱 GPU 小時用量減少超過 1,000 倍，僅適用於這套動作控制訓練設定，並非泛指機械人學習（結果、機制）。

Agent 產品、檢索模型與 API 發佈

• Claude Duet 開放研究預覽：Anthropic 為一款由 Opus-5.5 驅動的主動式助理開放等候名單；據報，初期開放予美國 Pro 和 Max 用戶使用。示例包括監察 Slack、準備問題，以及按要求代為購物。Stripe 介紹了使用 Link 錢包購物，以及透過 MCP 開立發票、退款和分析收入。現時仍處於預覽階段，所提供的帖子沒有披露額外定價（Anthropic 高層、使用權限、支付整合）。

• 檢索產品更新着重準確度與上下文成本：Cohere 推出 Pro 和 Fast 版本的 Rerank 5。可選啟用的 Context Focus 會傳回帶評分的段落，而非整份文件；據稱在維持準確度的同時，最多可減少 41% 的 token 用量。另一方面，ParseBench 報告指出，NVIDIA 的 sub-1B Nemotron 3.5 Parse 在其文件理解基準測試中排名第一（Cohere 功能、供應情況、ParseBench）。

• Kling 4.0 推出 API：fal 最初宣佈可透過 UI／Agent 使用，並表示 API 支援即將推出；其後 Kling 宣佈正式推出 API。據稱，改進主要包括提升複雜動作的穩定性、參考內容一致性及電影感控制。後來的公告取代了較早前「API 即將推出」的狀態（fal 推出公告、API 推出公告）。

• 企業模型使用渠道擴展，Claude API 更新版本：OpenAI 宣佈，前沿模型及 Codex 工作流程將於 Google Cloud Model Garden 提供。另一方面，Anthropic 的 API 版本 2026-10-21 從 Messages 移除 temperature、top_p 及 top_k；新主要版本的 SDK 預設採用此版本，而 2023-06-01 仍獲支援。升級 SDK 的團隊應明確檢視遷移行為（Google Cloud 發佈渠道、版本變更、SDK 預設設定）。

行業與管治：研究人員發聲與公益監督

• 禁止貶損條款引起關注：引述 BBC 報道的帖子指稱，Google 的僱傭合約無限期限制公開批評，阻礙有關 AI 安全及軍事用途的討論。前員工的説法及研究人員的評論形容，這造成寒蟬效應。這些是有來源歸屬的合約及職場指稱；所提供的材料沒有公司回應或法律裁定（報道摘錄、研究人員説法）。

• Anthropic 更新公益治理：Anthropic 發表年度 Public Benefit Report，並委任實驗物理學家、哈佛大學前科學院院長 Christopher Stubbs 加入其 Long-Term Benefit Trust。這是治理方面的發展，與公司的模型評估及產品發布分開（報告、信託委任）。

熱門推文（按互動量排序）

1. NSA：準備 PHP 更新；如無法緩解風險，便將系統下線 — 80,000

2. OpenAI：協調發現及修復 PHP2Shell — 19,600

3. OpenAI：用於檢查 PHP2Shell 風險的 Codex 技能 — 10,500

4. NVIDIA：Microduck 模擬轉真實環境示範 — 7,800

5. Richard Socher：Flint 本地編碼模型發布 — 7,600

6. OpenAI：GPT-Rosalind 對神經退化的假設 — 7,500

7. Cloudflare 技術總監：免費 WAF 緩解措施只是權宜之計——修補 PHP — 7,000

8. Nous Research：Hermes 在 GTC 協調機械人訓練工作流程 — 6,400

AI Reddit 摘要

/r/LocalLlama + /r/localLLM 摘要

1. 開源推理提速：DeepInfer、EAGLE-4、RTX 3090 解鎖 BF16

• DeepSeek 最新消息—DeepInfer—（活動量：441）：圖片是 DeepSeek 在 X 上發布的公告截圖，宣佈其內部開發的大型推理框架 DeepInfer 現已完全開源：圖片、GitHub 儲存庫、X 貼文。DeepSeek 表示，DeepInfer 是支援 DeepSeek-V4.1-Flash 的生產推理堆疊，經過最佳化，可提供高吞吐量、低延遲的服務，從而降低運算成本及能源使用；一個連結的知乎來源聲稱，單一叢集可達到155 trillion tokens/day，並在離峯時段定價下帶來約$38/card/hour收入。評論者認為，與Anthropic、OpenAI 或 Meta相比，這種開源做法異常進取；有一位評論者表示，這些實驗室「絕不會這樣做」。部分用戶仍不清楚這個框架的實際用途，只問：「這是做甚麼的？」

  • 一個連結的知乎來源聲稱，DeepInfer 可為 DeepSeek V4.1 Flash 提供高吞吐量、低延遲的推理服務，並指出單一叢集在離峯時段定價下的吞吐量為 155 trillion tokens/day，收入為 $38 per card per hour：

https://zhuanlan.zhihu.com/p/2095560295930508953

• • . 評論者指出，與 OpenAI、Anthropic 或 Meta 等公司相比，這種公開披露的做法異常進取。

  • 其中一個技術疑問是，DeepInfer 究竟是真正通用的推理框架，還是主要針對DeepSeek 自家的模型架構進行調校。一位評論者指出，與旗艦模型掛鈎的矚目框架發布，往往掩蓋了架構專屬的最佳化，而這些最佳化未必能順利應用於其他大型語言模型。

  • 討論串提到的一項效能數據約為 256 tokens/s × 100 users，評論者形容其並行服務吞吐量極高。這意味 DeepInfer 的目標或許是大規模生產環境中的多用戶推理，而不只是單一請求的延遲基準測試。

• Eagle-4 發佈：速度快於 DFlash2 和 DSpark（活動：306）：EAGLE-4 是一套原始碼可取得的推測解碼技術堆疊，使用按硬件／工作負載校準的草稿樹，並提供 eagle-harness 整合方式，支援 SGLang、vLLM 和 TokenSpeed；目前公佈的支援情況和基準測試主要集中於 Qwen3.8-27B。貼文列出的相較於標準解碼的加速幅度為：MTP 2.22×、DSpark 2.57×、DFlash 2 2.80×，以及 EAGLE-4 3.59×；而程式碼庫公佈的 SPEED-Bench 測試結果顯示，在 4× NVIDIA B300 上、單一請求並行度下，SGLang 提升 3.42×、vLLM 提升 2.83×，TokenSpeed 提升 3.09×；據報並行度較高時，增幅會縮小（EAGLE-4）。留言者亦提到 Nemotron Bolt 使用的 LiLiCorr，認為它是另一款具競爭力的推測解碼器，而且提供更細緻的基準測試報告（論文）。留言者質疑 DSpark／DFlash 的比較能否代表不同工作負載的表現，因為整體平均值可能掩蓋對工作負載的敏感度——例如 MTP 在程式碼／JSON 等結構化輸出任務上可能表現較佳——並要求按工作負載類型列出細分結果。另一個疑慮是實用性：據報 EAGLE-4 的草稿模型比 DFlash2 大約多出 3 GB，因此對 VRAM 容量有限的部署而言吸引力較低。

  • 有幾位留言者質疑 Eagle-4 相較於 DFlash2 和 DSpark 的加速幅度，能否代表不同工作負載的表現。有人指出，平均結果可能掩蓋很大的差異，因為 MTP 在程式碼或 JSON 等結構化輸出任務上可能表現較佳；他們要求按工作負載類型列出加速幅度，而非只提供整體基準測試結果。

  • 有留言者提出實際部署方面的疑慮：據報 Eagle-4 的草稿模型比 DFlash2 大約多出3 GB，對 VRAM 容量有限、且已達負荷上限的本機推理部署而言，可能並不合適。

  • 留言者提到其他具競爭力或相關的推測解碼技術，尤其是 Nemotron Bolt 使用的 LiLiCorr；據報其論文提供更細緻的基準測試分析：https://arxiv.org/pdf/2608.20530。留言者亦有興趣比較 Eagle-4 與 HyperQwen，或探討 HyperQwen 能否整合 Eagle-4：https://github.com/syv-ai/HyperQwen。

• 現在看來，那則關於 3090 熱潮的警告貼文確實説得通。（活動：405）：圖片是 X/Twitter 貼文的截圖，內容聲稱 RTX 3090 的「gpu-unlock」核心／模組可大幅提升 BF16 張量運算吞吐量，例如 BF16 tensor pipe 達82→155 TFLOPS，cuBLAS BF16 GEMM 達64→99 TFLOPS；據稱這是透過移除 NVIDIA 對 FP32 累加張量運算施加的限制來達成。就上下文而言，Reddit 發文者想知道，這是否解釋了先前有關「3090 熱潮」的警告，以及舊有的反挖礦或產品區隔限制是否仍可能影響 LLM 工作負載；不過，留言者指出，合成 BF16/GEMM 基準測試的效能提升未必能轉化為實際推理／訓練速度提升。留言者對市場炒作的説法持懷疑態度：有人稱預測二手 3090 價格會高於 5090 是「妄想」，另有人連結先前的反駁文章，指出這項破解尚未證明能提升實際工作負載表現。主流看法較審慎：基準測試的説法值得留意，但「速度快 1.9 倍」最終可能只帶來幅度小得多的端到端改善。

  • 有幾位留言者認為，RTX 3090 傳聞中的「破解」被過度吹捧，因為測得的效益似乎只限於一小部分工作負載：預填充效能提升約10–12%，而非普遍適用的1.9x實際 LLM 推理速度提升。有人連結了先前討論串中最熱門的反駁文章，指出表面上的低階 BF16 效能提升尚未轉化為實際端到端工作負載效能。

  • 有人提出一項技術疑慮：BF16 運算可能只佔推理時間的一小部分，因此除非瓶頸確實在 BF16 計算，而非記憶體頻寬、KV 快取存取、抽樣或其他核心程式，否則在 RTX 3090 上加速或解鎖 BF16 路徑的影響可能有限。另一位留言者指出，是否有人採用，取決於能否安全地套用修改，並在CUDA 和 NVIDIA 驅動程式更新後保持穩定。

  • 談到價格，留言者不相信這則消息會令二手 RTX 3090 價格大幅飆升；他們認為，GPU 價格更受整體行業供應合約及新卡市場定位影響，而非小眾 LLM 愛好者的需求。有留言者比較指，一款價格約為~$2k的全新 Radeon RX 9700 級 32 GB 顯示卡，性價比或高於價格被炒高的二手 3090；不過，該討論串並未深入進行基準測試，以驗證其確切產品名稱及性價比説法。

2. 新開放模型：Ornith-1.5、Flint、Tiny Voice-Cloning TTS

• ornith-ai/Ornith-1.5-122B (Qwen finetune)（活躍度：438）：Ornith AI 發佈了 Ornith-1.5-122B，這是一款 122B MoE 推理模型，以 Ornith-1.0 為基礎微調／延續訓練，採用 Qwen 3.5 / Gemma 衍生模型系列；其自我改進循環透過 RL 聯合最佳化任務生成、框架建構及解決方案 rollout，而非只使用固定的人手策劃任務。發佈產物包括 GGUF、unsloth GGUF 及 NVFP4 版本；模型卡聲稱其程式編碼／Agent 基準測試表現出色，支援 262K 上下文，並可選用 YaRN 擴展至約 1M；亦支援透過 vLLM/SGLang/OpenAI 相容 API 提供推論服務，以及 llama.cpp/Ollama 類型的 GGUF 路徑。評論者質疑選用Qwen 3.5 122B作為基礎模型，而非較新的「Next Flash」類型基礎模型，認為它可能已落後於更新的架構。一項技術疑慮是推論速度：由於它基於 Q3.5 122B，有 A10B 個活躍參數，而且沒有稀疏注意力，一名評論者估計其速度會比有 A6B 個活躍參數的 Q3.8fn 類模型慢約 2×。

  • 一名評論者指出，這個微調版本基於Qwen 3.5 122B，意味對 q3.8fn 用戶而言，其表現會是A10B 而非 A6B，而且沒有稀疏注意力；他們估計在這種設定下，推論速度會慢約 2×。

  • 評論者對基礎模型的選擇抱持技術上的懷疑：一名評論者問為何不以Ornith Next Flash為基礎，並認為雖然Qwen 3.5是強大的基礎模型，但與較新的替代方案相比，已「遠遠落後」。

• RecursiveSI/flint (40B A2.5B) · Hugging Face（活躍度：784）：RecursiveSI/flint 是一款採用 Apache-2.0 授權的純解碼器 MoE 程式編碼代理模型，刊載於 Hugging Face；總參數量為 39.8B，但每個 token 僅啟用約 2.5B 個參數。它採用 49 層、每個 MoE 層有 256 個路由專家，每個 token 會選取 6 個，並混合使用滑動視窗及完整注意力；文件列明其上下文長度為 262k。Recursive 報告稱，它在 Terminal-Bench 2.1 上取得 54.9%、在 SWE-bench Pro v2 上取得 89.7%，並在 SWE-bench Verified 上取得 74.2%；目標是在 B300/H200 GPU 上透過 SGLang 提供推論服務，並支援 OpenAI 相容的工具使用。評論者將它形容為大致屬於人們原本希望 Qwen 3.8 推出的「35B-A3B」級別模型，但也指出Qwen3.8-27B已經存在，令這次發布沒那麼令人意外；除此之外，基準測試截圖是討論中主要的技術焦點。

  • 評論者將Recursive Flint定位為一款 40B MoE，只有 2.5B 個活躍參數，大致符合部分用戶期待的「35B-A3B」級稀疏模型；不過，它如今要與Qwen3.8-27B等較新的低活躍參數 MoE 競爭。討論串指出，若沒有 Qwen 最近的發布，這次推出很可能會被視為重要得多的一次發布。

  • NVIDIA GTC Berlin 的一則技術公告將 Flint 定位為一款針對 RTX Spark 最佳化的本地編碼模型，聲稱在一部 64GB RTX Spark 上得分超過 220 tokens/s，並在 SWE-Bench Pro v2、Terminal-Bench 2.1 和 SWE-bench Verified 等代理式編碼基準測試中表現出色：https://blogs.nvidia.com/blog/local-ai-gtc-rtx-dgx-spark-station-sync/

  • NVIDIA 表示，Flint 是使用 Recursive’s Eureka Machine 建立。這是一個自動化 AI 研究循環，會提出構想、實作構想、執行實驗，並選擇後續研究方向。文中聲稱，這套系統產生的專用核心讓 Flint 在 RTX Spark 上的生成速度提升了55%，而且沒有更改模型權重；文中亦指出，Flint 採用 Apache 2.0 開放權重，並支援透過 NeMo Automodel SFT/LoRA 和 NeMo RL GRPO 進行後訓練。

• 支援聲音複製的 Pocket TTS，現在只有 190 萬個參數（活動：561）：Kyutai 發布了 Pocket TTS-small，將可在 CPU 上即時運行的聲音複製 TTS 系統，從約100M個參數縮減至 18.2M、6.9M及 1.9M等參數版本。壓縮流程採用從約300M參數的教師模型蒸餾、單次執行時內建的無分類器引導、由 PCA 推導的 64-D骨幹網絡—輸出頭潛在空間介面、結構化 Transformer 剪枝、分別對骨幹網絡／輸出頭／編解碼器進行蒸餾，以及可選的獎勵微調；據報，CPU 吞吐量可達約9.9×倍即時速度（適用於 18.2M模型），而約25×倍即時速度（適用於 1.9M模型）；18.2M模型在 WER/UTMOS 上與原版相若或略勝一籌。評論者較少關注壓縮方法，更多是留意到已發布模型／示範版中疑似存在粗口過濾功能，例如「搞甚麼鬼」被合成為「What the dee」；不過，更新指出團隊已修正問題。另有用戶要求提供更嚴謹的自然度、即時因子和跨説話者聲音相似度基準測試，尤其是針對完全本地推理。

  • 多名用戶反映，TTS 輸出疑似出現文字審查／退化現象：例如 「搞甚麼鬼」 被合成為 「What the dee」。最受關注的評論者其後指出，團隊已處理問題並發布修正，顯示這很可能是模型、分詞或過濾機制的非預期行為，而非永久性的政策選擇。

  • 一名評論者指出，標題所列的參數量——1.9M個參數——令人印象深刻，但也要求提供具體評估數據：自然度、即時因子和跨説話者的聲音相似度。他們強調，極小型 TTS 模型最具吸引力之處，在於能否在不犧牲説話者複製品質的前提下，維持完全本地推理。

  • 一名用戶反映非英語語言支援欠佳，稱非英語輸入實際上會以英語而非目標語言輸出。這顯示，儘管有更廣泛的 TTS／聲音複製能力宣稱，其多語言功能可能仍然薄弱或欠缺。

3. AI 硬件供應緊張：Nvidia 訂單與 HBM/DRAM 定價

• 獨家：ByteDance、Alibaba、Tencent 下訂價值超過 350 億美元的 Nvidia 晶片（活動量：1047）：Reuters 報道，ByteDance、Alibaba 和 Tencent 已下訂超過 350 億美元的 Nvidia 晶片（Reuters）。Reddit 貼文將此描述為中國訂購約 3M 張 RTX PRO 5500 顯示卡，每張約 $11,400，可能用於 LLM 推理和 AI 影片生成；引述的消息人士則稱，Nvidia 可能只能交付所需數量的 5–10%，並且 2027 年全球最多隻能生產 3M 張 RTX PRO 5500 顯示卡，而中國客戶要求的數量超過 6M。評論者認為，供應受限意味着標題所指的訂單量不太可能全部交付，有些人推測，隨着數據中心需求佔主導地位，Nvidia 可能會降低工作站級顯示卡的優先次序，轉而供應利潤較低的產品。也有人懷疑，未來幾代 GPU 推出後，現有 RTX PRO 顯示卡會否變得足以讓本地 LLM 用戶負擔；但也有人希望數據中心的換代週期能令二手市場價格下跌。

  • 評論者指出，據報供應嚴重不足：Nvidia 可能只會分配 5%–10% 的所需數量給合作夥伴；據一名消息人士稱，Nvidia 在 2027 年全球生產量不會超過 3 million 張 RTX PRO 5500 顯示卡，而中國客戶訂單超過 6 million。這意味着，$35B+的訂單積壓可能受供應嚴重限制，而非代表可完全交付的需求。

  • 有一項價格更正指出，推算每張卡的價格約為 $11,400，而非 $11.40，與高階專業級／數據中心 GPU 的定價相符。另一項技術方面的疑慮是，高利潤企業需求可能令 Nvidia 認為，即使是 $16,000 RTX 6000 Pro 這類顯示卡，與數據中心的供應分配相比也不值得優先供應。

  • 有幾位評論者推斷，GB202 級矽晶片可能會轉用於 RTX PRO 等專業級或符合出口規定的 SKU，令 RTX 5090 等消費級 GPU 的供應減少。根本的憂慮是，數據中心及專業級需求可能會繼續擠壓遊戲 GPU 的供應，直至新一代產品令需求不再集中於現有晶片。

• 做好準備，GPU 價格即將上漲 --> Samsung 售出 2027 年全部 HBM 產能——HBM 價格預計明年上漲 200%，DRAM 價格預計上漲雙位數（活動量：1227）：GSMArena 報道，Samsung 據稱已透過與大型科技客戶簽訂的大型多年期合約，預售明年通用 DRAM 產量約 70%，以及其 HBM 產能的 100%。由此造成的記憶體供應緊張，預計會令 HBM 價格上漲 150–200%，並令 DRAM 價格在 2027 年 Q1 上漲雙位數，增加 GPU／AI 加速器及下游裝置（例如未來 Galaxy 手機）的 BOM 成本壓力。評論者預期，HBM 供應緊張會令消費級及本地 AI GPU 更難負擔；他們亦指出當中的相互依賴：前沿模型需要超大規模雲端服務供應商的 GPU 叢集，但本地推理用戶也要爭奪同樣受限的記憶體供應。有人認為，供應短缺可能會促使業界轉向規模更小、效率更高的模型，並延長硬件的使用週期。

  • 有數名評論者將三星據報 2027 年 HBM 已售罄，以及預期 HBM／DRAM 價格上漲，與本地 AI 硬件成本效益日益轉差聯繫起來：本地推理用戶需要 GPU，但超大規模雲端服務商和 AI 實驗室同時正為訓練和擴建數據中心而大量採購供應。一名評論者指出，GPU 採購似乎在相應的數據中心容量建成之前已加速，這意味著囤積庫存可能令消費級／專業消費級 GPU 供應多年受限。

  • 有人提出一個技術與經濟層面的觀點：隨著 GPU 和記憶體價格上漲，而部分雲端 AI 服務變得更便宜，本地 AI 設備相對雲端推理的損益平衡點已推得更遠。該評論者特別指出，MoE 模型令這個趨勢加劇，因為數據中心可以在多名用戶之間更有效地多路復用稀疏專家啟動；相比之下，個別用戶難以證明購置昂貴且需要大量 VRAM 的硬件是合理的。

  • 一名評論者認為，硬件短缺可能推動模型端最佳化，促使業界採用更小、更高效的模型，而非只增加參數數量和記憶體頻寬。這意味著 HBM／GPU 價格高企可能加快壓縮、量化、蒸餾、稀疏架構及提升推理效率等方面的研發。

• 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.