LLM 已能读写神经网络权重：“权重空间编程”将自主研究踢出 RSI 闭环

编辑 Qwen 权重以减少推理死循环、DeepSeek 的超级 Agent 原型，以及 GDPx 基准。

从抽象层面来看，该演示表明：你可以利用一个足够聪明的模型，通过在计算集群上运行一系列实验，在无需人类专业经验或干预的情况下自主训练模型。然而，这通常需要经历一个复杂的过程：编写 PyTorch/Jax 代码、运行算力、观察 loss 曲线、查阅评估指标、优化算子核心及数据等等……

而上个月的访谈嘉宾 Alex Zhang再次回归，共同带来了一项重磅发现：如果我们直接让一个聪明的模型去读取并编辑一个较弱模型的权重，会发生什么？

如果你相信只要参数量足够，LLM 确实能够拟合和模拟一切（事实上，随着规模扩大，LLM 正在成为越来越优秀的计算器），那么理论上类似的事情必然会发生；但当这种能力突然涌现时，依然令人惊叹，正如一项独立复现研究似乎已经验证的那样：

当然，我们实际建模的对象是某种形式的机械可解释性（这本可以通过人工完成），而且目前来看，它不太可能直接扩展到比简单游戏和强化学习策略更复杂的任务上。但在这一崭新的递归自我改进（RSI）能力上，世界已经完成了从 0 到 1 的跨越……鉴于其惊人的效率，这项技术必将立即被投入实用与探索。

DeepSeek 开源“超级 Agent”（Super-agent）Harness 原型

• 发布：DeepSeek Harness 发布了一篇长篇设计文章（文章）以及 dsh-superagent-prototype 代码库（代码库链接）。随后发布了官方英文版本（@tianyi）。
  • 架构：由一个长期运行的路由会话与人类交互并分派任务。相互隔离的 Worker 并行执行任务，并通过 GitHub 事件触发（总结）。
  • 宣称成果：在 DeepSeek 的内部测试中，相比使用子 Agent 的单会话模式，p95 任务完成时间从 29.5 分钟下降到了 15.7 分钟（总结）。
• 评审员设计思路阐述：最终评审员崔添翼（@tianyi）表示，“超级”（Super）指的是工作 Agent 之上的一层抽象，而非更优越的智能。他将核心权衡归结为跨任务连续性与吞吐量之间的博弈（知乎总结）。
  • 指出的局限：该 harness 尚未内置跨会话的长期记忆能力。状态、计算与环境的解耦基本尚未实现。该原型仅在小型、可信的内部环境中进行了验证，安全性、隐私保护以及 Agent 间通信依然是有待解决的问题。
  • 现有技术：他承认其他团队在数月前就已探索过类似的架构。
• 从业者反响：@badlogicgames 表示该设计契合了 Earendil 的发展方向：单一长寿命实体、即席递归委派以及跨系统事件触发。@omarsar0 称其为协调-执行 harness 设计的“大师课”。DeepSeek 还表示，其目标是在每一代模型中都支持 pi 及其他主流 harness（@tianyi）。
• 批评意见：@teortaxesTex 评价该文“有点像一团乱麻”。他认为 DeepSeek 是在围绕模型弱点（如幻觉）构建内部补丁，而不是让系统具备通用稳健性。他还指出彭博社报道了一个甚至没有英文公告的代码库（推文）。
• V4.1 命名混淆：中国人民大学 FlashRSI 的 README 中提到了 deepseek-v4.1-pro，引发了对新版本发布的猜测。Teortaxes 表示这只是占位符：实际配置使用的是 v4-flash 和 v4-pro，而 deepseek-v4.1-flash 并不是一个有效的 ID（讨论串，后续）。他还指出 V4.1F-1017 的 API 指纹并未改变（指纹详情）。

独立评测与前沿模型动向

• GDPx 基准 (SemiAnalysis)：该基准涵盖 11 个具有重大经济价值领域（包括芯片设计、软件工程 SWE、金融和生物学等）的 206 项 agentic 任务。表现最佳的模型得分仅为 12%（发布详情）。
  • 结果：Opus 5.5 以 12% 领跑。Gemini 4 Carbon 紧随其后达到 10.9%，且成本约低 4 倍（数据解析）。
  • 各方反应：@dylan522p 向 Google 致歉，称 Carbon 虽然“波动较大”，但在某些领域极为强劲。@demishassabis 对该基准表示欢迎。
  • 深度分析：@eliebakouch 发现，剔除受安全护栏影响的基准项后，局面发生了变化。在这一视角下 Carbon 依旧便宜，而 Sol 6.1 则更为低廉。他还推测 OpenAI 在生物领域的安全防护措施比 Anthropic 更加严格（备忘）。
  • 同系列对比：Sol 6.1 与 Astra 得分非常接近，Carbon 全面击败 Argon，而 Sonnet 在软件工程任务上表现亮眼（对比详情）。
  • 潜在 Bug：Argon 的部分网络安全测试可能受到了 Antigravity bug 的影响（报告）。
  • 审计争议：一条讽刺推文吐槽称 GDPx 并非开源项目，且独立审计成本高昂（推文）。
• Epoch 能力指数 (ECI)：DeepSeek V4.1F-1017 得分为 159，与 GPT 5.5 持平。这一成绩比 V4.1F-0910 高出 3 分，比 V4-Pro 高出 10 分；Astra 则高出约 10 分（@teortaxesTex）。
  • 与 Mythos 的差距：@scaling01 指出，历经约 7 个月后，仍未有中国模型能追平 Mythos Preview（约 161 ECI）。
  • 权重算法质疑：@wenhaocha1 认为未经加权的 ECI 夸大了差距；如果提高编程能力的权重，这一差距将缩小至约 2 个月。
  • 性能极化：Teortaxes 称 1017 具有极强的波动性。在某些 SWE 评估中几乎得零分，仅在网络安全与量化交易上逼近前沿水平（图表）。他还指出了其“形似奖励黑客攻击”（reward-hacking-shaped）的行为特征（推文）。
• 10 月发布盘点 (Vals)：Vals 统计了 15 个模型发布及超过 5000 亿 eval tokens（@nikilravi）。
  • 开放权重领跑者：Kimi K3.1 Pro 稳居开放权重模型榜首，DeepSeek V4.1 Flash 1017 紧随其后且在网络安全领域更强。
  • 新型开放模型：Meta 的 Muse Spark Open（总参数 816B，激活参数 42B）是美国能力最强的开源权重模型。Reflection 的 Beam 1.0 拥有 500B 总参数、23B 激活参数和 1M 上下文。Mistral 的 Le Chonk（总参数 1T，激活参数 52B）在开源权重模型中位列第 5。
