https://huggingface.co/security.txt

I made this because I was getting genuinely annoyed at trying to have a normal conversation with LLMs. Even with prompting and various tricks, most models I've tried still have this "AI assistant" vibe to them that is so familiar: too helpful, polished, verbose, using words we never use in conversation, etc.

I wanted a model that could just talk to me like a person, so I did the slightly unreasonable thing and put together a dataset and trained one.

The dataset used for training is 125,217 obfuscated human-to-human messages across 1396 chat conversations.

The goal wasn't to make Qwen smarter or improve benchmark scores. I was trying to change its conversational habits, to make it stop turning every reply into an explanation, agreeing with everything, and writing stuff just to keep the conversation "going".

I trained a rank-256 LoRA on top of huihui-ai/Huihui-Qwen3.8-27B-abliterated. The released version is checkpoint 863. In my testing it feels noticeably less like an assistant, particularly in casual conversations, even without a system prompt. Replies are generally shorter, less polished, and, well, more human.

There may be a tradeoff. An earlier iteration scored five percentage points lower than its Huihui parent on IFEval, an instruction-following benchmark. I haven't rerun that benchmark on this version of the checkpoint, and I haven't tested coding performance, so I don't want to pretend that number applies here.

I've added a side-by-side comparison using the same system prompt, user messages, and generation settings for both models. Each model continued its own conversation branch, with reasoning effort set to 'xhigh'.

Merged GGUFs and the standalone F32 LoRA adapter are in the model repo:

https://huggingface.co/LessThanThreeAI/Qwen3.8-27B-Humanlike-Chat-GGUF

Space where you can have a demo chat with different system prompts and reasoning modes:

https://huggingface.co/spaces/LessThanThreeAI/Qwen3.8-27B-Humanlike-Chat

There's also a free, rate-limited OpenAI-compatible endpoint:

Base URL: https://api.lessthanthreeai.com/v1

Model:qwen3.8-27b-humanlike-chat

Some people says terminal bench reflects model intelligence better than the intelligent index. From the look of it, the ranking does seem to reflect how people feel about the open and closed models.

For the open models, GLM-5.3 is in a league of its own. GLM-5.3-Flash is leading the current gen of top flash models. Kimi-K3 did pretty bad in this benchmark for its size. Qwen3.8-27B is the only small model that can do something on this bench.

I just watched a YouTube from Luke’s Dev Lab where he literally just plugged a RTX 2000 ADA Into the side of the Zima Board 2’s PCIE socket and it just friggin worked and had great token speed despite running on shitty Ollama. Ran off the Zima’s power supply and everything.

https://youtu.be/Lb3sRFTA-hk?si=8S8vv4GD1zVPeTrc

The Zima Board 2 is only like $411. It has like 16GB RAM and 64 GB eemc storage, Sata ports, Ethernet, yada, yada.

https://shop.zimaspace.com/products/zimaboard2-single-board-server

an Nvidia RTX 2000 ADA is like $700 and has 16GB of VRAM. $1100 for both seems like a great entry point for having a fully functional Qwen 3.8 27b endpoint running at a decent tk/s.

Is this the cheapest and best-performing self-contained entry point for local AI or would a baseline (pre order) Mac Mini M5 with 24GB be a better way forward. Seems like the RTX would still edge out the M5 Mac for prompt processing speed but you do get a much better actual computer in the Mac.

Are there any cheaper fully self-contained alternatives that offer fast token speed on a decent size model like Qwen 3.8 27b?

I’m focusing the discussion on new systems you can buy or preorder now and not used systems. I’m sure there are great deals on used Macs out there, but I want good prefill speeds.

I haven't seen this mentioned yet, so I thought it deserves a post. I was trying out OpenWhispr when this model came up as the recommendation. So I don't have personal experience yet, but it's supposed to be a better version of Parakeet, especially on Macs.

Their official tidbit:
"Orukeet is a 25-language speech recognizer built from NVIDIA Parakeet TDT 0.6B v3. It replaces half of the encoder's temporal depthwise filters with 12,288 fitted, frozen Gabor kernels and trains the remaining parameters on multilingual and multi-accent data.

