A local AI coding agent is a program that runs on your own computer, opens a folder you choose, and changes files in it that you approve before anything is committed. The model behind it may still be a cloud API you pay for, a model running on your own hardware, or a mix. What makes the agent local is where it lives, not necessarily where the thinking happens.
An agent is a loop, not a message
A chat window hands you a snippet and trusts you to paste it somewhere sensible. An agent does something different: it reads the file you named, searches for the function it needs to touch, writes the edit, runs your test command, looks at the failure, and goes around again. Every lap of that loop, the model sees what actually happened last time rather than what it assumed would happen.
That loop is most of the product. The model supplies judgment about what to do. The tools, the permission checks, the timeouts, and the written record of every step come from whoever built the agent, and those are where two tools with the same model behind them stop behaving the same way.
Image goes here
/blog/local-ai-coding-agent-loop.png
Diagram of a coding agent loop: plan, tool call, result, repeat
Show generation prompt
Editorial technical diagram, 16:9, flat vector, horizontal flow. Four rounded rectangles in a row connected by thin arrows that loop back from the last to the first: labeled by abstract glyphs for plan (a lightbulb outline), tool call (a terminal caret), result (a document), and repeat (a circular arrow). Charcoal (#121212) background, grey (#8c8c8c) outlines, one arrow and the returning loop in indigo (#5560d4), faint ordered-dither texture along the return path, generous negative space, centered. Mood: cyclical, calm. No readable text, no logos, no watermark.
What runs on your machine, and what does not
The phrase local gets used loosely, so it is worth being specific about the split. In a local agent setup, these parts stay on your disk:
- Your working copy. The agent edits the files in the folder you opened. There is no upload step and no second copy of the repository living in a vendor's bucket.
- Your shell. Commands run through the shell on your own machine, so they see your installed toolchain, your environment variables and your local services.
- Your history. Threads, run journals and settings sit in a local database. Deleting the app deletes the record with it.
- Your keys. API keys are stored in the operating system keychain rather than passed through an application server.
What can still leave is the prompt, plus whatever file contents you let the agent read, sent to whichever model provider you configured. Point the agent at a local model through Ollama or MLX and that traffic stops too. Anything claiming to be a local agent while quietly syncing your conversation to a third party is worth checking before you trust it with a repository.
Local models are finally usable for this kind of work
For a couple of years the honest advice was that local models could autocomplete but could not run an agent loop. That has moved. Ollama and Apple's MLX both expose an OpenAI-compatible endpoint, so a local model plugs into the same provider slot as a cloud one, and the current generation of coding models handles multi-step tool calling well enough to finish real tasks.
The practical pattern most people land on is a hybrid. Send the cheap, high-volume work to a local model: titles, summaries, compaction, planning a refactor. Send the work where a mistake costs you to a cloud model with a strong benchmark record. Because both arrive through the same interface, swapping between them mid-thread does not cost you your conversation history.
When a cloud agent is still the better choice
Local is not automatically the right answer. If your repository is private client code under an NDA, or your company policy forbids code leaving the building, the decision is already made. If you want the strongest model available today and do not care who sees the prompt, a hosted agent is less setup and better raw capability.
The middle ground is where most teams actually sit: the code is sensitive enough that a permanent upload of it is a problem, but the work still needs a frontier model. Bring your own key keeps that arrangement legible. The request goes straight from your machine to the provider, you can see the spend on your own bill, and there is no intermediate service holding a copy.
How to tell a genuinely local agent from a local-looking one
- Ask where the thread history is stored. If the answer is an account, your conversation is not local.
- Check whether the shell runs on your machine or in a container the vendor provisioned for you.
- Look for an offline or air-gapped mode. An agent that cannot be made to stop phoning home does not have one.
- Find out whether you can point it at your own endpoint. If the model list is fixed, you are a tenant, not a user.
- Read what happens to a diff before it lands. Anything committed without your review is a decision made for you.
What Quaka does
Quaka is a desktop coding agent that runs on macOS, Windows and Linux. You open a folder, it reads the repository there, and it works against your own disk with a diff you approve before any commit. It ships with five modes from read-only Ask through Build and Debug, and the tool allowlist for each mode is enforced in Rust rather than written into the prompt, so a read-only mode genuinely cannot see a write tool.
You can bring a key from OpenAI, Anthropic or Gemini, point it at any OpenAI-compatible endpoint, or run a local model through Ollama or MLX. Every step of a run is journaled as it happens, so a killed app picks up where it stopped. If you want the details of what makes up that loop, the harness post goes deeper.
Get an invite
Quaka is in private beta.
One email when your invite is ready. macOS, Windows and Linux, bring your own key.
Read the source on GitHubCommon questions
Does a local AI coding agent work with no internet connection?
Only if you also run a local model. The agent itself is a desktop program and needs no network, but a cloud provider does. Quaka has an air-gapped setting that refuses cloud and CLI providers, drops web search, limits the browser to localhost and stops the updater checking in, which leaves a fully offline setup once a local model is loaded.
Is a local coding agent the same as a self-hosted one?
Not quite. Self-hosted usually means the agent runs on a server your company owns, which colleagues reach over the network. A local agent runs on the developer's own laptop, so there is no server to operate, no multi-tenant boundary to reason about, and nothing running while the laptop is closed.
Which is better for coding, a local model or a cloud model?
Cloud models still lead on hard, long-horizon tasks, which is what benchmarks such as SWE-bench Verified measure. Local models win on cost, privacy and availability. Most people get the best result by routing summaries, planning and short edits to a local model and reserving the cloud model for the work that needs it.