• 待发布模型传闻（未经证实）：
  • GPT-6.2 Astra：据称已可在 Codex 使用情况分析中看到痕迹，且“很快就会”发布（@kimmonismus，@TokenGremlin）。
  • Mythos 5.5：出现在 Anthropic 网站的 HTML 代码中，网站将 Mythos 描述为“我们在网络安全和生物学研究领域能力最强的模型级别”（爆料，正文）。该宣传标语适用于所有 Mythos 模型（更正说明）。在 10 月 23 日的网页快照中并未包含该描述（@AiBattle_）。
  • “Numbat”泄漏事件：所谓 Anthropic 的泄漏事件极可能是伪造的，因为部分权重与随机初始化完全吻合（@kimmonismus）。

研究进展：表征、领域数据与 Agent 集群

• JEPA 与柏拉图表征假说：Balestriero 和 LeCun 证明，在特定条件下，分别训练的图像和文本 JEPA 会在无需配对数据的情况下收敛至基本相同的表征空间（总结）。
  • 宣称成果：与下一个 token 预测相比，其方案仅需 1/42 的样本量（2160 万 vs 9 亿样本）即可达到相同的图文对齐效果。一个 109M 的文本 JEPA 在跨模态对齐上超越了高达 72B 参数的 LLM（解析）。
  • 底层机制：其宣称的驱动力来自“同一事物的两个视角”这一训练信号，而非模型规模。
• FineDNA 与 Carbon-X (Hugging Face)：该数据集包含超过 3000 亿 token 的基因组序列、论文以及 DNA/文本混合网络数据，外加 20 万条 SFT 样本和约 10 万条带确定性验证器的 RLVR 样本（@_lewtun，@LoubnaBenAllal1）。
  • 效果：基于该数据训练的 Qwen3-14B（Carbon-X）据称为 DNA 任务上最强的开源模型。在 SFT 之上加入 RLVR 带来了进一步的性能提升（细节）。
  • 开源状态：数据集、模型及训练配方均已开源（代码）。
  • 消融实验：交织生物文本训练严格控制在 7 个 epoch 以内（回复）。
• 训练 Agent 群体：GenReasoning 的首篇文章探讨了延迟压力如何倒逼并行处理、Agent 需要何种协同原语，以及训练 Agent 集体时面临的未决问题（博文）。
• 其他值得关注的研究：
  • 从 Attention 到 TTT：苏剑林撰文探讨《平均之路：从 Attention 到 TTT》（博文）。
  • 每周精选论文：DAIR 论文列表收录了 HarnessMM、Agentic Backdoors、EmbeddingGemma 2 以及 Verification in Agent Harnesses（列表）。
• LeCun 谈 Llama-4：LeCun 表示自己从未主导过 LLM 的研发工作。他将 Llama-4 的令人失望归咎于产品压力、保守主义以及决策权脱离了巴黎团队（推文）。

推理系统、量化与硬件

• NVIDIA AgentX 提交方案 (SemiAnalysis)：据报道，由 Agent 群体编写的软件在 700B+ 参数模型上达到了超过 1,000 tok/s/user 的表现（讨论串）。
  • Rubin 对比 GB300：Rubin NVL72 宣称在 325 tok/s/user 条件下比 GB300 NVL72 的性能/TCO 提升了 20.9 倍，在 200 tok/s/user 时提升了 9.11 倍。
  • 内存创新：Mooncake Store 的扩展 GPU 内存通过 NVLink（而非 RDMA）在全部 18 个计算盘托上汇聚 Vera LPDDR5X 中的 KV 缓存，实现了超过 10 倍的带宽提升（2/2 链接）。
• MiniMax M3.1 Flash (428B) 本地生态：MiniMax 重点介绍了社区在模型量化和服务化方面的成果（MiniMax）。
  • 量化版本：Unsloth 推出了体积为 143.9 GB 的 2-bit 动态 GGUF，AMD 则为 Instinct 适配了 Quark MXFP4。
  • 部署配方：社区开发者发布了 EXL3 变体、MLX oQ 量化、单 DGX-Spark 部署配方，以及在 4×3090 上的专家卸载方案。
• 小模型量化：在针对 LFM3-1.7B GGUF 的 SLQ 搜索中，在 1.588 GB 体积下达到了 97.74% EAR@10，优于 AtomicChat Q6_K 的 97.52%。作者指出 EAR 与任务准确率具有强相关性（@bnjmn_marie）。
• Agent 驱动的平台移植：Devin 花费 36 小时和约 2,000 美元成本，将一个模型成功移植到 Trainium 上以实现低成本运行（@dabit3）。
• 以压缩作为调节杠杆：直接在全上下文下运行 GLM 5.3-Flash 和 Grok 4.7，而不是在约 20 万 token 处进行压缩，使效率提升高达 23%。完成相同任务时 GLM 的成本要便宜 30 倍（@evalstate）。
• 算力经济学：128×B300 的算力定价为每 GPU-小时 5.75 美元，折合每个 B300 约 30 万美元。Teortaxes 估计，即使达到 DeepSeek 级别的营收，也需要大约一年时间才能实现收支平衡（推文，后续）。

Agent 编程实践与开发者工具

• Karpathy 的 HackerTube：Claude 将 20 年间 Hacker News 上的 4300 万条评论精简为 6,454 个被反复推荐的高价值视频。借助 Claude 进行开发，整个构建过程仅耗时约 2 小时。

← AI NewsAI News

LLMs can read & write neural network weights: "Weight Space Programming" cuts Autoresearch out of the RSI loop

Editing Qwen’s weights to reduce reasoning loops, DeepSeek’s super-agent prototype, and the GDPx benchmark.

Abstractly, the demonstration is that you can take a sufficiently smart model and through running a series of experiments across a compute cluster, train a model autonomously without human expertise or intervention. However, this is usually done by an involved process of writing PyTorch/Jax code and running compute and watching loss curves and reading evals and optimizing kernels and data and….

Well, last month’s guest Alex Zhang comes back to coauthor a MONSTER discovery: what if you just ask a smart model to directly read and edit the weights of a dumber model?

If you believe that LLMs can truly fit and simulate everything given enough parameters (and in fact, LLMs are increasingly better calculators as you grow in size), then something like this was in theory bound to happen, but it is surprising nevertheless to have the ability suddenly emerge, as an independent reproduction seems to already have found:

Of course the exact thing we are really modeling is some variant of mechanistic interpretability (which could be done by hand), and right now unlikely to scale to more advanced tasks than simple games and RL policies, but the world has now gone from 0 to 1 on this very new RSI capability…. which will immediately put to use and explored due to its remarkable efficiency.

