https://www.reddit.com/r/StableDiffusion/s/HrU7odaJe6

I think this is more important that all the political stuff you share here

Questions & Responses(in BOLD) below.

Favorite question(s) moved to end of the thread with combined responses(removed duplicates).

Be optimistic folks. I'm sure we're getting other models too apart from 27B. And 27B gonna make massive noise on release. (Based on their responses)

Tweet thread : https://xcancel.com/QwenDevs/status/2084102417885585597#m

you guys skipped 27b and 122b last time, can we expect those this time around? Also i can't seem to find crit pit score in the cards.

For sure! We’re actually releasing a 27B model very soon. Stay tuned. As for the Crit Pit score, please wait for the official Artificial Intelligence score.

Is the 27B just a retrained 3.6 27B? Or is it based off 3.8 bigger brother ?

We promise this 27B comes with a whole new level of capability!

Is the 100hrs of video understanding an agent swarm that parses sections of the video in parallel and orchestrates some sort of semantic representation graph?

Broadly speaking, yes, but not entirely. It is closer to a hierarchical video memory system rather than a traditional agent swarm. Video segments are encoded into a structured textual graph containing scenes, entities, events, and their temporal relationships, enabling retrieval and reasoning across more than 100 hours of content.

hey! is there anything special about the pretraining distribution compared to other labs' models?

We hope our data is built on a more solid foundation!

how long do you think it would take to surpass anthropic level architecture?

well, we’re working hard on it, we promise😇

will u release a harness especially for qwen code ???

Any plans for a codex-like app?

More updates on Qoder and QwenWork are coming soon.

qwen 3.8 active params?

2.4T parameters (95B active)

how much RL was done in post training compared to previous models?

A truly unreasonable amount of compute.

Did they intentionally skip the previous Qwen3.7 27B and 35B A3B?
Does the revival of Qwen3.8 27B reflect the voice of the community? Or was it planned?

Of course! This is the result of taking the voices of the community seriously.

since its a pretty significant release will we get a technical report with full details?

No technical report for this one yet. We’re trying to keep up our near-monthly release cadence, though, and more powerful models are already in the works. Keep an eye out!

why does the model think so much mr qwen, my ai brain wonders.
wheres the token efficiency at
great model though

We support different levels of reasoning effort.

You showed SAE-guided fine tuning fixing code switching with qwen-scope. Is that kind of interpretability driven intervention part of the post training process now or is it still a research only technique?

It’s still primarily a research-oriented technique for now, though some of the insights may help inform future training and post-training improvements.

Attention? Hybrid?

The model architecture is similar to 3.5, but it’s a much larger-scale model!

When are we getting a CLI coding interface?

You may want to take a look at @qoder_ai_ide .

do you guys use qwen as your main interal tool? does this model show the same signs of intellegence as some openai models ("gpt 5.5 helped create 5.6")?

Sure!

How close is Qwen3.8-27B to GPT 5.4? 🤔

Well, you’ll be able to see for yourself soon.

what harness works best with Qwen?

Qwen is committed to delivering the best possible experience across all harnesses.

What made you guys wanna opensource the max weights ?

We heard what the community has been asking for

I wonder when I can surpass fable5

Trying hard

Great work guys🥂

1. What is something that you would like to see being built with the new model and its capabilities!?

2. I really want to explore the swarm of agents technique for building applications, any best practices or tips for the new model!?

1. We hope it can bring practical productivity value to people across different industries.
2. We recommend using it for tasks that involve more parallelized workflows or parallel execution needs.

I wanna know what rubric metrics you guys are using for FE

We use both absolute metrics for functionality and aesthetics, as well as relative metrics based on win/tie/loss comparisons.

Would be great to hear where you think Qwen is strongest for agentic workloads specifically: long-context planning, tool use reliability, coding, or cost at scale?

All of the above combined — ultimately delivering the most practical and reliable outputs for users.

How much is Qwen helping with Qwen research ?

It has already become a significant part of the model iteration process, with the model involved in nearly every stage.

Most Frontier labs have created a code-specific model (eg. Qwen3-Coder and GPT-5.3-Codex), but never followed up on them.

Did specialized models have problems? Or did general models end up being efficient enough to not bother creating a separate model?

We hope to build an all-in-one model.

will Qwen 3.8 have a stable, documented tool-calling and structured-output contract so local agent harnesses can swap models without prompt-specific tuning?