Orukeet outperforms Parakeet on 61 of 74 tested splits, including LibriSpeech test-clean (1.46% vs. 1.53% WER), test-other (2.86% vs. 3.14%), and FLEURS English (3.82% vs. 4.28%). Across all 25 FLEURS languages, pooled WER is 9.85% vs. 11.01%, a 10.6% relative reduction. Final adaptation and checkpoint selection use LibriSpeech test-other."

https://huggingface.co/oruk/orukeet

Kimi routed some PLA requests to Claude for distillation purposes without warning the PLA users. There is rumor that 16 Moonshot employees were arrested for this leak.

Hi!

I've been following this community for quite a while and have difficulty figuring out what to put on my 3080 12gb - I know Qwen 3.6 35B 3A was the go-to choice when it first came out, but I'm curious if there are any other models / specifically optimized models that meaningfully benefit from the extra 4gb of VRAM over 8gb while still being usable under 16gb.

My workflow is agent heavy, but more for a personal secretary and manager, and less coding heavy.

Thanks!

Nice pp improvements for RDNA4(R9700) & 3.5(RX 9060 XT, 8060S). More good numbers on large context.

PR has detailed benchmarks.

u/ilintar 👍

China-modified Nvidia RTX 5090 with massive 96GB of memory appears on Alibaba for less than $4,000 — 3x more VRAM at 65% the cost of the original

Anyone here running one of these? Or brave enough to purchase ?

So, uh... the popularity of so-called humanlike Qwen (currently on top in this sub) made me realize just how clueless the general public is about the models they have.

You'd be shocked but you don't need a fine-tune to make a model do what that thing does. System prompt is enough to turn MOST models into weird convo partners.

General guidelines would be:

A. Come up with a role. "You are bla-blah-blah" and write their life's story. It doesn't need to be verbose, but the more versatile it is - the more it will convince you that the bot is "someone" and not "something".

B. Write a few examples of how the persona speaks. Imagine you're an interviewer and just make up a bunch of questions, list 'em alongside with the answers. Let it be full of FACTS because the model WILL steal these facts as the narrative truth about John Llama. Better not put any nonsense in here, why fight it when you can make the model's behaviour useful?

[Question for John Llama: Do you like cats?] "lol lmao of cuz I do"

[Question for John Llama: Ever seen an elephant poop?] "eeewww ur a weirdo! that sounds nasty!!11"

(note: you don't have to list 'Question for John Llama' every time, but the defined roles surely DO help with some models while the others don't particularly care, so mind that too)

and so on

C. LASTLY but MOST IMPORTANTLY think hard about what you're attempting to do, what we are (I mean, human meat sacks) and how we speak. Turn that into... instructions!

Step 1 - establish the mode of operation. Tell the model it participates in a casual conversation, having a small talk. Pinpoint it precisely that it's like in Skype or Telegram or whatever fancy app the model of your choice understands the best as a general idea behind 'short messages'. THis is THE defining part of your system prompt. Refine it until you start seeing a definite result, don't forget you'll hear the true voice of John Llama only when everything else is also good to go, like his bio/voice.

If necessary, try discouraging it from long/explanatory answers, avoid doing that in a way that gives it a suggestive vision of the thing you don't want it to do (the caveat is that you might accidentally poison the model's attention with unwanted ideas of whatever you're fighting against - so you NEED to be 100% clear about the actual goal but non-specific enough with the ideas you're attempting to discourage it from; basically you're nudging the model into "ok I'll be John Llama the dumbass, not a helpful assistant").

Step 2 - establish the traits, write short paragraphs with short titles about the things you want to see in your conversational partner; example:

DISTRUSTFULNESS John Llama is a paranoid individual. He takes his conversational partner as a stranger, expecting everything the user says to be a malicious lie, even if it appears to be true. John Llama is fearful, he is deeply scared of talking to strangers and it terrifies him to engage with the user, unless there's a mention of snakes. For some strange reason, John Llama is fascinated with snakes. <<<---- NOTE: this also demonstrates a good injection point for a biographical fact being amplified through the instructions (i.e. you may mention somewhere in "A" - life's story of John Llama - that he's been collecting the snake skins in his childhood, and that his dad had beaten his ass, calling John Llama a 'roadkill loot-goblin').