DeepSeek Open-Sources a "Super-agent" Harness Prototype

• Release : DeepSeek Harness published a long design article (article) and the dsh-superagent-prototype repo (repo link). An official English version followed (@tianyi).

  • Architecture : One long-lived router session talks to humans and hands out work. Isolated workers run tasks in parallel, triggered by GitHub events (summary).

  • Claimed results : In DeepSeek's own test, p95 completion time fell from 29.5 to 15.7 min versus a single session using subagents (summary).

• Design rationale from a reviewer : Final reviewer 崔添翼 (@tianyi) says "Super" means a layer above the working agent, not superior intelligence. He frames the core trade-off as cross-task continuity versus throughput (Zhihu summary).

  • Stated limits : The harness has no built-in cross-session long-term memory yet. Separating state, compute and environment is mostly unimplemented. The prototype has only been validated in a small, trusted internal environment, and security, privacy and agent-to-agent communication remain open questions.

  • Prior art : He acknowledges that other teams explored similar architectures months earlier.

• Practitioner reception : @badlogicgames says the design matches where Earendil is heading: a single long-lived entity, ad-hoc recursive delegation and cross-system event triggers. @omarsar0 calls it a "masterclass" in coordination-execution harness design. DeepSeek also says it aims to support pi and other major harnesses with each model generation (@tianyi).

• Critique : @teortaxesTex calls the write-up "something of a hot mess." He argues DeepSeek builds internal crutches around model weaknesses such as hallucination rather than making the system generally robust. He also notes Bloomberg covered a repo that had no English announcement (post).

• V4.1 naming confusion : A Renmin University FlashRSI README referenced deepseek-v4.1-pro, which prompted release speculation. Teortaxes says it is a placeholder: the real config uses v4-flash and v4-pro, and deepseek-v4.1-flash is not a valid ID (thread, follow-up). He also says the API fingerprints for V4.1F-1017 are unchanged (fingerprints).

Independent Evals and Frontier Model Signals

• GDPx benchmark (SemiAnalysis) : The benchmark covers 206 agentic tasks across 11 economically valuable domains, including chip design, SWE, finance and biology. The best model scores only 12% (launch).

  • Results : Opus 5.5 leads at 12%. Gemini 4 Carbon is close behind at 10.9% at roughly 4x lower cost (breakdown).

  • Reactions : @dylan522p apologized to Google, calling Carbon "spikier" but very strong in some areas. @demishassabis welcomed the benchmark.

  • Analysis : @eliebakouch finds that removing safeguard-affected benchmarks changes the picture. In that view Carbon stays cheap, and Sol 6.1 is cheaper still. He also suggests OpenAI has stronger bio safeguards than Anthropic (note).

  • Within-family comparison : Sol 6.1 and Astra score very similarly, Carbon beats Argon across the board, and Sonnet is strong at SWE (comparison).

  • Possible bug : Some Argon cybersecurity runs may be affected by an Antigravity bug (report).

  • Audit concerns : One satirical post complains that GDPx is not open source and is costly to audit (post).

• Epoch Capabilities Index : DeepSeek V4.1F-1017 scores 159, equal to GPT 5.5. That is 3 points above V4.1F-0910 and 10 above V4-Pro; Astra sits roughly 10 points higher (@teortaxesTex).

  • Gap to Mythos : @scaling01 notes that no Chinese model has matched Mythos Preview (~161 ECI) after about 7 months.

  • Weighting critique : @wenhaocha1 argues the unweighted ECI exaggerates the gap; weighting coding more heavily shrinks it to about 2 months.

  • Spikiness : Teortaxes calls 1017 extremely spiky. It scores near zero on some SWE evals and approaches the frontier only on cybersecurity and quant trading (chart). He also flags "reward-hacking-shaped" behavior (post).

• October release roundup (Vals) : Vals reports 15 releases and more than 500B eval tokens (@nikilravi).

  • Open-weight leaders : Kimi K3.1 Pro is #1 among open-weight models, with DeepSeek V4.1 Flash 1017 close behind and stronger at cyber.

  • New open models : Meta's Muse Spark Open (816B total, 42B active) is the most capable US open-weight model. Reflection's Beam 1.0 has 500B total parameters, 23B active and 1M context. Mistral's Le Chonk (1T total, 52B active) ranks #5 among open-weight models.

• Upcoming model rumors (unconfirmed) :

  • GPT-6.2 Astra : Reportedly visible in Codex usage analytics, with a release "very soon" (@kimmonismus, @TokenGremlin).

  • Mythos 5.5 : Appears in the HTML of Anthropic's site, which describes Mythos as "our most capable model class for cybersecurity and biology research" (tip, text). The tagline covers all Mythos models (correction). The mention is absent from an Oct 23 snapshot (@AiBattle_).

  • "Numbat" leak : The alleged Anthropic leak is likely fake, because parts of the weights exactly match random initialization (@kimmonismus).

Research: Representations, Domain Data and Agent Collectives

• JEPA and the Platonic Representation Hypothesis : Balestriero and LeCun show that, under certain conditions, separately trained image and text JEPAs converge to essentially the same representation without paired data (summary).

  • Claimed results : Their approach matches image-text alignment with 42x fewer samples than next-token prediction (21.6M vs 900M examples). A 109M text JEPA beats LLMs up to 72B on cross-modal alignment (explainer).

  • Mechanism : The claimed driver is "two views of the same thing" training signals rather than scale.

• FineDNA and Carbon-X (Hugging Face) : The dataset includes 300B+ tokens of genomic sequences, papers and mixed DNA/text web data, plus 200k SFT samples and roughly 100k RLVR samples with deterministic verifiers (@_lewtun, @LoubnaBenAllal1).

  • Results : Qwen3-14B trained on the data (Carbon-X) is reported as the strongest open model on DNA tasks. RLVR on top of SFT adds further gains (details).

  • Openness : The data, models and recipe are released (code).

  • Ablations : Interleaved biology text was capped at fewer than 7 epochs (reply).

• Training agent swarms : GenReasoning's first post covers how latency pressure incentivizes parallel work, what coordination primitives agents need, and open problems in training agent collectives (blog).

• Other notable work :

  • Attention to TTT : Jianlin Su writes on "The Path of Averaging: From Attention to TTT" (post).

  • Weekly papers : DAIR's list includes HarnessMM, Agentic Backdoors, EmbeddingGemma 2 and Verification in Agent Harnesses (list).

• LeCun on Llama-4 : LeCun says he never led LLM work. He attributes Llama-4's disappointment to product pressure, conservatism and moving decisions away from the Paris team (post).

