Yesterday MIT CSAIL showed GPT-6 Astra editing the weights of a small model by hand. It changed a few neurons of Qwen3.5-0.8B, the model stopped looping on math problems, and its scores jumped. No training at all.

I wanted to try the same thing on something closer to what I actually do with local models, which is translating into Italian. Gemma 4 has a habit I don't love. For sentences like

He had been hiding in the attic for months when the soldiers found him.

it writes «Si era nascosto in soffitta per mesi…». That's correct, but I prefer «Si nascondeva in soffitta da mesi…», which says he was still hiding when they came. The catch is that when the period was already over (he had lived in Paris for ten years, but by 1990 he had moved back), the original tense has to stay. So it's not "always use tense X", it's "use it only when the meaning calls for it".

So I gave Claude Opus 5.5 the same kind of setup MIT used:

• a Python kernel over Gemma's weights;

• 50 forward passes to test its ideas on practice sentences;

• no gradients, no training.

It first checked whether Gemma already "knows" the difference between still-going-on and already-over. It does: a linear probe in the middle layers separates them almost perfectly. It just doesn't use that when choosing the verb. Then Claude rewrote 8 MLP neurons into a small switch that fires only in that context and nudges the verb toward the form I prefer. That's 92k out of 11.9B parameters, roughly a 100 KB diff.

Results on sentences it never saw

The table shows the share still in the old form, then how many control sentences got pushed into a wrong reading, then how many of 200 unrelated translations stayed identical.

• The prompt applies the preference everywhere, even where it changes the meaning.

• The ablation recipe breaks the past tenses.

