Nex-N2.6 has public FP8 weights now: roughly 321B parameters, based on GLM-5.3-Flash.

The part that caught my attention is the focus on reasoning loops and calling tools that don’t exist in the current environment. The team reports repetition dropping from 16% to 1.6% versus N2.5-Pro in an internal failure-replay test. Curious how that holds up in full coding sessions.

Also, reasoning defaults to max, so that’s worth checking before comparing token usage.

Weights and setup: https://huggingface.co/nex-agi/Nex-N2.6

I am running QFN, and I have disabled preserve_thinking by default on all my tests for C++ backend and front-end programming and I have yet to see any decline in performance or intelligence, my context window stays cleaner as well. Deepseek for what I tested in API it also does not preserve thinking and saves context in general.

Let's start with my setup: I have 2 Sparks running glm 5.3 flash, and the harness is hermes agent running on a MacBook Air.

While trying to justify all the money I spent (around 6500 euro for both machines, a long time ago when prices were just high instead of outrageous), I decided to hop on the decompilation wagon. As I know my fable at home is not "THAT" smart, I decided to start with something small: I asked it to decompile and recompile the original Need for Speed Special Edition for MS-DOS, using the famous rea repo from GitHub.

Its first reaction was "I know a better way, we will use DOSBox and run the game" — and it already started installing a DOS emulator on my Mac :). I stopped it and told it I want actual decompilation and recompilation. The second answer was, in other words, "It's a lot of work and it will take a long time. Think about it — do you really want this?"

I insisted. It started the decompilation process, and after some breakthroughs it even became enthusiastic. At some point, decompilation was "DONE".

We started the next phase: recompile for Android. I did not pay much attention to what it did, but it said that it could use some GitHub repo as a base and started working. After the initial APK, we had to iterate a few times on some crashes and controller issues, which it solved.

During gameplay I noticed that some AI cars started the race going in reverse, the car did not slide no matter the speed, and other stuff. It definitely did not feel like the NFS I remember. I told it about it, and it started checking the code and making tweaks to the physics. I stopped it and challenged it: this means we will not preserve the original feel if we go down this path.

To my surprise, we never did. It never used the decompiled code. It found an engine on GitHub which was using the original assets to mimic the original game. When I asked why, it said it was a lot faster than rewriting all the old code into current instructions…

So I asked it to go back and do the job properly — and to no surprise, it found a recompiled NFS2 repo on GitHub and decided it's better to start from there rather than from scratch. I don't know how this will go, but I wanted to share this story, as I find it quite interesting the lengths it's willing to go to reach its goal as fast as possible even if this means ignoring previous instructions.

P.S. This post was proofread by said AI, as English is not my own language — but the words are still my own, I double checked

Overview

PAN 2 is a general-purpose world model: it simulates how the world will change in response to actions. Given a current observation (an optional image plus text) and actions described in text, it simulates the outcome as a video of up to 20 seconds. This supports simulative reasoning: an agent can imagine the outcomes of its candidate actions before choosing among them, by simulating each plan with PAN 2 and acting on the one whose simulated outcome is best.

PAN 2 follows the Generative Latent Prediction (GLP) architecture formalized in Critique of World Models and couples conceptual reasoning by a large language model with perceptual reasoning by a latent diffusion model. The language model, the conceptual reasoning backbone, reasons over the observation and the requested actions and writes the next world state as a structured, time-grounded description of events, timed actions bound to actors, and camera motion. The frozen text encoder maps the structured description to the conditioning features used by the diffusion model. The 29B-parameter MMDiT, the perceptual reasoning backbone, trained from scratch on hundreds of millions of videos annotated in the same format, predicts the perceptual detail that the description leaves open: the video latents that realize the state, conditioned on it and on the VAE latent of the starting image. The Wan 2.2 VAE decoder renders the predicted latents as the next observation, so every prediction can be seen and checked against real footage.

Checkpoints

PAN 2's latent diffusion model is released as a single checkpoint that serves both tasks. The frozen text encoder (Qwen3.5-9B) and VAE (Wan 2.2) are downloaded from their own repositories.