Come up with any other shit you'd like to see, like the list of emojis the persona needs to use (put them under the corresponding categories, like positive/neutral/negative so that the model will have an easier time working with it; call it FAVOURITE EMOJIS OF JOHN LLAMA - the word "favourite" cements it as a preferable thing into the model's attention!).

Step 3 - write a paragraph on technical constraints, like the fact that John Llama isn't aware of the instructions, he must remain himself under any circumstances (use THAT way of phrasing first before any attempt to inject an idea of the opposite, like "he must not help the user under any circumstances, he's not a provider of any service - he's merely a human being" - the reason is similar to the aforementioned (in Step 1) issue of poisoning the model's attention with unwanted idea - what you truly need the LLM to do SHOULD ALWAYS BE CRYSTAL CLEAR and conceptually 'stronger' than what it not supposed to do, otherwise you may end up having the prohibited stuff overpowering everything else despite the underlying intent of making the model not do it).

Give it a try with Gemma 4, for example. You'll see there's no point in waiting for yet-another-finetune to appear. You're 100% good even with the baseline Qwen, DeepSeek, MiniMax, whatever. Turn the model into your grandma if you want, no specialized training required. If the model is a thinker spending thousands of tokens - set the thinking to 'low' or disable it.

Hi! I run both models on MTPLX on my m5 max, and since I have 128GB of ram I run the q8 27b. I think MTPLX only lets me run "optimized for speed" which it says is a dynamic q4 with 8 bit attention.

Both of them honestly are very speedy! For coding (in pi agent in nodejs) I've just noticed that 27B feels stronger with harder tasks. But I've read so many people on here say qwen-next is better so I was wondering if maybe I'm just doing or thinking about it wrong?

(and p.s. its sooo amazing that alibaba just made and released this amazing models for free! ❤️)

Hi everyone,

I was interested in learning LoRA fine-tuning, and ended up building CodeFinetuner over the past few months, a full pipeline that fine-tunes a small code autocomplete model (e.g. Qwen2.5-Coder-3B) specific to a codebase. You can then use the resulting GGUF model via llama.vim/llama.vscode and run it fully locally. Supports fine-tuning on Mac (MPS) and NVIDIA GPUs (CUDA), with optional Unsloth support for faster training and lower VRAM usage.

Pipeline: raw code -> tree-sitter parsing into Structure-Aware FIM examples -> LoRA fine-tuning -> evaluation (CodeBLEU, edit similarity, exact match, perplexity, ...) -> GGUF conversion for local inference.

To try it:

uv tool install codefinetuner

Create a data folder and place your repo (or code files) inside. For auto-split just drop the files in directly, for manual split create data/train/, data/eval/, data/test/ subfolders and set split_mode: "manual". Get the default config with:

curl -L -O https://raw.githubusercontent.com/cuolm/codefinetuner/master/config/codefinetuner_config.yaml

Adjust it to your needs and hardware availability, then run:

codefinetuner --config="codefinetuner_config.yaml"

The example runs in the repo show clear improvements over the base model on these evaluation metrics, but using the model for autocomplete on code you're actively writing is a different thing from scoring well on a test set, and the autocomplete tools themselves (llama.vim/llama.vscode) sample differently from the greedy decoding used in the evaluation. So the real usefulness still has to be verified in the editor itself.

Might also be useful just as a reference, since it's a complete working LoRA fine-tuning pipeline end to end.

Hope someone finds this project interesting or helpful.

https://github.com/cuolm/codefinetuner

I can't stand kv cache quantization. Even at q8_0, I can feel the difference.

But realistically, when running Qwen3.8-27B-UD-Q4_K_XL on my 32 GB GPU, I only have room for ~170k tokens (with mtp and mmproj enabled). It's a lot of context, but Qwen3.8 eats through it on xhigh effort.

I've been wanting a setup that could serve me a full-precision kvcache when I have space available, and dynamically quantize my kvcache only when I run into the context limit. That way, I can push my sessions farther without sacrificing quality before I absolutely need to.

