While most AI coding tools default to cloud-hosted models, local model runtimes have become a viable alternative for developers who want to keep code on their own machines, avoid per-request API costs, or have to work without an internet connection. Tools such as Cline, Continue, and Aider can already be pointed at runtimes like Ollama or LM Studio. At the same time, GitHub added local-model support to Copilot CLI in April, including an offline mode for fully air-gapped setups.The catch is that “local” generally still leaves much of the assembly to the developer. You have to choose a model and a suitable quantization for your hardware, configure the runtime and context settings, and work out which combination performs well with the agent. And that last part really does matter: models small enough to run comfortably on a laptop can still struggle with the tool use, reasoning, and longer-running tasks that coding agents demand.This is why JetBrains has now built Junie Local, a free version of its coding agent designed to run entirely on the developer’s own machine.Local marketBy way of a brief recap, JetBrains — the developer tools company behind IntelliJ IDEA, PyCharm and WebStorm — launched Junie in January 2025 as an AI coding agent embedded in its IDEs, capable of planning tasks, modifying code, running tests and inspections, and working with the context of a developer’s project. It has since expanded into a standalone CLI.Junie itself isn’t exactly new to local models. In a blog post published on Monday, JetBrains’ head of marketing Dmitry Savelev notes that developers have been able to connect the agent to runtimes such as Ollama and LM Studio for some time, load whichever model they want, and have Junie run against it locally.However, with Junie Local, JetBrains has picked the model, quantized it, and tuned its inference engine and agent harness around that specific combination. Setup is handled from inside Junie itself: running /local downloads the model and inference engine, starts a local server, and switches the agent over automatically. There is no separate Ollama or LM Studio installation, endpoint to configure, or model profile to write.The first step is simply choosing Junie Local from the model selector, where it appears alongside the usual array of cloud-hosted models.Junie’s model selector offers Junie Local alongside its cloud-hosted modelsOnce the download and setup are complete, Junie switches to the local Qwen model, which then appears in the CLI like any other model option.Junie running with Qwen3.6 locallyFrom that point on, inference happens entirely on the developer’s machine.Under the hood: Why Qwen3.6 — and why an M5 MacIt’s worth noting that JetBrains has been very specific about its model choice and hasn’t opted for the latest, shiniest open-weight version. Junie Local uses Qwen3.6-27B, a 27-billion-parameter open-weight model released in April, even though the newer Qwen3.8-27B arrived earlier in August with improvements.“On today’s Macs, [Qwen] 3.6 wins.”Savelev notes that the choice came down to how the two models behaved inside Junie on current Macs, with Qwen3.8 requiring its reasoning mode to be enabled to work reliably with the agent; with reasoning switched on, tasks took roughly four times longer. For Junie Local right now, Qwen 3.6 offers the better balance of reliability and speed.“On today’s Macs, 3.6 wins,” Savelev writes. JetBrains runs Qwen3.6-27B at 4-bit using an inference engine based on mlx-vlm, which in turn uses MLX, Apple’s machine-learning framework for Apple Silicon. It’s a similar underlying approach to the one Ollama adopted in March, when it moved its Apple Silicon engine onto MLX to take advantage of the chips’ unified-memory architecture.There is a fairly substantial hardware floor, though: JetBrains confirms that Junie Local involves about 20 GB of downloads, and requires macOS 26, at least 64 GB of unified memory, and an Apple M5 chip or newer. In real terms, that 64 GB requirement puts MacBook Pro users into M5 Pro or M5 Max territory — in other words, this is firmly a high-end Mac proposition.JetBrains acknowledges that those requirements will put Junie Local beyond the reach of plenty of developers who might otherwise be interested in running it.“We know that an M5 Mac with 64 GB of RAM is a big ask,” Savelev writes. “We are not going to pretend otherwise. That is simply what it costs to run a 27B model well today, and it is the number we are working hardest to bring down.”“We know that an M5 Mac with 64 GB of RAM is a big ask. We are not going to pretend otherwise.”The intention is to reduce memory requirements, support a wider range of hardware, and continue optimizing the underlying stack.“If the lofty requirements are the reason you cannot try Junie Local, rest assured that we are working to bring them down,” Savelev adds.Where local pays offUltimately, the hardware requirement is closely tied to where JetBrains identifies the real performance bottleneck for a local coding agent. The tokens-per-second metric measures how quickly a model generates output, but an agent can spend much of its time first ingesting source files, prompts and other context — the prefill stage — before it starts producing an answer.“Everyone benchmarks generation speed,” Savelev writes. “For a coding agent, that turns out to be the wrong number to chase because most of the time is spent on prefill, while the model reads files to work out what is going on. Optimizing for prefill is where the real gains were.”Being free and unmetered also changes the kinds of jobs developers might be willing to hand over. JetBrains positions Junie Local as particularly well-suited to long, repetitive, and mechanical work — multi-file refactors and renames, filling test-coverage gaps, dependency upgrades, and framework migrations — where the agent can keep working and iterating without the developer having to think about how many tokens it’s burning through.“Long, repetitive, mechanical work is exactly what an agent is for, and exactly what you stop asking for when you are keeping an eye on your balance,” Savelev writes.“Long, repetitive, mechanical work is exactly what an agent is for, and exactly what you stop asking for when you are keeping an eye on your balance.”For everyday development work, Savelev reckons users are unlikely to notice much of a gap compared with stronger cloud models. However, he does concede that more complex architectural reasoning remains better suited to those models.And then, of course, there is arguably the biggest reason developers have been interested in local models in the first place: privacy. Running the entire agent locally means that no external model provider sits between the developer and their code, and that no source, prompts, or generated changes need to leave the machine. For developers working on proprietary code, under client NDAs, or in environments where sending source to a third party is simply off the table, that is a substantial part of the appeal.“Everything after the download happens on your hardware, so your prompts, source, and diffs stay put,” Savelev writes.The post Junie now runs entirely offline. Can you spare a 64 GB M5 Mac? appeared first on The New Stack.