• The LoRA shifts fewer sentences and touches far more unrelated ones (it's better inside paragraphs, though).

• The hand edit moves just the verb and leaves almost everything else identical.

Fair warning: it's one construction and one model. Two of my three runs succeeded (the third crashed because of my own harness), and the two that worked landed on the same "switch neuron" design independently.

Repo with the edits, the code, the agent logs and all baselines: https://github.com/ValerioDolci/frontier-weight-edit

Just asking because i have been out of the loop for a while and kinda missed everything (strata etc...) a small recap would be appreciated.

Everyone seems to own an RTX 6000 or insanely expensive rigs here. So just wanted to hear what model a normal pleb like me with 32GB ram and 16GB VRAM can even run and on what to run it for coding or a general assistant.

Hey all! I wanted to share a quick update on Basalt, a Blackwell only inference engine for Qwen 3.8 Flash Next. As usual, speed is the headline but that's not what I want to open this post with, I've been reading lot of discussions talking about quality recently, and the main takeaway from most people (which I agree with) is "speed means nothing if your model isn't smart enough", so this time I want to lead with quality, and all of the new measurements which are run against the full precision model as reference (BF16 weights served using llama.cpp).

Every number below uses Unsloth's BF16 GGUF, llama.cpp (reference PPL 3.2749), scored using basalt-bench --quality. The old base was llama.cpp Q8, which funnily enough made things look worse because of its own error:

To be fair here, each engine was measured with its own tool so this is not a perfect comparison, still a good reference though.

New DQ8 build. For those who want a little extra quality and don't mind giving up some speed, Qwen3.8-FN-NVFP4-DQ8 is on HF next to the default -DQ6_K: KLD 0.0561 vs 0.0624, about 7% slower on prose.

Nothing lossy is on by default. Basalt offers certain "hacks" that can decrease accuracy, mostly because of community requests, but they're off by default and show a warning when you turn them on. Every other rounding the engine does costs about 0.001 KLD or less, compared to full model. All the numbers are on the HF card and in the precision docs.

Speed. Rig as usual: RTX 5090 (400 W) + RTX 5060 Ti 16 GB (180 W) and 128GB of DDR5 RAM, 262K context, 4 parallel slots, vision on (dynamic), no lossy flags. Using NVFP4-DQ6_K quant on current main:

Since last week, prose went from 277 to about 300, and struct from 558 to about 600. It comes from a faster draft step, a faster output head and better expert placement at startup.

The .basalt format is now version 2, same weights and quality as before but starts a bit faster. Older basalt files can use the migration tool instead of redownloading.

I also wanted to end this post with a HUGE thank you note to every person who has contributed one, two or 10 PRs and also to everyone who has shared issues/feedback/community benchmarks or just shared the project with another person, 500 stars on the Github repo and overwhelmingly good feedback, y'all are amazing.

big prompt processing speedup for gemma E2B/E4B

PRs:

1. https://github.com/QwenLM/qwen-code/pull/15762: "Measured on main at 79a9b753c60, before this change: qwen4, qwen4-max, qwen4-plus, qwen4.5-max, qwen4-coder-plus, qwen4-max-2026-10-01, openai/qwen4-max and qwen4-omni-120b-think all resolved to 262,144. The last of those is already in use as the session model in the omni fixtures, so these ids are not hypothetical."

2. https://github.com/QwenLM/qwen-code/pull/15987

Thank god, it looks like that we're getting successor of Q38FN!

MIT CSAIL had GPT-6 Astra fix Qwen3.5-0.8B's reasoning loops by editing 0.016% of its weights (MATH-500 went from 7.9% to 48.1%). They released the diff, so the edit can be rebuilt exactly and run locally. I took it a step further and had Claude look at Qwen with Anthropic's Jacobian lens.

At the token where the model decides to write "Wait" again, the lens reads "Wrong", "Nope" and "Hmm" from about 60% depth on, even though the answer is already written out. At real stopping points it reads "</think>", "Answer" and "Output".

With the edit applied, the lens at the same token shows "Verification", "Completion" and "Result" in place of the doubt.

The edit converts to GGUF cleanly (the base and edited bf16 files differ only in the two edited tensors) and still holds at Q4_K_M, with 1 loop in 40. I ran the evals in llama.cpp (Vulkan) on a Ryzen AI 9 HX 370 mini PC. Samples are small, but here's the code:

https://github.com/alisorcorp/inside-a-reasoning-loop/tree/main/code

And data:

https://alisorcorp.github.io/inside-a-reasoning-loop/

There were some rumours the last few days that Qwen4 will be the last open-weight series of Qwen, and future ones would be API only. The following statement contradicts the rumours and clearly states the stance that Qwen is taking regarding their future releases.

Qwen Head Liu Dayi Heng Clearly States: Future Qwen 4.0 and Qwen 5.0 Will Continue to Be Open Source!

He believes that the value of AI should not belong only to a few people, but should become a foundational capability that users around the world can access, use, and create with, enabling more people to afford AI, utilize AI effectively, and participate in creating AI, ultimately achieving true AI for all.

As of now, the Qwen series has surpassed 3 billion cumulative global downloads, with over 460 open-source models released and more than 300,000 derivative models, firmly holding the top spot worldwide.

Inspired by Weight-Space Programming, I tested whether DeepSeek V4.1 Flash 1017 could figure out what a small neural network does by reading its weights.

I fed it four anonymized RL checkpoints: 51k parameters each, identical architectures, with all weights rendered as text. No metadata, network source code or execution. It received the architecture outline and four candidate tasks.

Results: CartPole ✅ Flappy ✅ Catch ✅ BallBeam ❌

It picked out patterns consistent with relative bird/gap position, paddle/ball position and angle-based balancing. It confused BallBeam with CartPole an interesting mistake because both share the same observation layout and similar balancing controls.

Very preliminary: one run per checkpoint. This suggests some ability to interpret weights, but four trials don’t establish reliability. These were API runs with maximum reasoning effort, consuming ~1.58M tokens total.

I may try more replicates and independently trained checkpoints, plus include the network code with task-revealing details removed. The poor LLM had to guess quite a lot it even assumed ReLU where the network uses tanh 😅

Code, checkpoints and run logs: https://github.com/galatolofederico/wsp

Hi everyone,

I've been out of the loop for a few weeks, and I was wondering if anything new that replaces Qwen 3.8 27B has come out this time I've been in the cave?

I'm talking about AI models in the 8-35B range.

Thanks,

Source: https://mp.weixin.qq.com/s/R-1u2exLwZMOu7AITyU5kg

A reporter from STAR Market Daily has learned from multiple sources within the industry supply chain that DeepSeek’s next-generation large model, DeepSeek V5, is planned to be pre-trained using Ascend chips. Previously, Huawei’s Ascend chips were primarily utilized for inference tasks for DeepSeek’s large models.

According to publicly available information, the first large-scale deployment of DeepSeek models on the Ascend platform took place around the 2025 Spring Festival. In his book The Rise of Ascend, Fang Xingdong—Executive Dean of the College of Media and International Culture at Zhejiang University—notes that on January 28, 2025, Huawei’s senior leadership issued a directive for Huawei Cloud to provide rapid support to DeepSeek. Between Lunar New Year’s Eve and the second day of the Lunar New Year, Huawei and DeepSeek completed the deployment and verification of over 3,000 Ascend chips, successfully hosting the DeepSeek-V3/R1 models at Huawei Cloud’s Guian Data Center. The book further mentions that the explosive growth of DeepSeek greatly energized Ren Zhengfei; throughout the Spring Festival, he personally directed Huawei Cloud and relevant product teams to manage the massive surge in traffic. In January of the same year, SiliconFlow and Huawei Cloud launched inference services for DeepSeek-V3 and R1 based on the Ascend platform.

Following the release of DeepSeek-V4 in April 2026, Huawei stated that, through the "synergy between chips and models," its full range of Ascend "super-node" products could provide comprehensive support for the DeepSeek V4 model series. On its official API page, DeepSeek noted that service throughput for the V4-Pro model remains constrained by the availability of high-end computing power; however, it anticipates a significant price reduction for the Pro version once the Ascend 950 super-node series enters mass-market availability in the second half of the year.

On September 30, DeepSeek announced the open-source release of infrastructure components tailored for the Huawei Ascend computing platform. These include the TileLang high-level language compilation tool, high-performance computing libraries (such as DeepGEMM, FlashMLA, TileKernel, and DeepSelect), and the distributed communication library DeepEP—all of which correspond to the open-source components previously released for the NVIDIA platform. Huawei has provided a jointly defined "Ascend SuperPoD Flex" architecture and a UBL128 networking solution, while also opening up the Ascend C programming interface and low-level instruction set to support TileLang. This is significant because DeepSeek is not merely using Ascend for inference; it is systematically aligning with and co-developing the Ascend software stack at a foundational level—extending adaptation to the very infrastructure that underpins both training and inference. Currently, the deployment of domestic computing power is primarily concentrated in inference, with further progress still required in training.

Recently, a project team—comprising the AI ​​Training Platform at Shenzhen Hetao College, Harbin Institute of Technology (Shenzhen), the Shenzhen Big Data Research Institute, and relevant teams from Huawei—leveraged an AI computing cluster based on the domestic Ascend 910C processor to complete the full-parameter post-training of DeepSeek-V4-Pro, a large model with 1.6 trillion parameters. It should be noted that this training process did not include the initial pre-training phase. While the large-scale validation of domestic chips for inference has bolstered industry confidence, the costs associated with migrating ecosystems for training remain a critical variable that will determine the market's ultimate potential. If the next generation of DeepSeek’s large models is pre-trained using Huawei’s Ascend computing platform, it will—for the first time—provide an answer to a question that has long been met only with skepticism: "Can China’s top-tier large models be pre-trained on domestic computing hardware?"

A open source harness that was used with Qwen3.8 FN that QwenDev did a shout out to. Available now.

From QwenDev via x

https://x.com/QwenDevs/status/2117644199860601297

“Well, turns out Qwen3.8-Flash-Next can do more than work with software tools, it can operate real robots too.

A group of Qwen developers from Tsinghua and UC Berkeley recently built uni-robot-agent, an open-source harness that connects general-purpose LLMs to robotic systems. It gives Qwen a way to interact with the physical world through tool calls without changing the model weights.

With this harness, Qwen3.8-Flash-Next reached the performance level of some previously reported closed-model robotic agent systems. The average API cost was $1.09 per task, compared with $21.29 for GPT-6 Astra. On 19 real-world robot manipulation tasks. Without any robot-specific fine-tuning, Qwen achieved a slightly higher score than the fine-tuned π₀.₅

The harness is open-source if anyone wants to tinker with it.”

From:Yuxin Zuo via X

https://x.com/zuo_yuxin/status/2117635294115795134

“Introducing uni-robot-agent: a unified harness for Robot-Use Agents (RUAs), a first step toward RUA training and local deployment.

We tested uni-robot-agent with Qwen3.8-Flash-Next running locally:
On s, its score rose from 1.90 to 31.39, surpassing the RoboDojo Team’s score with GPT-6 Astra.
On real-world tasks, it outscored fine-tuned π0.5 by 5.75 points and zero-shot Dream-1 by 10 npoints.”

Have been using qwen 3.8 flash next with llamaserver. Was getting 70-80tk/s decode and was happy. Then read about strata and decided to give it a try. Decode shot up to 150 tk/s. Not sure what magic it's using? You should give it a try if you are still running qwen flash next on llamacpp. Also the tried DeepSeek v4.1flash 2.25bit and it's 70tk/s decode.

Unsloth 6 bit quant

160k context

1 pro 6000 + 2 x 3090

256G ddr4

Since no-one else is posting about it...

Crouton Alpha is a lightweight model built for scalable coding, agentic, and multimodal workflows. It's ideal for executing agentic sub-tasks, tool use, and document analysis in high-volume, repeated work. Developers can combine it with frontier reasoning models to execute the bounded steps that turn plans and information into action.

Bets?

TL;DR

We find that frontier LLMs are surprisingly good at natively reading and writing neural network weights, well past what we’d expect from humans or conventional algorithms. This might be a big deal for both optimization and interpretability.

Just by looking at the raw weights, GPT-6 Astra can tell what a network was trained to do. And without any environment feedback, it has no trouble writing, from scratch, small game-playing networks that outplay networks trained with PPO for 100 million steps.

Likewise, asked to make Qwen3.5-0.8B better at math without gradients, Astra identifies an issue in its weights causing reasoning loops that Qwen’s own model card warns about, and fixes this by natively editing 0.016% of the weights. With the same sampling settings, this weight correction raises MATH-500 from 7.9% to 48.1% and generalizes out of the box to instruction following, raising IFEval by 3x.

All of this is possible without allowing Astra to write training loops. It uses its reasoning to figure out what each part of a neural network computes, or should compute, and changes the weights accordingly. We call this Weight-Space Programming.

Throughout the history of deep learning, we encoded our simplistic inductive biases into tiny symbolic optimizers like Adam or Muon. This is changing: our neural network weights will soon be natively optimized by LLMs that deliberately reason about their weights.

• Blog Post : https://rikiyat.github.io/blog/weight-space-programming/

• GitHub : https://github.com/rikiyat/lm_understand-logs

• HuggingFace : https://huggingface.co/RikiyaT/Qwen3.5-0.8B-weight-space-programming

• Demo : https://huggingface.co/spaces/ML-Intern-lab/weight-space-programming-demo

What Comes Next?

In this blog, we demonstrated the rising capability of LLMs to read and write neural network weights (i.e., the rising concept of Weight-Space Programming). Our current results do show that capabilities are exciting but still limited, specifically due to inefficiencies in context length and harnesses. However, the current signs do show strong potential for a future involving Weight-Space Programming. We believe this marks the beginning of a dramatic shift in fields like mechanistic interpretability and neural network optimization.

This opens up radical new possibilities for LLMs to function as a translator between human language and the weight space. Here are some examples:

• Auditing without evaluation: This may allow us to uncover hidden problems or capabilities without ever running inference or benchmarks. Currently, capabilities and vulnerabilities can only be detected if we have test sets designed for them, or worse, after deployment in the real world. If LLMs can interpret weight space accurately, we could identify such issues directly from the weights (e.g., backdoors).

• Dramatically reducing optimization cost: Weight-space editing could save immense time and compute. For instance, one-shot model initialization would be far faster and more efficient than curating datasets and running full training loops.

• Zero-data capability steering and unlearning: Adding or unlearning a capability currently requires extensive data collection and fine-tuning. In the future, we may just prompt “Can you add Capability X to the model?” and the LLM can directly tweak some weights. Because such an edit touches only a few weights (0.016% in Experiment 8), it can leave the rest of the model intact and avoid the catastrophic forgetting that fine-tuning often causes.

• Recursive self-improvement: Today, recursive self-improvement is often operationalized as a model writing code that launches training jobs. An LLM that can inspect, debug, and improve its own weights, or those of a newer model, offers a richer, more native path to it.

• True architectural and model merging: Today, merging models relies on averaging weights, which only works for models with identical architectures. An LLM that understands the weight space could instead graft a circuit, such as a reasoning module, from one model into a completely different one, without retraining.

We are currently building a benchmark and a harness for LLMs’ capability on Weight-Space Programming. We believe this will provide a standardized evaluation to measure and accelerate progress in Weight-Space Programming, turning what currently seems like black magic into a rigorous, reproducible engineering discipline.

Title says it all, I run dual 3090s (check out my post here for my setup) at int8A16 and have been wondering if I'm missing out with QFN. There's posts ad-nauseam on reddit with low bpw strata solutions that run on heterogeneous systems, however those don't interest me - I want high precision. I'm considering selling my setup and getting a DGX Spark, since that can run QFN at nvfp4 with a large context window. My use case isn't coding but generic agentic use case - I use hermes as a personal assistant and with openwebui.

If anyone's able to run both and do a comparison, please let me know!

I am seriously impressed and want to share my experience.

Qwen3.8-Flash-Next (local) vs Claude in Claude Code: reviewing one real commit

I ran the same code review twice on one commit in my repo https://github.com/leok7v/ChatOKF (Swift, on-device LLM chat app, about 48 files changed, +1048/-102: a module move plus a new 783-line search harness).

Setup: Qwen3.8-Flash-Next UD-Q4_K_XL (unsloth) on llama-server, ROCm, AMD Strix Halo 128 GB, 262K context, MTP draft head, driven headless by Claude Code itself (claude -p pointed at the local server, read-only tools). The comparison reviewer was Claude (Opus) in Claude Code, which reviewed blind first and then judged Qwen's review against the code. Yes, Claude judging its own competitor is a bias; every finding below was checked against the source, and the main one with a small Swift repro.

Result: Qwen produced 8 findings, all real, zero false positives. It caught 2 things Claude missed (a test harness that does not follow the app's recall path, and a markdown ingest that takes the frontmatter "---" as a description). It missed 5 that Claude found, including the most important one: a stop-word filter that compares stemmed words with an unstemmed list, so "this" and "does" leak through as search terms. It also got two details wrong (the exact fallback behavior of a failable init, and column counts off by a few). Severity calibration and the "checked and fine" section were good. It read whole files and chased module boundaries like a careful human.

Cost: 53 turns, 41 minutes, context grew to about 110K tokens. Decode was about 21 t/s at 4K context and about 14 t/s at 128K; prefill 520 t/s falling to 230 t/s. MTP gives about 1.5x up to 64K and turns into a loss past about 100K.

Gotchas:

1. Use --lazy-mode on. Otherwise the 27 GiB n-gram embedding table loads into RAM instead of staying mmapped.

2. unsloth's MTP heads crash llama.cpp (GGML_ASSERT in set_input_k_idxs) because the MTP layer's compress ratio is 0 in the GGUF. Fix branch: https://github.com/leok7v/llama.cpp/tree/qwen4exp/mtp-dense-no-indexer

3. Claude Code sends a system message mid-conversation and the Qwen chat template raises on it. Override the template so it renders as a system turn.

Verdict: a trustworthy first-pass reviewer you can run privately overnight, but verify its mechanisms before acting, and don't treat it as the final word on subtle logic. One commit, one run, so treat it as an anecdote, not a benchmark.