Making Local AI Smarter and Faster

We want local coding agents to be smart and fast, with the ability to understand a codebase, do useful work, and finish tasks without long waits. This Junie Local update makes it practical to use a more capable model on your own machine.

In the first release, we had to choose between two versions of the same model. With reasoning disabled, Qwen3.6 was fast enough to be usable on a laptop. Qwen3.8 completed more tasks, but it needed reasoning enabled to work reliably, and that made tasks take roughly four times longer. We picked speed.

This update is our attempt to remove the need to choose. We built Qwen3.8-3.6-27B-blend by merging the two in equal proportions. In our coding evaluation, it completed more tasks than Qwen3.6 while generating 71% fewer output tokens than Qwen3.8.

In this post, we’ll show where the new model improves coding results, how we made it run efficiently, and what we learned while testing it. We’re also bringing Junie Local to more machines with experimental NVIDIA support on Windows.

A smarter model that thinks less

In our 100-task internal coding benchmark, the new model completed 37 tasks, compared with 34 for Qwen3.6 with reasoning disabled. It came close to Qwen3.8’s 39 solves while generating 71% fewer output tokens.

Are we actually saving tokens?

One possible explanation for the token savings was just that the blend model spends fewer tokens when it gets stuck. To test that hypothesis, we compared token use for the 30 tasks that were completed by both Qwen3.8 and the blend model. On these tasks, the blend generated about 70% fewer tokens – 279K for the blend versus 935K for Qwen3.8. It used fewer tokens on 29 of those 30 tasks, further proving its token efficiency.

A simple merge worth testing

We started with a simple experiment. Since Qwen3.8-27B is based on Qwen3.6-27B, and they both share the same architecture, we simply merged their weights in equal proportions. This produces a single 27B model without any additional post-training.

However, this simple blend was already a surprisingly useful improvement. The early results were better than we expected, so we focused on evaluating this model across more benchmarks and tasks. That evaluation gave us enough confidence to make it the model for this release while the other experiments continue.

There are many ways to reduce reasoning times, including distillation, reinforcement learning, and more elaborate model merging methods. We are continuing a wider set of model and runtime experiments, and more of that work will appear in future Junie Local releases.

Multiple benchmarks, multiple runs

To see how the new model performs beyond our agentic coding tasks, we evaluated it on multiple public benchmarks. Repeating the evaluation runs lets us see which tasks are consistently completed, how much variance there is between runs, and whether a result depends on one favorable sample.

Across four LiveCodeBench runs, the blend model averaged 85.47% correct answers, compared with 83.29% for Qwen3.8, at a similar output cost. Qwen3.6’s four complete passes averaged 67.87% and used about 24.1 million output tokens per pass, versus approximately 6.14 million for the blend model.

The visual benchmarks expose a different tradeoff. The blend model used substantially fewer tokens than Qwen3.6 with thinking enabled, but more than Qwen3.8. We checked identical questions, images, and generation settings, and we found that the extra tokens were almost entirely due to the blend model spending more time on reasoning.

Further work

The blend can still overthink when it struggles to find a solution. If Junie keeps revisiting the same approach without new evidence or useful tool results, we recommend interrupting it and restarting it with a narrower goal.

There is also room to make successful reasoning more efficient. Across four identical benchmark runs, the length of CoT varied significantly. Picking the shorter correct trace would have cut token use by 24.5%, which suggests that shorter successful paths exist, and we could potentially teach the model to take those paths with zero performance loss.

Making the model run efficiently

The model determines how much text Junie generates, while the runtime determines how quickly that text reaches you and how much memory it needs. Our goal is to improve both.

Speculations about speculative decoding

Junie Local already uses multi-token prediction (MTP). A small subnetwork called the MTP head proposes multiple tokens that the main model checks in parallel. Correct proposals result in more output tokens per pass. We want to make more correct proposals, but this also adds GPU work, so it does not always mean faster generation.

How many tokens should MTP propose?

On the M5 MacBook Pro, proposing two tokens per round made decoding 60% faster than running without MTP. Increasing that to four brought the speedup down to 36%, because the extra GPU work of drafting and checking proposals outweighed the benefit of accepting more tokens.

Does MTP accuracy matter?

We compared how a four-bit MTP head (Q4) and an eight-bit one (Q8) performed on real-world coding trajectories at five context sizes, from 16K to 128K, with three seeds each. Q4 accepted 63.0% of proposals, and Q8 accepted 63.6%:

The acceptance rate tells us how often the guesses are useful, while decode speed tells us whether they save time.

We found no consistent speed advantage for the Q8 MTP head, so we kept Q4 to save memory.

To understand why MTP slows down with longer context, we profiled the GPU load during the token verification process. Calculating attention accounted for most of the increase: Its time rose from 8.4 to 40.2 ms per round, while feed-forward and Gated DeltaNet computations stayed nearly flat.

This MTP limitation results in slower responses as Junie works through a long coding session, even when its predictions remain accurate. We are researching how to reduce this verification cost and keep Junie responsive as sessions go on.

A hidden sticking point

During the early stages of development, our internal evaluations showed performance degradations that we were unable to reproduce when actually using Junie Local. The reason was a setting we had introduced to make evals reproducible: Every request received the same random seed. This caused numeric instability, as reusing the seed gave the same tokens the same random advantage each time the sampler generated a token. When the model’s predictions stayed similar, it could be steered back toward an unsuccessful action even after the prompt changed. Notably, Qwen3.8 was more affected by this instability than the other models we tested.

We corrected the setup by advancing the seed with each agent step and reflection attempt, allowing subsequent attempts to take a different path while keeping the tests reproducible.

Try the upgrade

Apple M5 users can already try the new model via Junie:

junie

Run /local and install Qwen3.8-3.6-27B-blend to switch Junie Local over to it. Make sure Junie is updated to the latest version.

For Windows users the nightly build of Junie now includes experimental RTX support, covering all NVIDIA RTX cards based on Ampere or newer architectures with at least 24 GB of VRAM.

junie --channel=nightly

This early preview lets you try Junie Local on Windows and help shape its development with your feedback.

You can find Qwen3.8-3.6-27B-blend on Hugging Face.

Qwen3.8-3.6-27B-blend is just one result of our broader model and runtime research. We are continuing that work, and you will see more of its results in future Junie Local releases.

Try Junie Local