Zero tokens, one honest number.

Models

LiquidAI/d1-3B and LiquidAI/d1-omni-600M (open weights, 7 October) are the first open members of Liquid AI’s d1 decision family. A decision model is not an assistant: you hand it a state (text, JSON, images, or a mix) and a set of named, typed questions — choice, noul (yes/no/unclear), score — and it returns an answer per question read straight off the model’s distribution over the options. Zero output tokens, no JSON to parse, one forward pass. d1-3B is a 3.12B model built from the decoder-only LFM2.5-VL-3B (SigLIP2 NaFlex 400M vision tower, 32,768-token context, 128k vocab). d1-omni-600M is the experimental one: 587M built from the bidirectional LFM2.5-Encoder-350M — a 381M shared trunk and decision head, a 94M vision encoder, a 112M FastConformer audio encoder, every modality running the same trunk weights — taking either text+image or text+30 s of speech.

The evidence. In three days the shelf has moved: d1-3B at 7,302 downloads / 241 likes, its official GGUF at 8,058 / 35 (Q4_K_M, Q8_0, BF16/F16, plus mmproj — day-one llama.cpp, which is what a decision model needs to be useful), and d1-omni-600M at 9,473 / 96. That is roughly 15k pulls on the 3B alone, the shape of a release people intend to run rather than bookmark. On the public Decision Index v0.2.1 split the 3B scores 48.57 — ahead of every model under 10B and above Decider 35B-A3B at 47.11, a model twelve times its size. On Liquid’s own seven-benchmark text table it means 82.9 against Decider 4B’s 81.1 and Decider 2B’s 77.1, and the 600M beats the 2B on toxicity detection and paraphrase identification. Latency, their numbers: 8 ms per question on an RTX 4090, 9 ms on an MI325X, 30 ms on an Apple M5 Pro, 16 ms on a Jetson AGX Thor, 50 ms on the smallest Orin Nano; three questions cost 1.3× one question, and packed batching hits 475 decisions a second on the 4090 and 1,106 on the MI325X. The honest gap in the release: the vision split of the index is private and not reported, and dedicated audio decision benchmarks don’t exist yet — Liquid says so on the card.

Verdict: Real deployment option — for the one slot it targets, the router/gate/judge position inside an agent or an app, where today people burn a generative model on classification and then parse its prose. Under 10 ms on a consumer GPU and 30 ms on a laptop is a different class of plumbing from “ask a 27B and hope the JSON parses.” The caveat is category-shaped: it decides, it does not converse, and the whole value depends on the probabilities being trustworthy — which is this post’s technical term below.

JetBrains/Mellum2.1-12B-A2.5B-Thinking (8 October) is the second version of the 12B MoE JetBrains open-sourced in June, and the architecture is deliberately unchanged: 12B total, 2.5B active, 28 layers, 64 experts with 8 routed, GQA 32/4, a 131,072-token context with 1,024-token sliding windows on three of every four layers, Apache-2.0. Everything that changed is post-training — reinforcement learning went from a short final stage to the main event, with millions of sandboxed runs across thousands of in-house environments and tasks in math, competitive programming, science, tool use and software engineering, so the model can explore a repo, edit files and check its own changes. Evidence: the official GGUF shelf (BF16, MXFP4_MOE, Q4_K_M, Q6_K, Q8_0) is up at 1,204 downloads / 44 likes in three days while the safetensors checkpoint sits at 198 / 82 — the local path is the one people are taking. JetBrains’ own table shows Mellum2.1 ahead of Mellum2 across LiveCodeBench, AIME, GPQA, BFCL, IFEval and SWE-Verified, and their speed claim is the interesting one: fastest in the group under heavy load, about 1.6× with multi-token prediction on a single request, and nearly twice the served tokens of Qwen3.5-9B on one H200. Verdict: Marginal — adopt only if you want a self-hosted coding sub-agent at 2.5B active on your own box; the vendor table is a vendor table, and the GGUF is the only local story worth chasing yet.

