What happened
In a post dated November 3, 2026, Sebastian Raschka says he is catching up on ten open LLM architecture releases from the preceding month. He calls the cluster “Open October” and presents architecture diagrams and fact sheets for the models. The post is a catalog of stated designs, not a shared benchmark: it does not compare model quality, serving cost, deployment requirements, or results on a common workload.
The list starts with Kolibri-1 (78B), which uses grouped-query attention (GQA) and sliding-window attention (SWA). Ling 3.1 Flash (560B) uses Kimi Delta Attention and a gated multi-head latent attention design inspired by DeepSeek. Muse Spark Open (816B) is described as Meta’s first major open-weight release since Llama, apart from Muse Glimmer. Raschka says it combines GQA and SWA with a LatentMoE design.
Raschka also includes Nemotron 3.5 Super VL (120B), which combines Mamba-2 layers with eight attention layers and uses LatentMoE. Dory1.0 (4B) uses a looped-transformer design. Reflection Beam (501B) uses GQA and SWA. For Recursive Flint (40B), Raschka notes that “Recursive” is the company name, not a description of the design, and calls its architecture a fairly standard mixture of experts, or MoE, with GQA and SWA.
The final three entries are MiniMax M3.1-Flash (428B), with MiniMax Sparse Attention; LFM3 (1.7B), which mixes short convolutions and attention; and Mistral Large 4 (1T), which combines multi-head latent attention, or MLA, with sparse attention. Across the ten entries, the recurring contrast is not simply model scale. The list spans conventional attention combinations, sparse expert routing, hybrid recurrent-style layers, convolution-attention mixtures, and looped transformer designs.
Raschka says he plans to discuss the releases in greater depth in a forthcoming Substack article. The roundup itself supplies diagrams and concise architectural labels rather than implementation documentation. It does not specify access terms, licenses, prices, serving limits, supported hardware, or an operational route for trying any of the ten models.
What the archive adds
We have not covered this before; it opens a new thread. New Runtime’s October 21 note on <a href="https://newruntime.com/posts/the-companion-jais-asr-notes-describe-an-open-1cbe78/">Jais-ASR</a> concerned an open Arabic speech-recognition model, a separate release and use case. It does not establish prior coverage of the models in Raschka’s roundup.
Trend signal
This does not yet fit a pattern New Runtime tracks. The roundup identifies architecture choices, but it does not show that a particular design improves completed-task economics, agent interoperability, verification capacity, or another tracked operating condition.
Why it matters
For teams evaluating open-weight models, architecture labels are useful prompts for investigation, not deployment answers. GQA, sliding windows, sparse attention, latent attention, MoE routing, Mamba-2 layers, and convolutional components point to different technical approaches. They can help a team identify which release documentation, inference implementations, and benchmark results to examine next.
That distinction matters because parameter count is a poor substitute for operating evidence. A 1T model and a 1.7B model belong in very different planning conversations, but size alone does not establish memory use, throughput, latency, output quality, supported context lengths, or fit with a particular serving stack. Nor does an MoE label, by itself, establish an inference-cost advantage for a team’s workload.
The practical value of this roundup is therefore its role as a candidate index. Teams can turn each entry into an evaluation checklist: confirm whether weights and code can actually be accessed, read the license, find supported inference software, establish hardware and latency constraints, and test a representative task set. The architecture descriptions help define questions; they do not resolve them.
Limits and uncertainty
Raschka’s post is an architecture roundup, not a benchmark or deployment study. It reports no shared task evaluations, measured inference costs, latency figures, hardware requirements, or controlled comparisons between the releases. It also does not state license terms, hosting arrangements, access conditions, pricing, or rate limits for the models.
The architectural details are Raschka’s descriptions of the releases and have not been independently checked here against model weights, code, or technical papers. The post also does not explain how the listed components were implemented, trained, or configured in each model. No conclusion about production suitability, efficiency, or quality follows from parameter counts and architecture labels alone.
Skill to build now
Create a repeatable model-intake sheet before adding an open-weight candidate to a roadmap. Record the license, weight availability, supported inference runtime, target hardware, context requirement, expected throughput, and a small set of real tasks with pass criteria. Use architecture as one field in that sheet, not as the selection criterion. If you are comparing models, run the same prompts, tools, and verification checks for each candidate.
Reader takeaway
“Open October” is a useful index of ten open-weight releases and their stated architectural ingredients. Treat it as a map for further investigation, not a ranking. Before choosing a model, verify access and licensing, then benchmark candidates against the tasks, hardware, latency, and reliability requirements that actually constrain your product.