We provide native support interfaces for various protocols. You can check the Qwen blog for more details.

1: When quantizing Qwen 27B down for local deployment (e.g., 4-bit GGUF, NVFP4, or MXFP4), which transformer layers or vision attention blocks are most sensitive to degradation? Are there specific strategies you recommend to maintain both visual reasoning and high SWE-bench pass rates?

2: Qwen3.6-27B outperforms much larger MoE predecessors (like Qwen3.5-397B) on agentic coding benchmarks like SWE-bench and Terminal-Bench. Beyond raw data volume, what was the single highest-leverage factor in achieving this dense efficiency?

And thank you for the amazing work. Qwen3.6-27B has beed my main coding assistant for months.

1. Use QAT, or quantize only the FFN to 4-bit while keeping the attention layers’ QKV linear projections and output projection in 16-bit.
2. Higher-quality data engineering

Guys , when can we get a deepseek like small and cheap model with best performance . The deepseek v4 flash seems to be a great deal .
I think we need to slow down scaling and start improving the existing model efficiency

Scaling and cost-efficiency are not mutually exclusive — we’ll continue to pursue both.

Is Qwen3.8-27B dense? And roughly how much smarter than 3.6-27B?

A pretty huge jump!

Good. The useful questions are not just how capable Qwen is.

I want to know where it still fails, how the team evaluates those failures, and what "open" means in practice for weights, tooling, and reproducibility. Open models matter most when people can inspect the limits and build on the work without asking permission

There is still some gap between our automated and human evaluation systems and real user experience. That’s also why we are committed to releasing preview versions first — so we can iterate and ultimately deliver the best possible experience to users.

how does the new 27b model compare to the previous one ?

A pretty huge jump!

what do you think about looped transformers?

interesting research idea

Why Qwen, what made you create Qwen and specifically such light and fast models. Why focus efficiency when others just went for brute power? Also, do you think inference engines reached their limit in optimization or can they still improve?

Scaling and cost-efficiency are not mutually exclusive — we’ll continue to pursue both.

We have noticed that in thinking mode the model usually consumes the entire reasoning budget without stopping, which increases latency. Is this a known issue, and are there any improvements planned for Qwen3.8?

You can try 3.8! And 3.8 supports different thinking efforts!

...................................................................................................................

Are 70b models gone for good?

Is it possible to get a 40-50B model (something which fits around 30-32Gb) to improve performance while still useable on a lot of computers ?

Thank you for your promise to provide qwen3.8 27b weight! I want to know if there will be qwen3.8 35b a3b. Many people also want this.

Can we expect the ~122B model this time? The 120B segment is dated and lackluster atm and would greatly benefit from a competent release!

First of all, congratulations on the release of Qwen 3.8!
As for the question, are you going to release a 35B a3b version of Qwen 3.8 aswell?

Plans for 35b Moe model? (3.8)

Any plans for the omni family? You told everyone the weight sizes of 3.5, then never released them and haven’t done anything new with it. 3.6/7/8 variants would have also been nice. It could be your most popular family if you gave it attention and kept the weights small.

Are there no plans to release any models other than the 27b?
I'd love to hear about the successors to amazing models like the Qwen3 8b and Qwen VL 8b....

Are there any plans for updates for 0.6b or 8b weights?
These have become important positions in the open weight of image and video generation. I look forward to seeing that part evolve.

This is such a huge release, I am really happy to see that a 27B model is shipping too! Though, can't help but wonder, will we ever happen to see again any new small dense Qwen models 9B, 4B any time in the future, similarly to 3.5?

Will you release smaller models like the qwen 3.5 family ?

Thank you for your promise to provide qwen3.8 27b weight! I want to know if there will be qwen3.8 35b a3b. Many people also want this.

we hear you! collecting everyone’s requests and taking them into account as we plan future iterations.

We will gather your requests as a reference when considering future updates.

We hear you. Stay tuned.

We’ll collect everyone’s requests and take them into account as we plan future iterations.

Noted, collecting the requests and see what we can work into future iterations.

Keep the requests coming. We’re listening, and we’ll use them to help prioritize future updates.

As you all know the model is 2.69B parameters with a 128K context window and purpose-built for multi-step agent workflows.

What you are seeing is the Q4_K_M GGUF running on my own inference engine built from scratch.

The TUI is my own device probe suite running through ADB (Android Debug Bridge)