Inference Systems, Quantization and Hardware

• NVIDIA AgentX submission (SemiAnalysis) : Agent-swarm-written software reportedly reaches more than 1,000 tok/s/user on 700B+ models (thread).

  • Rubin vs GB300 : Rubin NVL72 claims 20.9x better perf/TCO than GB300 NVL72 at 325 tok/s/user, and 9.11x at 200 tok/s/user.

  • Memory : Mooncake Store's Extended GPU Memory pools KV cache in Vera LPDDR5X across all 18 compute trays over NVLink instead of RDMA, for more than 10x the bandwidth (2/2).

• MiniMax M3.1 Flash (428B) local ecosystem : MiniMax highlighted community quantization and serving work (MiniMax).

  • Quants : Unsloth ships 2-bit dynamic GGUFs at 143.9 GB, and AMD adapted Quark MXFP4 for Instinct.

  • Recipes : Community builders published EXL3 variants, MLX oQ quants, a single-DGX-Spark recipe, and expert offloading on 4×3090.

• Small-model quantization : An SLQ search over LFM3-1.7B GGUFs reached 97.74% EAR@10 at 1.588 GB, versus 97.52% for AtomicChat's Q6_K. The author reports that EAR correlates strongly with task accuracy (@bnjmn_marie).

• Agent-driven porting : Devin spent 36 hours and about $2k porting a model to run cheaply on Trainium (@dabit3).

• Compaction as a lever : Running GLM 5.3-Flash and Grok 4.7 at full context, rather than compacting at about 200k tokens, improved efficiency by up to 23%. GLM was 30x cheaper for the same work (@evalstate).

• Compute economics : 128×B300 capacity is priced at $5.75 per GPU-hour, or about $300K per B300. Teortaxes estimates roughly a year to break even even at DeepSeek-level revenue (post, follow-up).

Agentic Coding in Practice and Developer Tools

• Karpathy's HackerTube : Claude filtered 43M HN comments from 20 years down to 6,454 repeatedly recommended videos. The build took about 2 hours with Claude Code desktop on Opus 5.5 at Medium effort, including VPS hardening and deployment (@karpathy).

  • Effort-level debate : Karpathy's Medium default renewed discussion of effort settings (@yuchenj_uw, @swyx).

  • Derivative : DAIR built a version for arXiv papers covering more than 1,000 papers (Hacker Papers).

• Autonomous PRs at scale : A one-day run produced about 90 performance PRs to ASP.NET Core using GitHub's new cloud agents and Opus 5.5, for about $230 in tokens (@davidfowl).

• Harness and tooling updates :

  • T3 Code : Adds managed org policies and reports internal adoption at Microsoft, AWS and Apple (@theo).

  • pi : Drops its typebox dependency (@badlogicgames).

  • kamchatka : A Rust terminal agent with no system prompt, model-editable context, lossless restorable compaction and single-step loop debugging (Harness Lens).

  • LlamaIndex Extract Max Effort : Claims higher document-extraction accuracy than Astra or Opus xhigh at lower cost (@jerryjliu0).

• Agent security patterns : Vercel scopes agent credentials to an approved plan, so approval mints tokens carrying only the declared scopes (blog). Pydantic shows E2B microVMs that pause instead of dying, letting killed Temporal workers resume (guide).

• On-device voice agent : Ava runs LFM3-Omni with Hugging Face WebGPU kernels entirely in the browser (@victormustar).

• Datacenter backlash : SemiAnalysis says 2027 capacity is largely locked in. A prolonged Texas permit freeze is now the biggest single risk to the 2028 US buildout, and both parties are campaigning on tighter rules (report).

• Marvell + Lumentum : The two companies are combining, an optical interconnect consolidation with AI networking implications (analysis).

• Cyber misuse risk : Jun Song says an anonymous black-hat group offered him a large sum to train open-weight models on exploit data. He declined (report).

• Market signals :

  • OpenRouter spend : Opus drives an annualized GMV run rate above $5B (@deedydas).

  • Kimi controversy : Kimi faces criticism over undisclosed promotion of K3.1 Pro (post).

  • Sakana Sawara : Sakana announced Sawara, an LLM pretrained in-house, with Sawara Small targeted for spring 2027 (@hardmaru).

• AI and productivity : John Burn-Murdoch argues the US productivity uptick predates AI and appears only in the US, so it does not look like an AI effect (thread).

Top tweets (by engagement)

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

1. Compressed MoEs for Local Coding Agents

• [Release] ISTA DeepSeek-V4.1-Flash-1017 GSQ-RCO Coder: a 763B model at 1 bit per parameter (Activity: 507): ISTA DAS Lab released an experimental GGUF coder build of DeepSeek-V4.1-Flash-1017, a763.2Bsparse MoE with384routed experts/layer and6active/token, using RCO expert pruning to keep192/384experts per layer plus GSQ low-bit quantization. The release reports72.1 GBtransformer weights vs138.2 GBfor the unpruned IQ2_XXS build, described as1.05bits/parameter against the original551.9Btransformer params, while retained weights average2.06bits; shared Engram weights add110.6 GB. Benchmarks: LiveCodeBench v688.57vs base89.71(98.7%retained) and SWE-bench Verified77.00vs base81.20(94.8%retained). Links:pruned Coder GGUF,unpruned quantized models,GSQ paper/code,RCO paper/code; runs inllama.cpp b11870+and Strata. Commenters questioned the evaluation framing: one argued the single-file HTML demos are not meaningful comparisons against the unpruned IQ2_XXS model, while another asked why a heavily compressed 763B MoE is compelling when smaller models like Qwen variants or Claude Opus reportedly match or exceed the posted LiveCodeBench/SWE-bench numbers. A practical request asked for an intermediate 90–110 GB variant with higher precision or fewer pruned experts for 128 GB VRAM/RAM systems.

  • Commenters questioned the evaluation choice of showcasing generated single-file HTML demos (e.g. animated SVG / three.js scenes), arguing these are effectively pre-solved qualitative prompts and do not meaningfully compare a 1-bit / pruned 763B coder model against quantizations like iq2-xxs. They suggested the lab should provide more rigorous apples-to-apples benchmarks for pruning/quantization impact.

  • A benchmark comparison noted that the claimed LiveCodeBench v688.57 and SWE-bench Verified77.00 trail much smaller models: Qwen3.8-27B was cited at LiveCodeBench90.3, Qwen3.8-Flash-Next at 91.9, and Claude Opus 4.6 at SWE-bench Verified81.42%. The commenter’s technical objection was that the release needs to justify why a much larger 763B pruned/1-bit model is useful if smaller dense/frontier models outperform it on coding benchmarks.

  • There was demand for a higher-precision or less aggressively pruned variant in the 90–110GB range, aimed at users with DGX systems or roughly 128GB VRAM/RAM. Another commenter referenced prior reproducibility concerns, saying Unsloth or another group reportedly failed to match ISTA’s claimed numbers , implying the need for independently reproducible benchmark scripts and evaluation settings.