canberkkkkkk/ema-lightning (1 October) is the smallest genuinely interesting release of the week: a 5.6M-parameter DiT acoustic model plus a 3M vocoder, 8.6M parameters and about 34 MB in total, Apache-2.0, pip install ema-lightning, running on CPU or GPU with no API key and nothing leaving the machine. It is Turkish-only, and it streams — first audio in 3.86 ms and 440× faster than real time on an RTX 4090, 1,316× batched, about $0.0085 per million characters. Its own eval (Freya-TR-Eval) reports 0.92% WER, the lowest of everything measured there, including ElevenLabs v4, Gemini 3.8 and the 2.38B-parameter Trendyol-TTS. Verdict: Real deployment option for Turkish TTS on weak hardware — a 34 MB model that beats a 2.38B one on its own language is the small-model thesis working; the vendor-own eval and the single language are the limits.

One sub-gate line, because the counters matter: Qwen/Qwen-Image-2.1-Turbo (9 October) — Alibaba’s own 8-step, CFG-1 turbo checkpoint of Qwen-Image-2.1, same 7B generator, research-license — sits at 0 downloads / 343 likes, and roughly thirty derivative repos appeared in its first 24 hours (GGUF conversions, MLX 4/6/8-bit, NVFP4, INT8 ConvRot, an uncensored build) with zero downloads on every one. Too new to judge, and the batch-lag on counters cuts both ways; on the watchlist rather than in the verdicts.

Quantizations

ConwayResearch/Underdog-Saluki-27B-1.0 (8 October) is the build of the week for anyone who has been told a 27B-class model needs 54 GB. It is a single 7.89 GB IQ2-mix GGUF of Qwen3.8-27B, made through the ISTA-DASLab GSQ-RCO recipe, tuned specifically to keep tool calling intact — the thing low-bit quants usually destroy first. It runs in stock llama.cpp with --jinja -fa on, and there is an optional vision add-on (928 MB F16 or 629 MB Q8_0 mmproj). Evidence: 15,274 downloads / 212 likes in two days. The claim, on the author’s own frozen 120-task slice of BFCL v4 (thinking off, temperature 0): 88 passed versus 84 for the full 54 GB model, 42 versus 35 on parallel tool calls, and 96% average retention across nine benchmarks — and it also prints Bonsai 2 at 70 on the same harness, which is the comparison that matters, because a 6 GB ternary model with 4.4M downloads does worse on the one job this file was built for. Verdict: Real deployment option for the ≤8 GB / 16 GB-RAM class — a quant that beats its own full-precision parent on the metric it was tuned for is the rare case where “tuned” is not a euphemism. The bench is the vendor’s; the shape of the claim (a frozen public task set, the incumbent named, the number printed) is what a quant card should look like.

peasantsmith/GLM-5.3-Flash-Maya-GGUF (7 October) is the other end of the spectrum: four quantizations of Z.ai’s GLM-5.3-Flash (321B, ~18B active) for people with a real memory pool, built for a project called Maya that keeps the hottest experts on the GPU, the next tier in RAM and the rest on SSD. The ladder is explicit: Maya-S at 96.5 GB (routed experts at ~2 bits, attention and shared experts at 6-bit), Maya-S24 at 94.7 GB (attention and shared experts dropped to 4-bit so 24 GB cards keep ~1.5 GB more expert cache, up to 14% faster decode), Maya-M at 116 GB and Maya-L at 156.3 GB. Accuracy against the full-precision model on zero-shot tasks: 99.2% for Maya-L, 97.9% for Maya-S and Maya-M, 97.7% for Maya-S24. Two details earn the post: all four are built from Z.ai’s own FP8 release rather than a re-quantized file, and they use ISTA-DASLab’s GPTQ-style error-feedback rounding per expert against its own input statistics — the same lab whose GSQ-RCO recipe Saluki uses above. 13,089 downloads / 14 likes in three days. Verdict: Real deployment option for the 100 GB+ pool class; the 14 likes on 13k downloads is the tell that these files arrive by guide rather than by page visit, so read the tier table before pulling 156 GB.

