Run a Coding Agent on Local Models: A Practical Setup
Running a coding agent against a local model used to be a demo rather than a workflow: the model would answer questions well enough and then fall apart the moment it had to call a tool twenty times in a row. That has changed, and the gap is now small enough that local is a reasonable default for work you would rather not send anywhere. Here is how to set it up in Atlarix, and where it still disappoints.
What you need
Either Ollama or LM Studio, and enough memory to hold a model with a useful context window. Both expose an OpenAI-compatible endpoint, which is what Atlarix talks to — there is no Atlarix-specific server to install and no conversion step.
Pick a model advertised as tool-capable. This is the single decision that determines whether the setup works, and it is worth more attention than parameter count. A larger model without reliable function calling will perform worse here than a smaller one with it.
Connecting it
Start your local server first — ollama serve, or LM Studio's server tab — and load the model so it is resident before you point anything at it. In Atlarix, open Settings, add the local provider, and give it the base URL your server prints. The model list is read from the endpoint rather than typed in.
From then on the local model appears in the picker beside every other option and can be selected per chat. Nothing else in the app changes behaviour.
What it costs, which is nothing
Your own API keys and local models cost nothing through Atlarix, on every plan, permanently. There is no metering, no markup and no request passing through our infrastructure — a local turn is your machine talking to your machine.
One honest caveat that surprises people: you still have to sign in, even for a fully local setup. That is an account requirement rather than a metering one, and we would rather state it here than have you discover it after installing.
Why retrieval matters more than usual here
Local models have smaller context windows and less tolerance for noise, which makes how a tool finds code the dominant factor in whether the agent stays coherent.
Atlarix retrieves with bundled ripgrep and no index, so what enters the context is the specific lines matched and the files the model chose to open — not a similarity-ranked spray of chunks. On a constrained window that difference compounds quickly: fewer tokens spent on near-misses means more turns before the model loses the thread.
Where local still disappoints
Long autonomous runs are where the gap shows. A local model will usually complete a focused edit as well as a hosted one, and will usually drift on a task requiring forty tool calls and a plan held across all of them.
Two Atlarix surfaces also cannot use it at all: the Chrome extension and Atlarix Reviewer are Core-only with no bring-your-own-key path. If your reason for running local is that code must not leave the machine, that reason applies to those surfaces too, and the honest answer is to not use them.
Atlarix is not unusual in supporting this
It is worth being accurate about the competitive picture, because several tools support local models and a post like this could easily imply otherwise. OpenAI's Codex CLI is Apache-2.0 and documents running against Ollama and LM Studio. opencode supports a long list of providers including local endpoints. GitHub's Copilot CLI documents bring-your-own-key configurations including Ollama.
What differs between them is not whether local works but what surrounds it — retrieval, the approval model, and whether the agent gets a sandbox.
Local models are no longer the compromise option for everyday coding work, and the setup is genuinely ten minutes. Where they still lose is sustained autonomous work, and pretending otherwise would waste your afternoon rather than ours.