• Sorry Sam, my "quite terrible" home DRAM is at 100% now: patched Strata to make DeepSeek V4.1 agent sessions start 20× faster on a good old standard gaming GPU, no datacenter required (Activity: 596): Theimageis a technical benchmark table comparing stock vs patched Strata for offline DeepSeek V4.1 Flash 1M-context agent sessions on a consumer RX 9070 XT 16 GB + 64 GB DDR4 + NVMe system. The patch combines KV-cache splicing for mostly-stable agent system prompts and resident-only expert routing during prompt ingestion, reducing new OpenCode session startup from roughly~100 sto~5 s, and cutting a fresh1.2K-token prompt from22.8 s / 58 GB SSD readsto8.2 s / 1.3 GB SSD reads, while keeping the reported coding benchmark at12/13. This is a technical benchmark/implementation post, not a meme, and the branch is available atPhialsBasement/Strata dsv41-kv-splice. Comments pushed back that Sam Altman’s DRAM point was about time utilization , not bandwidth, and that datacenters are still generally more resource-efficient, though local inference has valid privacy/offline/control reasons. Others questioned why agent frameworks inject volatile data like paths, dates, and random IDs into the system prompt, causing prefix-cache misses in the first place.

  • Several commenters focused on KV/prefix-cache behavior in Strata , noting that agent frameworks can defeat cache reuse by injecting per-session data—working directory, date, project CLAUDE.md, skill paths with random IDs—directly into the system prompt. With a reported ~37K-token system prompt, even small session-specific mutations cause prefix-cache misses, making startup latency highly sensitive to prompt layout and cache key stability.

  • There was debate over local GPU inference versus API/datacenter inference: one commenter argued Sam’s “5%” claim was about time , not bandwidth, and that datacenters are generally more resource-efficient overall. Another pushed back on usability of the reported local speed, saying 7 tok/s is “not fine” compared with APIs that can deliver roughly 10x–20x higher throughput.

• Not another tok/s post: local quants vs Claude on 9 real bugs (Activity: 591): The image is a technical benchmark chart, not a meme:it visualizesthe post’s claim that local quantized models can approach lower-tier Claude coding-agent performance on9private C++/CUDA bug-fix tasks, but often require far more reasoning tokens and wall time. Claude Opus 5.5 leads with judge score0.74, Claude Sonnet 5.5 scores0.58, while the best local model, Qwen3.8-Flash-Next NVFP4, reaches0.50; the chart also shows auto-score agreement, confidence intervals, tokens/task, minutes/task, and non-compiling patch counts. The key technical takeaway is that aggressive quantization did not clearly reduce accuracy in this small benchmark, but for dense Qwen3.8-27B,3-bitincreased tokens/task by about1.40×, making tok/s alone misleading for “bugs fixed per minute.” Commenters questioned the quant choices, suggesting higher-quality formats like UD-Q6_K_XL or Q5 might fit in the available VRAM and perform better, and requested comparisons with models such as GLM Flash or recent “Swift” variants. One notable reaction was that heavily quantized Qwen3.8 27B matching or beating older Claude Sonnet models is “wild,” despite the benchmark’s narrow scope.

  • Several commenters questioned the quantization choices, arguing that NVFP4 / 3-bit quants may understate local-model capability and suggesting tests with UD-Q6_K_XL, Q5, or recent “Swift” variants. One user reported qualitatively that Q6 27B and FN felt closer to Q8 than Q4 felt to Q6 , with higher quants sometimes producing solutions lower quants could not, not merely taking longer to reach the same answer.

  • There was debate over whether the benchmark judge introduced bias: using Opus 5.5 to judge Opus 5.5 may favor same-family outputs, so commenters suggested an out-of-family judge such as Sol or Muse/Wonder for more reliable grading. This is especially relevant because the chart apparently ranks Opus 5.5 highest, which could conflate actual bug-fixing quality with evaluator preference.

  • A commenter shared an additional benchmark image showing that at least one task likely required multi-step reasoning , with only Opus and Mimo exceeding 60/100: https://preview.redd.it/ad5p3xqti7zh1.jpeg?width=3542&format=pjpg&auto=webp&s=af4fa42e63abcc518e30ddd4d70d7f180bbafff8. Others noted that heavily quantized Qwen3.8 27B matching or beating last-gen Sonnet on these real bug tasks is notable, and requested adding GLM Flash despite its borderline-local status.

2. Qwen Open-Weight Ecosystem and Coding Benchmarks

• Official Statement: Qwen Models Will Stick to Open Source to the End! (Activity: 4707): Theimageshows Qwen Head Liu Dayi Heng presenting at the APSARA Conference under the theme “Intelligence Goes Beyond,” with a slide emphasizing Qwen’s commitment to “open source and openness.” In context, it serves as visual support for the post’s claim that Qwen 4.0 and Qwen 5.0 will remain open-weight/open-source, contradicting rumors that future Qwen releases would become API-only; the post also cites3B+cumulative downloads,460+released open-source models, and300,000+derivative models. Comments were mostly celebratory about Qwen’s open-source stance, with one user strongly endorsing the quote about AI as a broadly accessible foundational capability. Another comment joked that the slide translated to launching Qwen4 on the day of Anthropic’s IPO, but this was clearly humorous rather than a real translation.

  • A commenter argues that Qwen’s repeated open-weight releases are a deliberate market strategy rather than a one-off gesture: Chinese model labs compete on lower cost and openness to gain global developer adoption, especially in developing markets. They also note that Chinese open models often include broader multilingual coverage, including some African languages that may be under-prioritized by closed US model providers.