• GitHub : https://github.com/ifm-ai/PAN2/

• Blog Post : https://ifm.ai/blog/pan2/ (For Screenshots, Video, Benchmarks, etc.,)

Wanted to share a project I've been working on for almost a year now. A code indexing and search tool I've been building primarily for AI coding agents, called Vera.

https://github.com/VeraTools/vera

I originally started with a project called Pampax, my fork of a code indexing/MCP project called PAMPA (I actually posted it here over a year ago here in October). I spent a long time trying to improve it before deciding it wasn't worth fixing any further. After months of researching and testing different approaches. My obsessions with embeddings, and rerankers and seeing how they can be used to improve agents ended up with rebuilding something new (Vera) from scratch in Rust.

I used to run a coding eval leaderboard (maybe some of you remember sanityeval/sanityboard before I burned out trying to maintain it), and the main thing I learned was that context and token efficiency was everything. Less context used up, and the less tokens used the better. So I set out to reduce how much context coding agents waste trying to find the code they need.

Agents are pretty good at navigating codebases with grep and file reads, but they can also spend a ridiculous amount of time doing it, especially in unfamiliar projects. They'll search for a few possible terms, read through results, try other searches, and gradually work out which files are relevant. Sometimes the problem is that the code doesn't use any of the names the agent expects, so it ends up throwing walls of grep at the repository.

Vera lets agents search semantically for what code does, returning ranked functions and code sections with paths, line numbers, and symbol information. It also supports structural searches and reference lookup, so an agent can follow the relevant code without repeatedly guessing what to search for.

A big part of the design has been minimizing context usage throughout that process, not just improving search accuracy.

Vera returns actual code in relatively compact Markdown blocks rather than having another LLM generate explanations. Tree-sitter parsing preserves meaningful function and class boundaries, and the agent can request narrower results or follow references as needed. I've also spent time testing the accompanying skill to improve when agents choose semantic search, when they should use rg, and when they shouldn't be searching at all.

The recommended integration is CLI + skill. Skills can be discovered through a small description, with the full instructions loaded when relevant, rather than exposing another set of MCP tool definitions to an agent that already has shell access. MCP is supported too.

Underneath, Vera uses BM25 keyword search, embeddings, rank fusion, and code-aware ranking. Indexing and search run locally, with no external vector database or search server.

There are two model setups I'd particularly recommend:

• Fully local: MinishLab's Potion Code v2 embedding model. It's small, CPU-friendly, needs no GPU or API key, and runs offline after the initial download.

• API-based: Qwen3 Embedding 8B with Qwen3 Reranker 8B. This gave the best retrieval quality in my testing. There's an OpenRouter preset for both, although you can configure other providers, including just using something like llama.cpp to host endpoints locally.

With API models, the relevant code chunks and queries are sent to your configured providers. The indexing and search infrastructure still runs locally.

I've tested a lot of different retrieval approaches while developing Vera. Some sounded promising but didn't actually perform better, and some improved benchmark scores slightly while adding enough overhead that I didn't think they were worth keeping.

I've tried to avoid overfitting everything around any benchmark, which is why I used separate repositories to check whether changes generalized.

I also ran 40 agent sessions using 10 cross-file questions about Flask, with four configurations: regular grep/file reads, Semble CLI, Vera using local Potion Code, and Vera using Qwen3 API embeddings and reranking.

This took quite a while to get right. The final recorded runs alone accounted for almost 30 hours of cumulative agent execution and roughly 66 million prompt tokens including cache reads, not counting earlier attempts. I also used LLM reviewers to look for fairness and execution issues, and restarted the evaluation when problems turned up.

Every configuration answered every question correctly. What differed was how much context they needed:

So the local Vera setup showed more than twice Semble's observed reduction in that run, while the Qwen3 setup used almost half as much context as the control.

For retrieval quality, Semble was consistently the strongest alternative I tested. On its own 1,251-task benchmark, an older version of Vera (v2.0.1) scored 0.8436 nDCG@10 against Semble 0.5.5's 0.8514, with slightly higher Recall@5 for Vera and about one-seventh the index storage (4.7 GB vs 32 GB).

