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.
From the terminal: the Atlarix CLI
The Atlarix CLI runs the same agent without the app, which is the natural fit for scripts and unattended runs. Point it at the endpoint your local server prints and name the model:
`
atlarix --prompt "fix the failing test in auth.test.ts" \
--provider-url http://localhost:11434/v1 \
--model qwen3-coder
`
That is Ollama's default address; LM Studio's is http://localhost:1234/v1. No API key is needed for a server on your own machine. On CLI 15.0.1 and earlier, add --api-key local (any value works; the local server ignores it).
The same advice applies as in the app: the model must be tool-capable. We checked this setup with a deliberately tiny model, and it connected and answered but never called a tool, which is exactly the failure the first section warns about.
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.
Questions
- Can I run a coding agent fully on a local model?
- Yes. Run Ollama or LM Studio, load a tool-capable model, and point Atlarix at the OpenAI-compatible endpoint it prints. Model requests then go to your own machine, and there is no metering or markup.
- Which local model should I use for a coding agent?
- One that reliably calls tools. Tool calling matters more than parameter count: a larger model without dependable function calling does worse as an agent than a smaller one with it.
- How do I use a local model from the Atlarix CLI?
- Pass the endpoint and the model: atlarix --prompt "your task" --provider-url http://localhost:11434/v1 --model <model name>. Use http://localhost:1234/v1 for LM Studio. A local server needs no API key.
- Does a local model cost anything in Atlarix?
- No. Local models and your own API keys cost nothing through Atlarix on every plan. The Chrome extension and Atlarix Reviewer are the exceptions: they run only on Atlarix models.