The embeddinggemma-2 GGUF shelf. On 7 October this log noted Google’s multimodal embedding model as an applause-pattern one-liner: 364 downloads on the base repo, zero on the unsloth GGUF. Three days later the shelf is the story — unsloth/embeddinggemma-2-GGUF at 41,582 downloads and ggml-org’s own conversion at 12,634, against 29,185 on the base model. It is one embedding space for text, images, audio and video, with UD-Q4_K_XL through Q6_K_XL quants plus BF16/F16/Q8_0 and mmproj files. Verdict: Real deployment option for local multimodal retrieval — this is the retrieval half of a RAG stack that until now had to reach for a cloud embedder, and 54k pulls in three days says the gap was real.

The tape, one line each: SC117’s abliterated Flash-Next GSQ-RCO at 684,487 downloads (created 2 October, never printed here — an abliterated derivative of the ISTA Flash-Next quants, so the uncensoring wave has now reached the 125B-class MoE); ISTA’s own Coder-expert-pruned Flash-Next at 622,990 (351,230 on 4 October); orcarouter’s OrcaSAQ-2 Cyber GGUF at 21,406; Bonsai 2’s GGUF at 4,389,072 (batch-aggregate caveat stands); antirez’s V4.1 GGUFs at 1,694,196; unsloth’s Qwen3.8-27B-GGUF at 6,452,782 and the base at 6,783,589. The family is compounding; the numbers are snapshots.

Fine-tunes

nerkyor’s Coder390 line (4–6 October) is the week’s most legible fine-tune, because it names its base and its delta. The base is Qwen3.8-27B, already post-trained once (SFT + SimPO) in the same author’s EfficientThink chain; this version adds several more rounds of SFT and RLOO, and the stated target is specific: the model would fail to stop — it had the answer and kept re-deriving until it hit the 94K cap with no final answer. Same-harness numbers, against the FP8 baseline: GPQA 177/198 vs 177/198 (identical), MMLU 433/500 vs 444/500, LiveCodeBench 90/100 vs 83/100. So the real delta is coding plus a stopping habit, paid for with about 2.5% of general knowledge — and the baseline’s GPQA reasoning length is printed too (P50 5,299 / P70 12,607 / P90 50,577 tokens), which is how you check a “shorter thinking” claim instead of believing it. Adoption: 8,873 / 143 on the safetensors repo and 16,283 / 20 on the GGUF repo, which ships eight packages — Q2/Q3/Q4 LynnStyle with a built-in Q4_0 MTP head, the same three with a Q8_0 head, Q6_K and Q8_0 — plus NInfer packages with vision baked in. Verdict: Marginal — adopt only if you want an uncensored 27B coder that actually stops; +7 on LiveCodeBench for −11 on MMLU is a real trade, not a free upgrade, and the uncensored lineage is the reason the chain exists.

akatz-ai/MiniMax-H3-Person-Remover-LoRA (8 October) is the second video-editing adapter from the same author, after the Character-Swap LoRA this log covered on 29 September at 3,436 downloads — which has since reached 31,800 / 382, a ninefold move in eleven days, and is now the clearest sign that MiniMax H3’s real ecosystem is editing, not generation. The new one removes a chosen person from a shot and rebuilds the background: a rank-adapted Ref2VA LoRA plus a ComfyUI workflow that tracks the person with SAM 3.1, paints the mask green, and regenerates in overlapping windows, with the training dataset and config public and a 1080p comparison clip with original audio attached. 328 downloads / 39 likes in two days. The card is refreshingly honest: the showcase contains selected successes, not a benchmark, and background detail, camera movement, shadows and hard cuts still move. Verdict: Marginal — experimental, editing-niche, but it is the kind of adapter that makes an open video model actually usable for a task, and the receipts (dataset, workflow, timing) are all on the page.