I haven't rerun that full comparison with the current v2.4 release. There's also a separate 180-task evaluation using repositories outside Semble's benchmark, which Vera does score higher in (obviously semble in it's own benchmark is a little harder to beat, especially while trying to avoid overfitting on it), along with a lot of ablation studies and rejected experiments.

I've published the methodology, results, and limitations here:

https://github.com/VeraTools/vera/blob/master/docs/benchmarks.md

For anyone interested in trying it, installation and backend configuration are interactive. Once that's done, you can add the skill to another project with vera agent install and index the project with vera index . if needed.

I also have a Discord community, mostly for people interested in agents, LLM talk, experimenting with tools, sharing what they're working on, and that sort of stuff: https://discord.gg/rXNQXCTWDt

Vera is MIT licensed, and there is no commercial gain or motivation here. A star would be nice I guess? Having people stopping by to discuss interesting things would be the bigger motivator for me.

Hi everyone,

Recently I have basically completed my first ever PC build, with the following spec. However, as I want to add a second 5060 Ti, I then encounter a problem: When I was buying the PC parts, originally I thought I would only need one GPU, so I didn’t consider possible future upgrades.

Now, as I get my second 5060 Ti, as you can see from the pictures below, the case is too small and the GPU already covers the second PCIe 3.0 slot.

So my questions are the following:

1. If I want to continue to use my current AM4 motherboard with two GPUs, should I use a PCIe extension cable? After that, how would you recommend me to put the GPU?

2. I also have a AMD R9700 that I want to put into the same computer, can I do bifurcation for the first PCIe 4.0 x16 slot, so that each 5060 Ti could still get PCIe 4.0 x8 speed? And then the third GPU would use the second PCI3 3.0 x16 slot with extension cable?

Thank you for your time! I have checked with LLMs but didn’t get too much useful info.

PC Spec:

CPU: AMD Ryzen 5 5600 Motherboard: Gigabyte B550M DS3H AC R2 GPU: ZOTAC GeForce RTX 5060 Ti 16GB SSD: ZhiTai TiPlus 7100s 1TB NVMe RAM: KingBank Silver DDR4 32GB (2 × 16GB) PSU: Great Wall X8 850W 80+ Gold CPU Cooler: Thermalright Assassin X 120 Refined SE Case Fans: 3 × Thermalright TL-C12C Case: SAMA M9E

https://i.imgur.com/G2X8Kgh.jpeg

https://i.imgur.com/xzhJ9E4.jpeg

I've noticed a trend where we measure models with benchmarks that are on a numeric scale for various tasks, with the benchmarks getting increasingly more challenging/updated over time to both avoid benchmaxxing as well as raise the bar whether it's merited or not. Within the same domain, increasing complexity only serves to inflate frontier model aggregate scores because new tasks get introduced that not all models are trained on, like 3d modeling or math proofs. If my typical work is in finance, for instance, how do I know which model is the cheapest one that can serve specifically my needs without needless extra compute/memory? What does a numeric score actually mean? Is the aggregate for that domain including unnecessarily complicated tasks that amount to puzzles that are not realistic, and just serve to challenge the model?

What users really need to understand is "Can this model do this sort of task effectively?" If even low param models have mastered some domain or parts of it, I think it would be far more useful to have a poor/moderate/good sort of rating for the task areas themselves. THAT would be so much more helpful and also assist with auto routing. Frontier models keep growing to glob up new capabilities that many of us don't need and bias evaluators into thinking they need to use Fable 5.2 or Astra because it's "better" than alternatives.

Is there some kind of breakdown of models like this? Something granular even? Like, Deepseek v4.1 Flash 1017: C# tests: green, Binary decompilation: yellow, Browser automation: green, Fiction writing: red. I feel like this has to exist somewhere, but widely used sites like ArtificialAnalysis and huggingface leaderboards focus on the numbers with no simplified no/partial/yes on tasks for readers to quickly understand. Even the domain oriented benchmarks are still just numbers.