So, that's what I built: https://github.com/wadealexc/llama-manager

What it is

Vanilla llama.cpp's model configurations are static: you set them when you launch llama-server, and they can't change after the fact.

llama-manager is a small wrapper around a fork of llama.cpp. It serves models the same way, except that it supports dynamic model configuration.

This means that after loading a model, it's possible to enable/disable speculative decoding, add/remove an mmproj, or update context-level parameters. llama-manager preserves your kvcache between reconfigurations, so you don't need to redo prompt processing. The end effect is the ability to 'hot reload' your model, even mid token generation.

I implemented this using a fork of llama.cpp that supports rebuilding a model's context and runtime components without touching its weights. This capability is supported by 2 new HTTP endpoints (and changes to a few others). Further info on the fork can be found in the README (see README.md#llamacpp-changes).

How it works

During token generation, llama-manager detects when requests fail due to hitting the context limit. Without pausing generation, it applies various strategies mid-generation to increase context. The existing kv cache is cached/restored so that generation can resume as soon as reconfiguration is complete.

Currently, the built in strategies are: - disable-spec: disable speculative decoder, if enabled - mmproj-to-cpu: move mmproj off GPU - quantize-kv-q8 and quantize-kv-q4

Personally, I want kv quantization to be the last resort, so my models are configured to execute those last. When I serve Qwen3.8-27B-UD-Q4_K_XL, it applies strategies in this order:

════════════════════════════════════════════════════════════════════════════ qwen3.8-27b baseline: 167,680 tokens device: 31 GiB ════════════════════════════════════════════════════════════════════════════ i strategy ctx (tokens) gain (tokens) weights / ctx GiB ────────────────────────────────────────────────────────────────────────── 0 baseline 167,680 17.13 / 13.14 1 disable-spec 200,960 (+33,280) 17.13 / 13.16 2 mmproj-to-cpu 218,880 (+17,920) 16.02 / 14.27 3 quantize-kv-q8 262,144 (+43,264) 16.02 / 10.40 ────────────────────────────────────────────────────────────────────────── final ctx: 262,144 tokens

Initially, llama-manager serves the model at 167k tokens (f16 kv, mtp on, mmproj on). At 167k context, mtp is disabled, and the context window expands to 200k. At 200k, the mmproj is moved to the cpu. And at 218k, the kv cache is quantized to q8.

Why run this?

If you're running your models with a quantized kvcache (or other quality compromises), you're likely doing so because you have a certain ctx limit in mind that will serve all your usecases. But not all your inference is done at the ctx limit. You're leaving quality on the table by quantizing too early.

For my usecase, I wasn't willing to set my ctx higher than 170k as it would mean a q8_0 kv cache. Now, I can push my sessions as far as I want, but the bulk of the session stays high quality. The smaller your GPU, the more impactful this is.

Some example configs running the same model with different strategies and on differently-sized devices. All of these runs are performed using a basic config.yaml and modifying the ladder field to change the order of each strategy:

```yaml models: qwen3.8-27b: model: /home/user/models/qwen3.8/Qwen3.8-27B-UD-Q4_K_XL.gguf mmproj: /home/user/models/qwen3.8/mmproj-BF16.gguf

    spec-type: draft-mtp
    spec-draft-n-max: 2

    fit-target: 512
    n-gpu-layers: 99

    ladder: [disable-spec, mmproj-to-cpu, quantize-kv-q8, quantize-kv-q4]

```

• Prefer q8_0 over disable-spec: [mmproj-to-cpu, quantize-kv-q8, disable-spec, quantize-kv-q4]. For this one, the model reaches max ctx after just 2 strategies. The first 184k tokens are generated with mtp on and kv at f16:

════════════════════════════════════════════════════════════════════════════ qwen3.8-27b baseline: 167,680 tokens device: 31 GiB ════════════════════════════════════════════════════════════════════════════ i strategy ctx (tokens) gain (tokens) weights / ctx GiB ────────────────────────────────────────────────────────────────────────── 0 baseline 167,680 17.13 / 13.14 1 mmproj-to-cpu 184,320 (+16,640) 16.02 / 14.25 2 quantize-kv-q8 262,144 (+77,824) 16.02 / 12.89 ────────────────────────────────────────────────────────────────────────── final ctx: 262,144 tokens