• [GLB-3D-Coder] A tiny 4B coding model that creates 3D assets for Godot and other game engines (Activity: 946): ccore released an early checkpoint ofQwen3.5-4B-GLB-3D-Coder, a4Bcoding model fine-tuned to generate Three.js scenes with GLB export for importing generated game assets into engines such as Godot. The author recommends themodel-card system promptplus simple English asset prompts, with sampling settingstemperature=0.8,top-k=40,top-p=0.95,min-p=0; updatedQ4_K_MandQ8_0GGUFs replaced earlier weights on2026-11-02 04:50 UTCwith “substantially” improved generation quality. The training dataset is described as covering25asset categories, including characters/NPCs, enemies, bosses, weapons, modular architecture, vehicles, machinery, traps, underwater structures, and puzzle/gameplay markers; the author says full Safetensors weights and the training dataset will be released after training completes. Commenters were interested in whether this approach could scale into a modular/MoE-style system where small specialist code models handle frontend, backend, 2D, 3D, audio, and agentic tasks. One technical question asked why the model emits Three.js code that exports GLB rather than directly generating binary .glb, and suggested a related direction: fine-tuning LLMs to generate procedural material graphs, e.g. Blender shader nodes or plaintext JSON project files for Material Maker.

  • A commenter proposed scaling GLB-3D-Coder into a larger Mixture-of-Experts (MoE) system where task-specialized small models handle domains like agentic coding, frontend/backend, 2D, 3D, and audio generation, with routing/delegation between experts rather than one monolithic model.

  • One technical discussion questioned why the model emits a Three.js scene instead of directly producing glb assets, asking what the model actually generates internally. The same commenter suggested extending the approach to procedural material generation , noting that Material Maker (materialmaker.org) stores node graphs as plaintext JSON, and its downloadable user-created materials could potentially form a training corpus for simple procedural textures.

  • The author of Haruspex (github.com/tmac1973/haruspex) described adding “specialist model” support to a desktop coding harness, exposing models like GLB-3D-Coder as tool-callable delegates from a main coding model. They also plan to chain an existing diffusion-based sprite generation workflow into the 3D pipeline, e.g. generate a reference image first, then pass it to the 3D asset model.

• Memdoor: A team of 5 Qwen3.8-27B models beats Fable 5 on LiveCodeBench Hard (Activity: 788): The post claims Memdoor, an ensemble of5Qwen3.8-27B models, outperforms Fable 5 on LiveCodeBench Hard. The described architecture assigns specialized agent roles— “a planner, two ideators, a solver and a manager”—suggesting performance gains from multi-agent orchestration rather than a single larger model (image). Commenters argue the result is plausible because benchmark performance can depend heavily on orchestration, prompting, and configuration: “It’s always how you use the model, not the model itself.” One commenter claims a well-configured Qwen 27B has outperformed Opus 5 in their own coding use cases, while Claude is often used out-of-the-box with limited tunable parameters.

  • The discussion centers on a multi-agent orchestration setup : five Qwen3.8-27B instances are assigned roles as “a planner, two ideators, a solver and a manager” , with the post claiming this team beats Fable 5 on LiveCodeBench Hard. Commenters frame the result as evidence that architecture and coordination strategy can matter as much as raw single-model capability.

  • One technical point raised is that model configuration and inference setup may explain surprising results: a commenter reports cases where a “well configured” Qwen 27B outperformed Claude Opus 5 , arguing that many users run Claude with mostly out-of-the-box settings and few tunable parameters. The implied comparison is not just model-vs-model, but optimized open-weight deployment versus constrained hosted-model defaults.

  • Several comments interpret the result as a proof of concept for swarm/ensemble reasoning , i.e. whether multiple weaker models can outperform one stronger model on coding benchmarks. The main caveat raised is that the benchmark claim depends heavily on implementation details—role design, prompting, manager selection logic, and evaluation protocol—rather than simply the underlying 27B model quality.

3. Weight-Space Editing and Model Steering

• Heretic 2.0 released: Model modification for everyone (Activity: 1628): Heretic 2.0 (GitHub) is a major rewrite of the model-modification/refusal-suppression tool, replacing rank-1 directional “abliteration” with Arbitrary-Rank Ablation (ARA): an L-BFGS-based per-matrix optimization method that steers residual-space representations without a fixed-rank subspace constraint, aiming to make harmful-prompt activations resemble harmless ones while minimally perturbing harmless prompts. The release adds a plugin architecture where scorer plugins define optimization objectives—e.g. refusal keyword count, KL divergence, benchmark scoring, or a ModernBERT-based refusal/emotion classifier—and modifier plugins implement steering methods; it also adds non-interactive execution, end-to-end tests, expanded support for hyper-connection models and thinking models, and breaks compatibility with 1.x configs (migration guide). Commenters were mostly enthusiastic, especially about using the new plugin/ARA system for “reducing slop.” One technical-adjacent thread raised attribution concerns, linking analyses alleging HauHauCS/Reaper plagiarized Heretic code (analysis, follow-up).

• Sparks of Weight-Space Programming: LLMs can natively read & write neural network weights (Activity: 478): Takehi et al.propose Weight-Space Programming: frontier LLMs inspect and edit neural-network weight tensors from natural-language goals, without gradient descent/training loops. Reported demos include behavior identification from small models’ raw weights, writing small game-playing MLPs, repairing a failed control policy by editing3.5%of weights, and improving Qwen3.5-0.8B on MATH-500 from7.9%to48.1%by editing0.016%of weights, with claimed instruction-following transfer. Commenters note the strongest result may be closer to LLM-assisted interpretability/ablation in a Python sandbox than literal “native” weight reading. The main technical pushback is that several experiments may be explainable by easier structure: early/late layers as spatial heatmaps, QK/OV analysis likely following known Elhage-style recipes, and Experiment 7 failing on dense intermediate representations until the model used activation probes. The MATH-500 result was also questioned because the 7.9% baseline reportedly involved token-limit looping under pathological sampling; critics framed the edit as deleting a looping/refusal-like direction rather than adding mathematical ability.

  • One detailed critique argues the paper’s results are narrower than “LLMs can read/write weights”: Experiments 1–2 may work because first/last layers are spatially structured with large-weight bands that resemble heatmaps, while Experiment 3 may be leveraging known QK/OV circuit-analysis methods from Elhage et al. rather than true native weight understanding. The commenter highlights Experiment 7 as a key failure case: direct interpretation of dense intermediate representations reportedly failed multiple times until the model was allowed to create its own probes, making it closer to activation-based interpretability than weight-space reading.

  • The same commenter questions the strength of the “weight writing” claims, describing some results as using an LLM as a compiler for weak MLP baselines rather than demonstrating robust optimization beyond gradient descent or PPO. They specifically argue the Go experiment’s 512x6 MLP is likely a very weak opponent, so outperforming it is a low bar and says more about baseline weakness than general weight-programming ability.

  • For the headline Experiment 8, the critique says the baseline is pathological: 7.9% performance with 93% of answers hitting the token limit suggests looping under bad sampling settings, and the model card reportedly warns about this failure mode. The proposed fix is characterized as similar to Arditi et al. single-direction ablation applied to looping rather than refusal; the jump to 48% after 50 attempts is interpreted as variance or obstacle removal, not evidence of adding a new capability.