Phocinae/Phocinae-Largha-150M-v1 (8 October) is a 144.3M ModernBERT encoder fine-tuned for typed decisions, Apache-2.0, with a self-host typed accuracy of 0.906 and 21.0 ms per decision at fp16 on an RTX 5090. Its tags are the interesting part — calibration, option-order-invariance, zero-output-tokens — because those are the three properties that decide whether a small decision model is a component or a toy. Adoption: 89 downloads / 230 likes, the applause-without-runners pattern (2.6 likes per download) this log has flagged three times this month. Verdict: Marginal — nobody is running it yet, but it is the first small encoder in this lane to advertise the invariance property instead of burying it, and that is the number to copy.

Technical term of the day: calibration

A decision model returns a probability, not a sentence, which means the number has to mean something. Calibration is the property that makes it true: across all the times the model says 0.62, roughly 62% of them should be correct. A model can be accurate and badly calibrated at the same time — 95% right overall, while every “0.99” it emits is really a coin flip. If you only ever take the top answer, that never bites you. The moment you set a threshold — auto-approve above 0.9, escalate below 0.5, block above 0.8 — the calibration is the feature, and an uncalibrated model fails silently: nothing crashes, the queue just starts filling with the wrong things.

How it is measured and fixed, practically. Expected calibration error (ECE) buckets predictions by confidence and compares each bucket’s average confidence to its actual accuracy; the Brier score is the mean squared error of the probability itself, which punishes confident mistakes hardest. Both are cheap to compute on a held-out set you labelled yourself — a few hundred rows is enough to see the shape. The usual fix is temperature scaling: divide the logits by one number fitted on that set, which softens an overconfident model without changing which answer wins. Train-time cousins: label smoothing and Brier-style losses (Cloudflare’s Clef card named both), and the awkward truth that RLHF-style preference training tends to decalibrate models, because nothing in the objective rewards a well-priced maybe.

The sibling failure is order dependence, and it is why “option-order-invariance” shows up next to “calibration” on the Largha card. Shuffle the answer choices and an uncalibrated model changes its mind; a calibrated one does not, because the probability should not know which line the option is printed on. Liquid AI’s own write-up says the thing that helped most was unglamorous: training on long inputs, shuffling answer options, and fixing shortcuts in the data “made a bigger difference than more advanced techniques.” For anyone building locally, that is the whole lesson in one sentence — the cheap data hygiene beats the clever method, and you can test for it in an afternoon by re-ordering your options and re-running.

Where this sits in the month’s tape: TypeSafe’s kev-0.5b shipped with its temperature-scaled ECE printed (0.065 → 0.031); Clef was trained with label-smoothed cross-entropy plus a Brier loss; the GEV family gates its adaptive thinking on a probability crossing 0.8; and now d1-3B’s headline claim is not accuracy but a position on a decision index. The lane has quietly agreed that the score is the product. Which means the questions to ask a decision model are no longer “how smart is it” but: what is your ECE, does your answer survive a shuffle, and what happens at your threshold?

Harness improvements