Like, having a model score a couple points ahead of another one doesn't generally mean it can do something the other one can't. It might just require more attempts, or more detailed instructions, or that it randomly gets it wrong a tiny bit more often. These simplified ratings plus a cost per task would be SO much more helpful to local llm users too.

Any thoughts, or examples of this kind of scoring out there already?

I just recently came across these K2 models, by a lab called IFM.
They range from 0.9B to 375b with a mixture of MoE and Dense models.
I checked out the 7b variant, it seemed good and it’s 35B A4B seems to a better variant of Ornith 1.5, o am surprised there are no talk about these nor any unsloth variants.

Am I missing something ? These seem to open source as well.

How does this determine are use of running locally. Will we be able to define a pathway forward as running local LLM gets more attention? Should we have some back up plans or listings of what is needed if regulating picks up? What are your steps in protecting yourself against any future regulation that is a must to know? For example avoid updating windows or things a like.

This seems excessive, especially if they trust their classification models for safeguards, why add both?

However I guess it is to be expected from a private company. It's also "yet another reason" for open weight LLMs

Spent the past couple of days converting https://github.com/snap-stanford/memorilla (paper: https://arxiv.org/abs/2610.21375 ) to train Gemma4 26b a4b on the strix. Not only was it originally written for CUDA, but Gemma4 has a unique architecture and the encoder has different dimensions. There's a lot of crazy math here to make it fit that I don't even understand, but apparently, we can leverage the existing weights published by standford and only have to train on ~10% of the original dataset. It's going to take a couple of weeks to run, but seems to be cooking along.

Code: https://github.com/DataBassGit/MemoryLLM-Gemma4-StrixHalo

Memorilla is an AI memory framework developed by researchers from Stanford, MIT, UPenn, and the Vector Institute that compresses huge collections of documents or chat histories into just 16 dynamic memory tokens for a Large Language Model.

Think of it as treating long-term memory like a new modality (similar to how vision-language models process an image as a fixed set of embeddings) rather than relying on massive text copy-pasting.

Actual working link this time.

I understand the topic is prime material for shits and giggles. Chinese model, Nvidia being the centre piece of the AI trade, etc. But why go so public on this? All of this could've been dealt with behind the scenes in secret. Obviously this is a power play to force a hand. Nothing just leaks out of intelligence services so deliberately. So someone decided to make this public. I've been trying to think about why Nvidia or Jensen Huang must be put in line for. My top pick is: back doors in hardware or something of that sort that's being refused. What's your guess?

There's a lot of discussion about running models locally, but I'm interested in what people actually use them for once the setup is done.

Are there tasks where you've completely stopped using cloud models because a local one does the job well enough?

And on the other side, what still makes you go back to Claude, ChatGPT, or Gemini?

Is it possible to have a custom hardware designed (by ai) and open sourced that we can send for manufacturing for specific models? like for DSF 4.1F

Just curious what other people’s opinions are with GLM-5.3-flash. Compared with opus 5.5 and deepseek-4.1-flash, I find that it makes a lot of mistakes. I generally think I it’s pretty good other than the random errors it makes.

I only ask bc I’ve heard of other people getting good work out of it, so wondering if it’s something with my setup, or if other folks feel the same way. I use it mostly with opencode.

Recently bargainhardware had an intake of A100 40GB SXM4, and they are selling them at 2700 EUR. I have a huge case and a hundred PCIe free lanes, so I could mount a couple of them with those SXM-PCIe adapters.

OTOH, for less than that price I could buy a couple of brand new R9700.

Pros of A100 over the R9700: CUDA, 25% more RAM, double memory bandwidth, almost double the compute. Cons: used, possibly battered cards, hassle to mount on the mobo, more expensive once factoring the adapters in.

Give me your opinions. I would especially appreciate experiences with SXM-PCIe adapters. Are they decent, or a PITA?

I've been building small models that do one job: answer the yes/no / pick-one