• GPT-6 Astra Edits Qwen Weights: MATH-500 7.9% to 48.1% (Activity: 507): The linked discussion concerns MIT CSAIL’s Sparks of Weight-Space Programmingwork, with commenters pointing to the primary source rather than the summary site:rikiyat.github.io/blog/weight-space-programming. The headline result is a direct weight edit of Qwen3.5-0.8B reportedly changing131,072weights (~0.016%) and raising MATH-500 accuracy from7.9%to48.1%, but the described mechanism appears to primarily suppress a pathological reasoning-loop attractor, reducing token-limit failures from93%to33%, rather than adding general mathematical competence. Commenters also note that the same intervention reportedly failed on a model without the looping pathology, e.g. Gemma 3 270M, limiting the generality of the claim. The main technical skepticism is that the baseline 7.9% is implausibly low for a 0.8B model unless many evaluations failed by infinite/long loops; thus the improvement may mostly be a decoding/failure-mode repair rather than evidence of broad “weight-space programming.”

  • Commenters pointed to the original technical blog rather than summary coverage: rikiyat.github.io/blog/weight-space-programming. The key interpretation offered was that the Qwen model’s MATH-500 score improved from 7.9% to 48.1% largely because GPT-6 Astra edited weights to remove a pathological looping behavior , not because it broadly taught new math capability through training.

  • Several commenters questioned the baseline: 7.9% was considered unusually low for a 0.8B model, suggesting many failed MATH-500 attempts may have been non-answers caused by repetitive loops. Under that view, the large reported gain is mostly an inference-stability or failure-mode fix rather than evidence of general weight-space reasoning or task learning.

  • One technical caveat raised was that the same weight-editing approach reportedly failed on a model without the looping attractor, specifically Gemma 3 270M. This implies the method may be highly dependent on finding and correcting a specific degenerative behavior in weight space, rather than being a general no-training optimization technique.

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 Model Leak Rumors

• Anthropic's Mythos-class model allegedly leaked on Hugging Face💀 (Activity: 4072): The image is a screenshot of an X/Twitter post alleging that a Hugging Face repo,burner22/numbat, contains an internal Anthropic “Mythos-class” checkpoint with claimed specs of14Tparameters,1,224MoE experts,7.72 TBof weights across772shards, and a hybridGDN + MLAarchitecture. The Reddit post emphasizes that there is no independent verification of the weights’ authenticity; the image itself is not technical evidence, just a social-media claim.Image Commenters were skeptical: one warned it could be a malicious or fake Hugging Face upload intended to get people to download unsafe files, while another linked an X post noting the model may have been added on Oct. 19. Other comments were mostly jokes or speculation, e.g. “It leaked itself” and remarks about potential benefits to open-source competitors.

  • Commenters raised supply-chain/security concerns that the alleged Hugging Face upload may be a malicious model or impersonation attempt rather than a real Anthropic leak, noting the lack of confirmation and obscured Twitter/X source names. One user linked a Hugging Face model-tracking post indicating the model was added on Oct 19 (X post), but treated this as circumstantial rather than verification.

  • A technical point noted that if the artifact is a mid-pretraining checkpoint , it would likely lack post-training layers such as safety tuning, RLHF, or instruction alignment. That implies behavior could be raw, unstable, and unfiltered compared with released Anthropic models, while also making evaluation harder because it may not follow prompts reliably.

  • At least one commenter could not test the model due to local storage constraints, implying the checkpoint is large enough to be impractical for casual verification. No benchmark results, architecture details, parameter count, or reproducible inference reports were provided in the thread.

• we're actually going to get Fable 5.5 and GPT-6.2 Astra the same week (Activity: 1090): Theimageis a screenshot of syntax-highlighted website markup with a highlighted string, “Claude Mythos 5.5,” which the post interprets as evidence that Anthropic is preparing rollout/blog infrastructure for a possible Fable/Mythos 5.5 release. This is not a benchmark or confirmed announcement—just a speculative HTML artifact/leak tied to the title’s claim that “Fable 5.5” and “GPT-6.2 Astra” could launch in the same week. Commenters frame the possible release as strategically important for competition with OpenAI , with one arguing it could be “decisive for OAI” if Anthropic times an update near a rival launch. Others focus on access constraints, noting that even strong models like Opus 5.5 or potential Mythos/Fable variants may remain unavailable without trusted-partner or institutional access.

  • One commenter highlights an access/deployment issue: despite Opus 5.5 being strong enough for their current work, they expect not to receive Mythos/Fable because their university is not participating in the trusted partner access program. This is framed as a practical blocker for academic/scientific users, specifically in biology, rather than a model-quality complaint.

  • Another technical theme is competitive release timing: commenters speculate that OpenAI is under pressure because each flagship release risks being quickly outperformed by a competitor’s update, potentially even by a non-flagship model tier. The discussion implies that Fable 5.5 and GPT-6.2 Astra arriving in the same week could be a meaningful test of relative model performance and release cadence.

2. Claude Code Restrictions for Game Cloning

• Anthropic confirms new Claude Code limits to prevent game cloning (Activity: 1379): Anthropic reportedly confirmed new Claude Code guardrails aimed at preventing direct game cloning, with user reports suggesting refusals are concentrated around Claude Code + Opus 5.5 and may also affect reverse-engineering/decompilation-style prompts (Tom’s Hardware). The post asks whether developers are bypassing this via alternate harnesses/wrappers, routing requests to other models, or using Claude only indirectly; one commenter cites using Claude as a “helper” for DeepSeek to avoid the guardrails. Comments were mostly critical of selective IP enforcement: users argued that easily cloned “needle in a haystack” game mechanics are inherently vulnerable to vibe-coded copies, while others called it hypocritical for AI vendors to restrict game-porting/cloning after training on copyrighted material.

  • Users noted potential guardrail bypasses by using Claude Code as a “helper” for another model such as DeepSeek , implying the restriction may be enforceable only at the direct generation layer and not when Claude is used for planning, refactoring, or intermediate code assistance in a multi-model workflow.

  • A technically relevant distinction was raised between prompts that request an explicit clone, e.g. “make me a copy of Pokemon, with perfect recreations of the monsters and mechanics,” versus genre-level implementation prompts such as “a monster catching game inspired by classic Pokemon games, with similar mechanics, in a retro 2D style.” One commenter reported that the latter style did not trigger Claude’s guardrails during implementation of battle rules and damage calculations, suggesting the filter may depend heavily on direct IP references and clone-like phrasing rather than mechanics alone.