llama.cpp b11515–b11540 (7–10 October) has one change every script will notice: the server’s default port moves from 8080 to 9931 (#30159) — quiet, sensible, and a broken reverse proxy if you pin versions. The decision-lane plumbing keeps deepening: exact GELU for ModernBERT encoders (#30108) and classifier_activation support for rerankers (#29692) are what make the small decision encoders (Largha, the reranker family) score correctly rather than approximately. Elsewhere: MoE cache spread over multiple GPUs (#30112); a DFlash output-head sharing fix (#30111) that reads tied weights and embeddings from GGUF metadata; a CUDA radix top-k (#28713) that cuts top-k cost on qwen4exp at 34,816 tokens; Metal 128/96 flash-attention kernels (#30209); SYCL work including MXFP4 MoE with arithmetic decoding and weight reordering (#29809) and FWHT optimizations — the Walsh–Hadamard transform that ternary weights need, now on a fourth backend after the Musa FWHT fix (#30167); WebGPU 2D dispatch for one-dimensional ops and DUP support in the mixed-batch path; Vulkan top-k and rms_norm fixes.

Ollama v0.40.1 + v0.40.2 (7–8 October) introduces something new under the hood: models you already downloaded are now upgraded in the background on first run for better performance and llama.cpp compatibility, with the original kept as a backup and a documented command to reclaim the space. It is the first time Ollama rewrites blobs you already have, and it is worth knowing before you wonder why your disk grew. Plus a fix for Clef decision-head reads past the 2 GiB boundary on Windows.

Pi v1.1.0 (7 October) and the v1.0.4 line add program status reporting (OSC 7501): terminals and agent dashboards can now show whether Pi is working, blocked on a dialog or login, done, or failed — with the error — without scraping the window title, which is the kind of plumbing multi-agent setups need and rarely get. Claude Haiku 5.5 enters the catalog with adaptive thinking up to max effort, and tool selection became additive: pi -t +codemode,-write adjusts the defaults instead of replacing them, with * patterns and --no-mcp in v1.0.4.

oh-my-pi v18.8.0–v18.8.7 (7–9 October) is a week of credential and context hygiene: warm-cache-aware conversation pruning keeps pruned history inside the model’s prompt-cache lookback window, so trimming a session stops throwing away the cache you just paid for; OAuth account pools can now be restricted per session, so a restricted run will not silently fall back to another account; a single transient token-refresh failure no longer ends a running session with a false “no API key” error; Gemini and Cloud Code requests stop failing on JSON-Schema keywords they do not support; and an Anthropic image-byte budget stops long screenshot-heavy sessions from tripping request-size limits.

Hermes v0.21.6 (8 October) is the first patch tag cut by the new stable release pipeline — one attempt ref, a tested Docker image, and a receipt tag at publish — rolling up the window since v2026.9.24: 8,867 non-merge commits, 8,342 changed files (+772,490 / −225,600), 2,106 merged PRs and 3,027 closed issues. The curated notes ship with v0.22.0, so read this one as the pipeline proving itself rather than a feature list.

And the one this log has never printed: NInfer. It is a from-scratch C++/CUDA inference engine for a deliberately closed set of Qwen checkpoints on a single NVIDIA RTX 5090 — the build rejects anything but sm_120a — running text, image and video prompts through a CLI or OpenAI-/Anthropic-compatible HTTP APIs, with 1–8 execution lanes fixed at startup, prefix caching, and a scheduler that can pause a request under memory pressure and resume it. Its artifacts are a single .ninfer file (v3: configuration, encoded weights, logical bindings and frontend resources together), which is why you keep seeing them beside ordinary GGUFs. The numbers are the surprise: neroued/Qwen3.8-27B-NInfer at 409,464 downloads and its NVFP4 sibling at 392,923 — per-artifact traffic that dwarfs most “popular” GGUF repos this log covers — and the format has spread to community builds (a Ternary-Bonsai-2 NInfer at 43,758; a Swift-1.5 GSQ-RCO NInfer at 8,018; nerkyor’s new GGUF-NInfer shelf above). 2.9k stars, 566 forks, Apache-2.0, one maintainer. The harness angle landed this week too: OMP NInfer packages the engine with oh-my-pi and durable checkpoints, so a coding agent can resume from saved model state instead of re-prefilling a 240k-token context. It is not a llama.cpp replacement — one GPU, one resident model, on purpose — but it is the biggest local-inference thing this feed never named, and 400k downloads per artifact is the evidence.

The through-line this week is unglamorous and consistent: the models got smaller and the numbers got more specific. A 3B that answers in one pass, a 7.89 GB build that beats its 54 GB parent at the one job it was tuned for, a 34 MB voice that outscores a 2.38B one, a 12B MoE that was retrained almost entirely on post-training. None of it is a benchmark headline. All of it is checkable — which is the only kind of claim worth a post.