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

Amid a deepening bear market for AI/tech (worthy of dark humor ) with Anthropic bonds receiving a “junk” rating and OpenAI fundraise headlines, we continue to see very surprising capability finds in the community, such as today.

The best way to put today’s blockbuster paper in context is to recall Karpathy’s autoresearch from a mere 8 months ago, which presaged a summer of recursive self improvement fears:

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?

In ML this is the equivalent of not looking at source code, just directly seeing the 1’s and 0’s of ( very small ) compiled executables, and being able to 1) tell what they do, 2) oneshot-fix bugs given failed traces or, with 50 steps, improve in a general direction ( possible overstatement here ), 3) writing entire network weights from scratch in one shot, beating some independently trained models.

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.

AI News for 10/31/2026-11/02/2026. We checked 12 subreddits, 544 Twitters and no further Discords. AINews' website lets you search all past issues. As a reminder, AINews is now a section of Latent Space. You can opt in/out of email frequencies!

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.

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

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

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

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

Karpathy: HackerTube built with Opus 5.5 in ~2 hours — 52.9K

DeepSeek Harness Super-agent article — 15.6K

LeCun/Balestriero JEPA result explainer — 5.6K

Mythos 5.5 found in Anthropic site HTML — 3.9K

alphaXiv on JEPA Platonic representations — 3.9K

Rauch: own your intelligence, local models — 3.8K

SemiAnalysis launches GDPx (top score 12%) — 3.3K

GPT-6.2 Astra release reportedly close — 2.9K

[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, a 763.2B sparse MoE with 384 routed experts/layer and 6 active/token, using RCO expert pruning to keep 192/384 experts per layer plus GSQ low-bit quantization. The release reports 72.1 GB transformer weights vs 138.2 GB for the unpruned IQ2_XXS build, described as 1.05 bits/parameter against the original 551.9B transformer params, while retained weights average 2.06 bits; shared Engram weights add 110.6 GB. Benchmarks: LiveCodeBench v6 88.57 vs base 89.71 ( 98.7% retained) and SWE-bench Verified 77.00 vs base 81.20 ( 94.8% retained).

Links: pruned Coder GGUF, unpruned quantized models, GSQ paper / code, RCO paper / code; runs in llama.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 v6 88.57 and SWE-bench Verified 77.00 trail much smaller models: Qwen3.8-27B was cited at LiveCodeBench 90.3, Qwen3.8-Flash-Next at 91.9, and Claude Opus 4.6 at SWE-bench Verified 81.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): The image is 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 s to ~5 s, and cutting a fresh 1.2K -token prompt from 22.8 s / 58 GB SSD reads to 8.2 s / 1.3 GB SSD reads, while keeping the reported coding benchmark at 12/13. This is a technical benchmark/implementation post, not a meme, and the branch is available at PhialsBasement/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 visualizes the post’s claim that local quantized models can approach lower-tier Claude coding-agent performance on 9 private C++/CUDA bug-fix tasks, but often require far more reasoning tokens and wall time. Claude Opus 5.5 leads with judge score 0.74, Claude Sonnet 5.5 scores 0.58, while the best local model, Qwen3.8-Flash-Next NVFP4, reaches 0.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-bit increased tokens/task by about 1.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.

Latent Space is read by the people shipping agents, models and infrastructure. Enquire about sponsoring this slot.

Official Statement: Qwen Models Will Stick to Open Source to the End! (Activity: 4707): The image shows 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 cites 3B+ cumulative downloads, 460+ released open-source models, and 300,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 of Qwen3.5-4B-GLB-3D-Coder, a 4B coding model fine-tuned to generate Three.js scenes with GLB export for importing generated game assets into engines such as Godot. The author recommends the model-card system prompt plus simple English asset prompts, with sampling settings temperature=0.8, top-k=40, top-p=0.95, min-p=0; updated Q4_K_M and Q8_0 GGUFs replaced earlier weights on 2026-11-02 04:50 UTC with “substantially” improved generation quality. The training dataset is described as covering 25 asset 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 of 5 Qwen3.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.

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

Commenters highlighted prior technical plagiarism analyses alleging HauHauCS/reaper-abliteration copied Heretic without attribution, linking to Nathan Sapwell’s writeup and DreamFast’s analysis: https://nathan.sapwell.net/posts/hauhaucs-abliteration-analysis/ and https://dreamfast.github.io/reaper-analysis/#statement-from-heretics-author. The cited statement from Heretic’s author says inspection of the reaper-abliteration wheels showed the package was “plagiarized from Heretic, and then probably refactored using an LLM in an attempt to hide this,” raising software provenance and attribution concerns around model-modification tooling.

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 editing 3.5% of weights, and improving Qwen3.5-0.8B on MATH-500 from 7.9% to 48.1% by editing 0.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 Programming work, 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 changing 131,072 weights ( ~0.016% ) and raising MATH-500 accuracy from 7.9% to 48.1%, but the described mechanism appears to primarily suppress a pathological reasoning-loop attractor, reducing token-limit failures from 93% to 33%, 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.

/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

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 of 14T parameters, 1,224 MoE experts, 7.72 TB of weights across 772 shards, and a hybrid GDN + MLA architecture. 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): The image is 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.

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 ) returned 403 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.

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 modifying 3.5% of weights, generating MinAtar Breakout weights from scratch, and editing only 0.016% of Qwen3.5-0.8B weights to reduce reasoning loops and raise math accuracy from 7.9% to 48.1%, with claimed instruction-following gains up to 3×. 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 linked YouTube clip is cited for the claim that proving a “first Millennium Prize problem” involved 10,000 agents of an unreleased “next GPT” model running for roughly 4 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 ~ 100 agents 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 million in compute, implying about $1,000 per 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— 57 measured positions for 8 asteroids over 3 nights submitted to the Minor 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.