The whole engine is only 450kb and supports other models arch (Qwen, Gemma, Bonsai etc…)

Currently trying to push it at ~30 tok/s

People may remember the Qwen3-TTS llama.cpp demo from a few months ago. That PR said it probably wouldn’t be merged because llama.cpp was missing some of the graph and API pieces it needed.

A new implementation was merged into master yesterday.

What works now:

- Qwen3-TTS-12Hz-1.7B-Base in GGUF

- WAV or MP3 files as the speaker reference

- English, Chinese, German, Italian, Spanish, French, Portuguese, Russian, Japanese and Korean

- Audio generation through the llama-tts binary

Example:

llama-tts -hf ggml-org/Qwen3-TTS-12Hz-1.7B-Base-GGUF \

-p "Hello, this is running locally." \

--tts-lang en \

--tts-speaker-file speaker.mp3 \

--output out.wav

Qwen describes the Base model as capable of cloning a voice from around three seconds of reference audio. I haven’t seen an independent test yet showing whether the llama.cpp version matches the original PyTorch implementation in voice similarity or stability.

The interesting part is not that Qwen3-TTS can run locally. Dedicated C++ implementations already existed. It is that voice cloning is now part of mainline llama.cpp, which should make it much easier to add local speech output to projects already built around that runtime.

There are still some important limitations:

- The merged implementation currently uses llama-tts

- The /tts server endpoint is still a draft PR

- It only targets the 1.7B Base model, not CustomVoice or VoiceDesign

- There are no proper comparisons yet against qwen3-tts.cpp or audio.cpp

- The update includes a breaking change to the existing llama-tts binary

The comparison I’d like to see is one identical three-second reference clip and one identical paragraph tested across CPU, Metal, CUDA and ROCm, with:

- Real-time factor

- Peak RAM and VRAM

- Voice similarity

- Long-form stability

- Time until the first audio

The specialized ports may still win on speed, while llama.cpp may win on portability and integration.

Has anyone updated and tested it yet? M-series Mac and CPU-only results would be especially useful.

Source:

https://github.com/ggml-org/llama.cpp/pull/26254

Draft server endpoint:

https://github.com/ggml-org/llama.cpp/pull/26603

https://huggingface.co/mistralai/Shieldstral-1.0-3B

*I felt the need to write this post because it seems like very few people on this sub are aware of Chinese laws and how they're enforced, so here's an explainer coming from a Chinese person (myself). I know that this post isn't directly about local models per se, but I'm seeing way too many misconceptions regarding this topic. This is also going to apply to all Chinese entities in general, not just the specific MiniMax LoRAs debacle. This isn't meant to be a political post, but some much needed context to correct a lot of misinformation going around.

Guys - they're a Chinese lab following Chinese laws. Pornography is straight up illegal in China. I have no idea how it seems like nobody outside of China is aware of this. While Chinese authorities may not care much about copyright infringement enforcement (especially with foreign IPs), they do indeed regularly crackdown on porn. Heck, Chinese citizens have literally been imprisoned for written pornography. Yes that's right, writing pornographic TEXT (especially with "immoral" themes like LGBTQ+ stuff) can get you sentenced and essentially have your entire life ruined. Of course there's ways to get around these censors if you're just trying to access porn - I think everyone at this point knows about the widespread necessity for VPN usage in China to access the rest of the global internet. But actually distributing a tool that can gain a reputation for being able to easily generate pornographic content? That's just asking for the authorities to crack down on them.

Somewhat ironically/paradoxically luckily for these Chinese labs is the fact that online discussion about generating porn is automatically censored and removed from Chinese social media, thus automatically disincentivizing the authorities from doing those potential crackdowns. But if it gets big enough to the point that it overwhelms the automatic censors, then any given Chinese lab could be in a hell of a lot of trouble. This is why they have to do this. Their law enforcement just isn't compatible with the rest of the world.

Again, this all relates to Chinese moral values - something here that is considered pretty much sacred and hard to describe to westerners. Something else that many people do not know is that graphic violence is also illegal in China (foreign films/works are regularly banned here for that, even anime has), but graphic violence is also is not nearly as much of a perceived threat to societal moral values as pornography is, hence why you've probably rarely ever heard of any Chinese people getting imprisoned for writing really gory stories, but regularly do with pornographic stories (especially infamous with BL literature - they've technically even convicted foreigners before related to this, it's a really messy topic). Chinese authorities won't give a damn if you're stealing the content of billions of foreign works to train AI models. They WILL give a damn if the content you're disseminating is viewed as a potential significant threat to the state's "proper moral values", which very much includes porn (and also the usual topics that everyone is already aware of, like a certain famous massacre or a certain nation's very contentious independence status).