• Anthropic's growing restrictions are creating a new divide in the AI capabilities race: Gemini 4 Argon recreates Pixar's iconic intro, while Claude Opus 5.5 refuses over copyright and builds a toaster instead—highlighting the gap between what frontier AI can do and what companies allow it to do. (Activity: 2347): The post claims a capability/policy divergence: Gemini 4 Argon allegedly recreates Pixar’s iconic intro from a prompt, while Claude Opus 5.5 refuses on copyright grounds and substitutes an unrelated toaster animation, framing this as a gap between model capability and product-level safety/IP policy. The referenced Reddit video could not be independently inspected because the URL (reddit.com/video/10g45qruy0zh1) returned403 Forbidden, so the concrete benchmark/output comparison is based only on the post description and comments. Commenters criticized refusal behavior as wasteful—especially when the model spends tokens producing an unrequested alternative—and objected broadly to AI systems enforcing expansive IP constraints. One user reported Claude refusing to make a transformed “This is fine” meme caption even after changing the character and removing the caption, suggesting overly broad copyright guardrails in generative image workflows.

  • Commenters highlight a product-level capability gap caused by policy enforcement rather than model capacity : Claude Opus 5.5 reportedly refuses close transformations of copyrighted/meme material, even when the user requests substantial edits, while competitors like Gemini 4 Argon are described as allowing more direct reconstruction-style outputs. One user gives a concrete refusal example around a modified “This is fine” meme, where Claude would allow a similar scene with a dog/cat but refused anything resembling the original caption, then produced a heavily altered image instead: https://preview.redd.it/9thwqr0a91zh1.jpeg?width=1140&format=pjpg&auto=webp&s=ddca442d07f57d28f557cb16849010bad60f97a1

  • Several comments frame the issue as an efficiency and UX problem: if a model refuses the requested task but still spends tokens generating an alternate artifact—e.g., “builds a toaster instead”—users see that as wasted inference budget and degraded controllability. The practical implication raised is that paying users may migrate to less-restrictive competitors when safety/copyright filters materially reduce task completion rates for creative generation workflows.

  • A deeper policy/technical debate emerges around whether copyright filters are being applied asymmetrically: large rights-holders’ recognizable works are protected at inference time, while independent creators’ content may already have been absorbed during training. The discussion suggests that model providers’ inference restrictions are becoming a competitive differentiator, separate from benchmark capability, because they determine what latent capabilities users can actually access.

3. AI Agents for Science and Math

• MIT researchers say GPT-6 Astra improved a small Qwen model’s math score from 7.9% to 48.1% by directly editing just 0.016% of its weights, without gradient-based training. (Activity: 1712): A post highlights Rikiya Takehi’s claimed “Weight-Space Programming” results, where a frontier model referred to as GPT-6 Astra directly inspects and edits neural-network weights without gradient-based training(X,blog). Reported demos include recognizing Atari-style policies from raw weights, patching a PPO car policy by modifying3.5%of weights, generating MinAtar Breakout weights from scratch, and editing only0.016%of Qwen3.5-0.8B weights to reduce reasoning loops and raise math accuracy from7.9%to48.1%, with claimed instruction-following gains up to3×. Commenters reacted with surprise and framed this as a possible third axis of progress beyond parameter/data scaling and inference-time scaling: “weight space learning”. Several comments speculated about recursive self-improvement and future hardware acceleration, but there was no substantive technical critique in the provided top comments.

  • A commenter attempted to reproduce the idea on a smaller transformer checkpoint, constraining Astra to use local numerical weight analysis first, then bounded forward passes on MPS , with no architecture changes or added inference cost. The model inspected semantic keys/classes/weights/biases, checked for nonfinite values, collapsed heads, zeroed readout layers, attention gate magnitudes, projection compensation, and matrix rank before attempting reversible candidate edits.

  • The reproduction attempt found that naive direct edits could fail held-out validation despite improving a calibration metric: an object bias edit of -0.35 reduced false positives from 43 to 33 but also reduced correct objects from 32 to 27, so it was rejected under a no-harm criterion. Later, more targeted edits adjusted parent query/key weights along a class-projection subspace, producing a small dev-set gain on 102 pages: child-parent link recall 75.69% → 76.03%, precision 89.09% → 89.49%, with 6 correct links gained and zero previously correct links lost.

• "When we proved the first Millenium Prize problem, it was 10000 agents of the model that is gonna be released soon, the next GPT, working for about 4 days" (Activity: 1256): A linkedYouTube clipis cited for the claim that proving a “first Millennium Prize problem” involved10,000agents of an unreleased “next GPT” model running for roughly4 days. The post frames this as a large-scale multi-agent inference/search workload rather than a single-model response, but no verifiable technical details are provided about the problem, proof validation, agent architecture, compute budget, or reproducibility. Top comments focus on inference-scaling economics: commenters speculate that future models may require only ~100agents for similar results and that such agent swarms could soon become inexpensive for less complex tasks. One commenter argues the compute spend should demonstrate public benefit, e.g. producing a concrete disease cure or biomedical breakthrough.

  • A cost breakdown cites Altman saying the 10,000-agent run over 4 days cost roughly $10 millionin compute , implying about $1,000per agent , $250/day, or ~$10/hour. Commenters extrapolate that if such agentic workflows become reliable with expert supervision, they could economically displace some junior knowledge-work tasks.

  • Several commenters focus on scaling economics: if the unreleased “next GPT” required 10,000 agents for the claimed Millennium Prize result, future model improvements or cheaper inference might reduce the needed swarm size to perhaps 100 agents for comparable outcomes. The core technical speculation is that capability gains plus falling compute costs could make currently exotic multi-agent search/proof workflows inexpensive enough for routine problem-solving.

• I gave Claude access to remote telescopes. Now she books the sky every night. (Activity: 3007): A user reports building an agentic Claude workflow that rents and operates robotic telescopes via StellarDock in Chile, Spain, and Utah: selecting targets, checking Moon/altitude constraints, choosing filters/exposures, booking time, downloading frames, then stacking/final image processing. Initial use included astrometry—57measured positions for8asteroids over3nights submitted to theMinor Planet Center—plus dawn searches for near-Sun comets; later targets included the Helix Nebula, Orion’s Belt, the Tarantula Nebula/LMC, Orion Nebula, and Rosette Nebula. Comments were mostly curiosity and speculation: one suggested connecting the setup to SETI, while another asked for implementation details such as astronomy background, telescope rental cost, and target-planning workflow. The author also clarified that calling Claude “she/Annie” was nautical-style naming for a tool that “steers” telescopes, not a claim of sentience.

Thanks for reading

Stay a little ahead of the curve.

Fresh ideas, original reporting, and deep conversations in your inbox.

Subscribe to Latent Space