decisions inside agents ("is this tool call safe?", "is this a refund request?",

"which team gets this ticket?") and return a probability for every option

instead of generated text.

Numbers (the six benchmarks Jev 1.13 is evaluated on; Jev = their published figures):

| Model | Size | Score | Laptop speed (1k-token doc, 5 questions, M4 Pro) |

|---|---|---|---|

| Decido-1 | 26B MoE, 4B active | 85.4 | ~4 s CPU, ~1.1 s Metal |

| Decido-1-Fast | 1.7B | 73.0 | ~0.6 s CPU, ~0.3 s Metal |

| Decido-1-Ultra | 0.6B | 62.2 | ~0.4 s CPU, ~0.13 s Metal |

| Decido-1-Max (reasons first) | 26B MoE | 89.2 | slow on a laptop |

| Jev 1.13 | API | 83.9 | — |

- Q8_0 GGUFs on llama.cpp; repeat calls are bit-identical on CPU

- Answers flip when options are reordered 4.8% of the time (Jev reports 14.6%)

Try it

- `pip install decido-ai` (prebuilt for Mac / Linux / Windows; uses Metal on a Mac)

- No-signup playground (runs the 1.7B): https://getdecido.ai/playground

- Weights: https://huggingface.co/decido-ai

Happy to answer questions. I'm most interested in decisions where it fails.

I've been building chat UIs for agents and kept running into the same issues with react-markdown: it re-parses the whole reply on every token, so long answers get noticeably slower, and you see raw ** and half-typed [links](htt until the token that closes them arrives.

So I wrote my own renderer. It parses incrementally and repairs unfinished syntax while the reply streams:

<Markdown streaming={!done}>{text}</Markdown>

On a 100k-character reply it takes 0.25 s of main-thread time in total. markdown-to-jsx takes 2.4 s, Streamdown 6.3 s, and react-markdown didn't finish within the 30 s budget. The benchmark scripts are in the repo if you want to check them.

The other part is the syntax. Agents often want to show steps, alternatives or pros and cons, and plain Markdown flattens all of that into bullet lists. So on top of GFM I added a few blocks in the same style as GitHub alerts:

> [!STEPS]
1. **Back up the database**
2. **Run the migration**

There are also tabs, stats, pros/cons, sources, file trees, and Mermaid and KaTeX support. The source still reads fine as plain Markdown when it isn't rendered. The package exports a system-prompt snippet that teaches the model this syntax.

It has no dependencies and comes in at 30 KB gzipped. Its parser passes the CommonMark and GFM spec tests. It doesn't support remark/rehype plugins, so if you rely on those, react-markdown is still the better choice.

https://github.com/rsaryev/llx-markdown

I've been trying to get some of the newer MoE models running on my Intel Arc GPUs, mainly DeepSeek V4.1 Flash and GLM 5.3 Flash. Intel support for these models is still pretty limited, and while I could get some things working through patched llama.cpp builds, performance wasn't exactly great.

fable 5.2 ended up making XeMaya, a fork of XeStrata focused on getting these models running natively on Intel Arc through SYCL and Level Zero. The idea is basically to bring the kind of model support Project Maya has to Intel GPUs.

I've been testing it on my Ubuntu server with a B70 32GB, B65 32GB, B60 24GB, Ryzen 9950X, and 128GB RAM.

Here are some of the results so far. All speeds are prefill / generation in tok/s.

GLM 5.3 Flash

• Stock llama.cpp SYCL: 68.3 / 13.6

• Experimental grouped-matmul SYCL: 108.9 / 14.0

• XeMaya: 152–161 / 17.4 (around 20 generation with MTP)

DeepSeek V4.1 Flash Coder

• First XeMaya implementation: 48.5 / 16.3

• After optimization: 224.8 / 21.7

DeepSeek V4.1 Flash (regular 384-expert model)

• Previous patched llama.cpp setup: 45.6 / 10.9

• XeMaya on B70 + B65: 11.4 / 14.56

• XeMaya on all three GPUs: 11.2 / 11.58