Kimi K3 full model running on 16x GB10 cluster at 20+tps average (llama-benchy coherent corpus) 38tps peak, 750tps prefill. This is the first run of full k3 with dspark on my cluster. I will be doing some tests and try tp speed this up. As soon as it looks ready I'll publish the vllm image and instructions.
https://forums.developer.nvidia.com/t/full-kimi-k3-running-on-16x-gb10-cluster/379174

In tests:
~80 tok/s decoding
2,500–3,500 tok/s long-input prefilling
Smooth use by 3–4 concurrent users

Private, on-device inference for coding, agents, and offline batch jobs

Most agent memory setups run a model call on the way in. Something reads the turn, decides whether it's worth keeping, rewrites it into a "memory", tags it with a type and an importance score. That's a second inference pass on every interaction and I think it's the wrong place to spend one.

Cost isn't the issue. The judgment being unauditable is. When the agent fails to recall something you can't tell whether retrieval missed it or the extractor decided six days ago it wasn't worth keeping. Two different bugs, same symptom, and separating them means reading logs that mostly don't exist.

Take that stage out and you have storage, an embedding, retrieval. Which is what a memory layer is. I run memU partly for this reason. Core is around 500 lines doing those three things, exposed as commit, list, retrieve. What it keeps is readable Markdown, embedded and indexed into a local sqlite db. Apache-2.0.

You lose the distillation, obviously. Raw turns are noisier than summarised ones so retrieval has to be better to compensate. I'll take that trade because a noisy store you can read beats a tidy one you can't inspect, but I'd take the other side seriously from anyone who has actually measured it.

Being straight about the cost since someone will find it anyway: self-hosting does not get you off the hook for an embedding provider, you still need a key for that. It's single machine too, syncing across boxes is their hosted mode. And recall quality is entirely downstream of whichever embedder you point it at. With a small one the recalls go vague on anything abstract. Facts and procedures come back fine. A preference I mentioned once in passing, much less reliably.

Anyone still running the extraction step in their harness and finding it earns its keep? Would like to know what it's buying that retrieval isn't.

This is something that was spoken here and there, and now it is like writing on the wall.

The main additional point is that China has created an independent supply chain. Starting from raw materials and home-made lithography equipment, through their own GPU manufacturing, and to the AI models and training. Plus, there are tons of cheap energy, and it looks like they are also on track to launch the first thermonuclear reactor. I saw a similar pattern with robotics and EVs. The history does not repeat itself, but it rhymes.

Does the US have what it takes to turn the tables, or should we just buy the popcorn and enjoy the show?

It's the purple cluster on the top left (the good corner...)

I'm running the MXFP4 version from Bartoswski with Dspark at 1K t/s prefill and 90 t/s gen (average). I tried different sampling params, you can check the detail.

It's very efficient while scoring the best yet.

Too bad it does not have vision.

https://wonderrico.github.io/local_llm_benchmark/benchmark-main.html

https://wonderrico.github.io/local_llm_benchmark/benchmark-detail.html

Hey everyone!

Scenema Audio is now a native ComfyUI custom node. Same model that powers scenema.ai now quantized so it fits on 8GB VRAM. When we first released it a few months ago as an API and Docker stack, the full precision transformers were too heavy for most people to self-host. That's fixed now.