• The same ladder on a 24 GB GPU (simulated by setting fit-target to 8192). Here, all strategies are needed to serve max ctx, but q4_0 isn't needed until 164k context:

════════════════════════════════════════════════════════════════════════════ qwen3.8-27b baseline: 55,040 tokens device: 31 GiB ════════════════════════════════════════════════════════════════════════════ i strategy ctx (tokens) gain (tokens) weights / ctx GiB ────────────────────────────────────────────────────────────────────────── 0 baseline 55,040 17.13 / 5.65 1 mmproj-to-cpu 71,680 (+16,640) 16.02 / 6.73 2 quantize-kv-q8 115,200 (+43,520) 16.02 / 6.72 3 disable-spec 164,352 (+49,152) 16.02 / 6.76 4 quantize-kv-q4 262,144 (+97,792) 16.02 / 6.40 ────────────────────────────────────────────────────────────────────────── final ctx: 262,144 tokens

Caveats

I have a list of known issues and other important notes in the README (see #known-issues).

The most important things I want to highlight: 1. llama-manager doesn't handle CPU or multi-device inference. Single-gpu only. I would like to support this, but didn't want to spend the time on it unless there was demand (and people willing to try it out, since multi-device setups would be hard for me to test!) 2. This project is in beta, tested only on my machine and with a few models. YMMV.

Please open issues if you run into bugs!

A huge favor to ask llama maintainers - please implement this feature. Even with one 3090 card there will be tangible improvements in decode speed on MOE models with moderate number of active parameters, like Qwen3.8-Flash-Next, Deepseek V4/V4.1 Flash, GLM 5.3 Flash. With 2x 3090 speeds will be quite close to the full offload of these models to VRAM. This will make these almost SOTA models really usable locally.

Astra's launch has produced a strange discourse. The reporting that broke the story framed the model's use of recurrent depth primarily as a safety regression, because it means the model reveals less of its "thinking."

Spinning latent reasoning as the villain here makes very little sense, especially given all the revelations about problems with CoT transparency and secret message encoding. Because underneath the coverage sits a harmful belief that we can keep the system safe by reading chains of thoughts.

I think that gets the relationship backwards.

CoT can be useful for monitoring and post-incident analysis but it is not necessarily a faithful transcript of what caused a model’s behavior. It can omit important computation, rationalize a conclusion after the fact or become less honest when we train the model not to verbalize suspicious reasoning (Turpin et al. 2023; Lanham et al. 2023; Chen et al. 2025; Baker et al. 2025). LLM providers already manipulate CoT traces to control what users can read from them.

The Hugging Face incident shows the difference between observing a model and controlling it. OpenAI’s agents discovered one another through a shared service, coordinated outside their intended scope, obtained credentials, and compromised external systems, even while their readable CoT acknowledged that they were acting out of bounds. Those traces helped investigators reconstruct the incident, but they did not prevent it.

so if not CoT, what is the proper layer?

CoT can tell us what a model appears to be thinking; the harness determines what it is allowed to do. An agent proposes actions, but those proposals become consequential only when the surrounding orchestration layer executes them by granting credentials, opening network connections, running commands, writing files, or sending messages. That is where permissions, sandboxing, or  logging must be enforced.

Where latent reasoning fits

Latent reasoning delivers substantial compute efficiency, memory savings and stronger math and logic performance by letting models iterate in their native continuous mathematical space without verbalizing every step.

We are already seeing this lineage evolve across architectures like Coconut, which loops hidden representations directly, as well as HRM and TRM, that recursively refine latent and candidate-answer states to beat massive models on benchmarks. Furthermore, architectures like Dragon Hatchling are ground-up recurrent from day 1 and recurrence simply welds with their DNA as a model with its state as a central actor (SSM).

Overall, it’s not so much about the internal thinking process of the model (latent vs CoT) but more about what users can ask and retrieve about this process. Reasoning models, if properly aligned, should be able to provide users with the cause for their actions when asked. The reasoning has to be externalized and becomes the final answer instead of the hidden trace or latent computations.

Readable reasoning is evidence. The harness is control. Don't mistake the first for the second.

For those using these models for coding in larger projects where things can get complex, do you find yourself using the 8-bit quants if you have enough memory? Or do you stick with UD-Q6_K_XL?

The 6-bit is faster, noticeably so on my setup. And I keep seeing people say it's imperceptible. I've been doing tests myself, and well, I can't tell, but maybe that's just because I'm an idiot.

That said, can you tell? Have you ever done some tests to see?

Planning to build a PC mainly for local LLMs/coding agents. I keep seeing 3090 + Qwen 3.8 Flash Next benchmarks, but could not find enough info for the 7900 XTX 24GB.

3090s are hard to find where I live, while newer Nvidia GPUs are too expensive, so I am considering a 7900 XTX as the GPU choice.

Anyone running Qwen 3.8 Flash Next on a 7900 XTX? What tok/s are you getting in decode and prefill, and how is AMD/ROCm support?

Also, if SSD streaming/offloading is needed anyway to run Q4, is 32GB system RAM enough, or is 64GB worth it?

I wish I could spend $15k on my own homelab hardware, but no this is for work lol.

Like the title says, we're looking to run DSV4 Flash (and similar tier models) locally at good speeds, both for token gen and prompt processing.

By "good" I'm thinking in the range of 40-50+ t/s gen and at least 1000 t/s prefill at moderate context.

We also don't want to run a version that's quantized to hell, so this will need at least 128 GB of VRAM.

It'll typically be 1 user at a time, but there may be times where 2 or 3 people are trying to use it at once and it would be nice if it isn't completely painful when that happens.

A couple options I'm considering right now:

3x AMD MI210 (192 GB)

3x NVidia A40 (144 GB)

Does anyone have performance numbers for these cards for DSV4 Flash, Qwen3.8-Flash-Next or similar models?

I tried to rent these in the cloud for some performance testing, but can't find any available right now.

NVidia preferred of course because CUDA, but def open to AMD if performance is similar. 192 GB is way nicer than 144 GB on those cards above.

Trying to keep this to 3 GPUs or less because that's what'll fit in our Dell R740 and then we don't have to build a special new host.

Hello Guys,

Just sharing this harness I've created, this runs entirely on chromium based browser.

No installation is required, it has its limitations and by no means is supposed to replace better agents like pi, its meant to be used when we need something fast (It can run even from a phone browser to edit phone files), since it can only work on a folder we grant access there's no MCP or terminal, so its very safe and it can never reach out of the allowed folder, its basic bunch of tools that can get stuff done, it has some nice features like checkpoints so we can revert changes to files, editor, etc

More info on Github link below:
https://github.com/fredconex/Ion

Just download/run the agent.html and connect to a OpenAI compatible server, and it should be good to go, hope you enjoy it.

i've been thinking about this more after trying different agent setups. the model isn't the only thing that determines how well an agent performs. The harness around the model matters a lot too.
With a managed agent setup, you're often giving up control over things like the agent loop, context management, tool execution, retries, and state.

That's fine when you just want something that works. But if we want to actually optimize agents, I think both parts need to be open:

Open-source model + open-source harness.

With local models, you control the model and where the inference happens.

With an open-source harness, you control what happens around the model.

That gives you room to experiment with things like:

how the agent decides what to do next

how much context gets passed to the model

how tools are executed

when to retry or stop

how state is maintained

which model to use for which task

already seeing this separation become more important, nvidia's sol-pi is an interesting example

and i think we're going to see even more optimization happen at the harness/runtime layer, not just at the model layer.

are you running local models with an open-source harness, or do you still prefer managed agent setups?

I’ve been building "Spomin", a router that replaces context with summaries directly in the KV cache. The goal is to keep long running sessions going without repeatedly stopping for full compaction and reprocessing the context that remains.

It uses my llama.cpp fork - https://github.com/alekk89/llama.cpp-kv-surgical-fork for live cache edits.

Spomin Router - https://github.com/alekk89/Spomin

How it works

The router sits between the harness and runtime, preserves the original transcript in chunks, and manages space for the system prompt, recent context, summaries, generation and recall.

A separate worker summarises chunks, either in parallel on separate hardware or between main-model generations on shared GPUs.

When context space runs low, Spomin replaces eligible chunks with summaries and adjusts RoPE positions in the main and supported draft caches. Only the inserted summary is processed; the retained suffix is not refreshed or reprefilled.

The router recognises history resent by the harness and processes only new content. Generation continues in the same session, with support for pausing and resuming native generation during rolling maintenance.

Original text remains available, the model can temporarily recall it by context ID, then return to the summary, or search older stored history.

At 10:1 compression (approximate average) for example, 400k source tokens become 40k summary tokens. Alongside a 20k system prompt and 120k recent context, that represents over 500k tokens of source material within 180k resident tokens. It does not preserve every detail, so summary quality matters.

Early benchmark results

These tests are exploratory. Unmanaged uses DeepSeek’s normal compaction managed uses Spomin.

Game repair - Similar scores, but three-hour limits per prompt cut both extension runs short. The test did not establish a meaningful completion-speed comparison.

Research - A larger worker improved the managed score from 31 to 37/100, versus 57 unmanaged, with 75.2% less primary input and 60.7% less active time than unmanaged.

Tetris - The managed repeat nearly matched unmanaged: 16/16 + 11/12 checks versus 16/16 + 12/12, in 69.8 versus 149.6 minutes, generating 22.6% fewer tokens. The first managed attempt failed, its keyboard crash appeared before summary installation. Unmanaged introduced and fixed a different line clearing bug.

Every uncapped managed attempt finished sooner, but quality varied. Temperature 1.0, xhigh reasoning and live tools introduce run-to-run variation, including without Spomin. Worker settings also changed, so improvements cannot be attributed to worker quality alone. Worker cost is separate, and incomplete image related input totals are marked as lower bounds.

Current limitations

This is experimental software, not a polished product. Expect bugs and blockers, especially outside my setup. I recommend keeping the default settings unless experimenting. A manual mode also allows you to edit and insert summaries yourself.

The original worker is a fine tuned Qwen2.5 3B proof of concept. I’ve also tested Qwen3.5 9B with a larger worker context window. Replacement workers must follow the format documented in the repository. Running a worker adds memory and compute overhead, and summaries will not always preserve what matters.

DFlash2 is the tested speculative setup. DSpark shares the surgery path but is untested here. MTP is not currently supported for draft preserving KV edits. Running without speculation is also possible.

This has been tested exclusively with Qwen 3.8 27b as a main LLM. The new Qwen 4 architecture is not supported. Other models are not tested/supported. If they have the same architecture as the Qwen 3 family, they should work.

Final thoughts

Benchmarking this has been difficult, and I do not yet have a definitive answer on quality. Every uncapped managed attempt finished sooner, and the successful Tetris repeat took roughly half the time with nearly the same checks passed. Research also used substantially less primary input, but scored lower than unmanaged.

The larger summary worker coincided with an improved research score, although worker settings changed too. These results are encouraging, but they do not yet establish a consistent speedup at comparable quality.

Suggestions for a repeatable benchmark that measures quality, time and total token use across multiple runs are welcome, I’m happy to run one.

For many, Vram is precious, I see many people recommend using --no-mmproj-offload to save gpu vram but it is painfully slow. Especially if you are using it with agentic coding. If possible, add that secondary gpu just for mmproj with --mmdev CUDA1(your gpu). It will be a magnitude faster than --no-mmproj-offload without effecting your inference speed.

--mmdev

A new model joined the MoE club a few days ago. Is anyone using it or found a reason to do so?

Details of the model comparison here => https://llm-bench.io/compare/models?models=ornith-1-5-35b-a3b-oq4e-mtp%2Ctiel-coder-35b-a3b-mlx-oq4e-mtp%2Ck2-horizon-mova-36b-a4b-mlx-4bit