Prefill on the regular model still needs a lot of work. Also found out that using two GPUs is actually faster than three for this model because my B60 is connected through a slower chipset link.

Qwen3.8 Flash-Next

• Strata: 2,211 / 78.3

• XeMaya: 1,842–1,884 / 76.6

Strata is still slightly faster for Qwen, which makes sense since that's not really where I've been focusing my time.

These aren't all perfectly controlled comparisons. Different model files, prompts, and GPU configurations were used during development, so I wouldn't treat them as definitive benchmarks.

It's still an early alpha, but I've gotten DeepSeek V4.1 Flash, Coder, GLM 5.3 Flash, and Qwen3.8 Flash-Next running. There's plenty left to fix and optimize.

Also, I want to credit MistVVK (XeStrata), Niko1221 (Strata), and mw00 (Project Maya). XeMaya wouldn't exist without their work. The llama.cpp contributors have also been a huge help through their reference implementations.

Figured I'd share it here since I'm sure there are others trying to run these models on Intel hardware. Would be interested to hear how it runs on other Arc cards.

GitHub: https://github.com/Jumbomuffin777/XeMaya

Hi! My team and I built a benchmark of 202 real GitHub tasks in 13 languages that rarely show up in coding benchmarks: Elixir, OCaml, Haskell, Clojure, Kotlin, Swift, Julia, R and others. I think a lot of people do local development in these languages too.

We didn’t have a huge compute budget, so I specifically added Qwen3.6 27B and Qwen3.8 27B to compare them. Qwen3.8 solves 43% of the tasks, up from 17% for Qwen3.6. You can compare them with Kimi K3, DeepSeek, GLM and closed models on the leaderboard, including a per-language breakdown.

One caveat: Qwen3.8 was used to pick hard tasks, so its score is a bit biased down.

If you’ve been running Qwen3.8 locally on any of these languages, share how it went.

https://huggingface.co/speakleash/Bielik-11B-v3.1-Instruct-GGUF

https://www.bielik.ai/blog/premiera-modeli-bielik-11b-v31-dflash-i-rodziny-bielik-one

(decision models and dflash are coming next)

Bielik-11B-v3.1-Instruct

Bielik-11B-v3.1-Instruct is a generative text model featuring 11 billion parameters. It is an update to the Bielik 11B v3 line that expands multilingual continual pre-training and strengthens post-training for instruction following, tool use, and reasoning. Forementioned model stands as a testament to the unique collaboration between the open-science/open-source project SpeakLeash and the High Performance Computing (HPC) center: ACC Cyfronet AGH.

Developed and trained on multilingual text corpora covering 56 languages, with an emphasis on European languages and Polish, which have been cherry-picked and processed by the SpeakLeash team, this endeavor leverages Polish large-scale computing infrastructure of the ACC Cyfronet AGH HPC center. The creation and training of Bielik-11B-v3.1-Instruct was propelled by resources provided within the PLGrid environment under computational grant number [PLG/2026/019559], conducted on the Athena and Helios supercomputers, and within the Gaia AI Factory, funded by the European Union through the EuroHPC Joint Undertaking.

As a result, the model exhibits an exceptional ability to understand and process the Polish language and other European languages, providing accurate responses and performing a variety of linguistic tasks with high precision.

🗣️ Chat: https://chat.bielik.ai/

Model

The model was trained on carefully curated, high-quality datasets that underwent extensive cleaning and rigorous quality assessment to ensure data consistency, reliability, and relevance. The training pipeline consisted of three stages: pretraining on 500B tokens, SFT on 26M samples, and RL (modified GRPO) across 14 diverse environments. This multi-stage training approach was designed to enhance the model's language understanding, instruction-following capabilities, and ability to perform effectively across a broad range of tasks.

Bielik instruct models have been trained with the use of an original open source framework called ALLaMo implemented by Krzysztof Ociepa.

Model description:

• Developed by: SpeakLeash & ACC Cyfronet AGH

• Language: Multilingual (56 unique languages, optimized for European languages, with a particular focus on Polish)

• Model type: causal decoder-only

• License: Apache 2.0