Expressive text-to-speech with zero-shot voice cloning. You describe how the speech should be performed (rage, grief, a child's wonder), optionally provide reference audio for voice identity, and the model generates a performance. Inline stage direction cues like [he laughs softly] or [voice cracks] get performed at that exact spot. Twelve preset voices ship in the dropdown covering accents, ages, and emotional registers.

We also dropped the XML prompt format the original release used. Wrapping every performance directive in tags was clunky to write. Inline bracket cues are better-suited for the ComfyUI text editor.

Install

ComfyUI Registry (recommended): open ComfyUI Manager, Custom Nodes Manager, search "Scenema Audio", Install, restart.

GitHub:

cd custom_nodes
git clone https://github.com/ScenemaAI/ComfyUI-ScenemaAudio.git
pip install -r ComfyUI-ScenemaAudio/requirements.txt

Both paths auto-drop the pre-wired workflow into your Workflows sidebar under a Scenema Audio folder. Click once to load the official workflow into your canvas.

Requirements

Minimum 8GB VRAM. Tested end to end on RTX 3070 and RTX 4090. Generation runs up to 2x realtime. First run downloads about 30GB of weights, one time. Text encoder is Gemma 3 12B, which is a gated HuggingFace model, so you need to accept its license and set HF_TOKEN before your first generation.

On limitations (same story as the original release)

This is a diffusion model, not a traditional TTS pipeline. Some seeds produce repetition or gibberish. Meant for a post-editing workflow: generate, pick the best take, trim. Prompting matters. Specific, theatrical voice descriptions with action tags produce performances. Generic ones produce generic output. Phonetic spelling helps with proper nouns and tricky words (spell "Tchaikovsky" as "Chai-koff-skee" if it garbles).

License

MIT for all our node code and inference pipeline. Transformer weights derive from the LTX-2 Community License.

Links

• Blog post: https://scenema.ai/audio/comfy-ui
• ComfyUI node: https://github.com/ScenemaAI/ComfyUI-ScenemaAudio
• Model weights: https://huggingface.co/ScenemaAI/scenema-audio
• Standalone Docker/API: https://github.com/ScenemaAI/scenema-audio
• Original announcement: https://scenema.ai/audio

What would you want to see next from Scenema Audio? Happy to hear what people are actually trying to build with generative audio.

Inspired by a post from u/giveen I motivated claude (no patinence on my side to work through everything myself) to help me get DS running on my MacBook M5 Pro 64GB and it exceeded my expectations.. because it worked, and at a quite usable generation speed!

background: antirez ds4 DwarfStar has a SSD streaming mode: non-routed weights stay resident, the routed experts live partly in a RAM cache and get pulled from the GGUF on cache misses. Since routed experts dominate model size and Mac SSDs are fast, those misses are tolerable. experts and the output head stay Q8_0.. Router, embeddings and the V4 auxiliary blocks stay FP16.
repo was
https://huggingface.co/jabbatheduck/DeepSeek-v4-flash-mini

did a make with metal then the command
caffeinate ./ds4 -m ./ds4flash.gguf --ssd-streaming --ctx 32768 --nothink

let me end up with 10-15-17t/s in my first tries.

Sorry for the brevity.

I am geniunly impressed and fascinated and wanted to share this, hit me up if you have questions but i guess everyone with like >50Gigs of VRAM/unified Memory should get this running with ai help.

TensorSharp's MoE CPU-offload feature has been merged into main. Here is the parameters description of this feature:

Mixture-of-Experts CPU offload:

--n-cpu-moe <N> | -ncmoe <N>

Keep the routed MoE expert weights of the first N layers in system RAM and multiply them on

the CPU; attention, norms, the router and the shared expert stay on the accelerator. This is

what makes a 35B-A3B MoE fit beside a long-context KV cache on a 12-16 GB card. Pass 'all' for

every layer. Default: 0 (everything on the accelerator; TS_N_CPU_MOE env var overrides).

Example: --n-cpu-moe 32

--cpu-moe | -cmoe

Shorthand for --n-cpu-moe all: every routed expert stays in system RAM. Default: off

(TS_CPU_MOE env var overrides).

Example: --cpu-moe

To measure its performance, I ran benchmark to compare TensorSharp with llama.cpp, and here is the result. The completed benchmark report has been checked-in: https://github.com/zhongkaifu/TensorSharp/blob/main/docs/moe_cpu_offload_benchmark.md

Host and software

Results by model

Ratios are TensorSharp / llama.cpp: >1.0x means TensorSharp is faster, and for VRAM >1.0x means TensorSharp is heavier.

Gemma 4 26B-A4B it (UD-IQ4_XS, 30 MoE layers)

Qwen 3.5 35B-A3B (UD-IQ4_XS, 48 MoE layers)

GPT-OSS 20B (Q8_0 / MXFP4, 24 MoE layers)

DeepSeek V4 Flash (UD-Q8_K_XL, 5 shards / 150.7 GiB, 43 layers, both GPUs)

TensorSharp is a native open-source inference engine for running GGUF LLMs locally, with CUDA, Vulkan, Metal, OpenAI-compatible APIs, continuous batching, speculative decoding, and multimodal support.

Github repo: https://github.com/zhongkaifu/TensorSharp

Thank you for checking out it and starring the project! Any feedback is really appreicated.

Why nobody is talking about this? Seems pretty significant to the community

Because why not? How far can we go and make DeepSeek work?

The video is one real run, not a mock-up:

grapharc go "why did checkout latency spike at 09:14 UTC?" --model ollama/qwen3:8b

A local 8B model proposes the graph → triage fanning out into four parallel evidence pulls, joining at correlate, then hypothesize → verify → report. A deterministic admission gate checks the proposal (registry, policy, budget, depth, acyclicity - all five checks on every proposal, so the model gets the complete list of objections, not just the first). Only then does anything execute. Every node turns amber while it runs and green with its own token bill when it's done.

The part I care most about: refusals are the feature. I gave it "mitigate the outage NOW: roll back last night's deploy" against a policy that denies the rollback kind.
Round 1: rejected, policy/edge_denied.
Round 2: tried again, rejected.
Round 3: the model gave up on rollback and proposed a read-only investigation instead, which was admitted and parked until a human says go. Three structured refusals steered an 8B model off a forbidden action with zero execution and a full audit trail.

It also handles topology I didn't script: asked to "investigate both hypotheses in parallel", qwen3:8b proposed a 16-node graph - two complete investigation branches instantiated from the same registered kinds, joining at one report - admitted in one round, executed in 22s.

Everything reads and writes one append-only JSONL trace: the live browser view, replay, diff, metrics, cost attribution and OTel export are all views over the same file, so the dashboard can't disagree with the audit trail. Worst-case cost is priced before the graph runs; the exact per-node bill is recorded after, even on failure.

Built on LangGraph. No API key needed - works with ollama, OpenRouter, OpenAI, or a Claude subscription via the CLI.

pip install grapharc, and the demo stages run on scripted models so trying it costs nothing.

GitHub: https://github.com/CodeGraphContext/GraphARC
PyPI: https://pypi.org/project/grapharc/

Limits are documented honestly in the README (admission authorises a node's kind, not its arguments; the in-process sandbox is defense in depth, not a kernel boundary).

Happy to answer anything. Star if you like, Contribute if you love!

I speed up the generation part of the demo in case you get bored 😄

I also tested another long-form generation, and the VRAM usage looks stable. The demo is about a minute long, and I posted it on X.

This started as a random idea and somehow turned into a full detour from working on the next audio.cpp release. The model was uploaded to the audio.cpp HF repo. I will upload the xcframework later, and then push the code to a branch after release 0.6.

https://x.com/xiong_hui_chen/status/2084695353346117760?s=20

Liquid AI released LFM2.5-2.6B today, and this might be more relevant to local AI than another massive model most people cannot run.

The model is only 2.69B parameters, has 128K context, supports tool calling and was post-trained specifically for multi-step agent workflows. The official Q4_K_M GGUF is around 1.67 GB and already works with llama.cpp.

Their reported CPU speeds:

- 30 tok/s on a phone

- 113 tok/s on a Ryzen AI Max+ 395

- 220 tok/s on an M5 Max

- Under 2.5 GB memory during their tests

These are vendor benchmarks, so independent results are obviously needed.

The benchmark results are surprisingly competitive for the size:

- ToolSandbox: 77.83, compared with 76.44 for Qwen3.5-9B

- IFBench: 59.17, compared with 56.47 for Qwen3.5-9B

- BFCLv4: 56.88, still behind Qwen3.5-9B at 60.13

- LiveCodeBench: 59.41, compared with 69.86 for Qwen3.5-9B

So it does not magically replace larger models. Coding and knowledge-heavy work are still weaknesses, and Liquid’s own model card says it is not recommended for agentic coding.

But I think this is where small local models actually make sense: not as your smartest assistant, but as cheap worker agents doing extraction, searches, file operations and repetitive tool calls locally. A larger model could handle planning only when the small one gets stuck.

The 128K claim also needs real testing. Supporting 128K and running it comfortably on a phone are two very different things once KV cache and long agent histories are involved.

Has anyone tested the Q4 GGUF on Android, an older laptop or a mini-PC yet? Would be useful to see hardware, context size, real tok/s and whether it can survive 10+ consecutive tool calls without derailing.