Skip to content
Local LLM Course

Coding Agents on Local Models

This is the part most readers came for. Part 10 put a model in your editor and stopped where the model stopped: finishing the line you were writing, answering a question about code you can see. A coding agent is the other thing. It reads files you did not open, runs your tests, reads the failure, edits three more files and runs the tests again. Part 24 built that loop from first principles. This part points the finished tools at your own server.

Two questions run through every page. The first is factual and has a date attached: which of these tools can be told to talk to a machine you own, and how exactly. The answer changes every few months, tools appear and are archived, documentation moves to new domains, and a survey written without dates is worthless within a quarter. Every claim here carries the source and the day it was read, and where a page could not be confirmed the matrix says so rather than guessing.

The second question is the one nobody answers honestly: whether the model on your machine is good enough to drive the tool you just configured. That is not a matter of opinion. It is tool-call reliability, context length and speed, and all three are measurable on your own hardware with the harness from Part 24. This part measures rather than asserts, and it is entirely comfortable with the conclusion that on an 8 GB machine the honest answer is “not yet, and here is what fails first”.

What you will be able to do

Section titled “What you will be able to do”

By the end of this part you should be able to:

  • name the terminal, editor and autonomous coding agents worth knowing in 2026, say which are open source, and say for each whether it documents a path to a local endpoint, with the date you checked;
  • state the three requirements a model must meet to drive an agent loop, work out from your own measured decode and prefill rates whether a candidate model can meet the speed one, and choose a model per memory tier from the course’s reference set;
  • configure Aider, OpenAI Codex CLI, OpenCode, Claude Code, Goose and at least one editor agent against the gateway you built in Part 9, and know which of them will refuse and why;
  • run the same coding task through six tools with one model, record tokens, wall-clock and outcome for each, and read the differences off the table rather than off a forum thread;
  • put an agent in a container that can see one project directory, cannot reach the network except through the gateway, and cannot read your credentials, and prove all three with a test;
  • diagnose a sandbox that leaked, name the fault from a short list, close it and demonstrate the boundary holds afterwards;
  • assemble and document a workstation with models chosen per role, two agents configured, MCP servers wired in and a sandbox, reproducible from one script.

What you need first

Section titled “What you need first”

The gateway from Part 9, because every agent in this part is pointed at its aliases rather than at a port number you have to remember. The agent loop and MCP work from Part 24, because this part assumes you know what a tool call is and what happens when the model emits a malformed one. The measured decode and prefill rates from Part 5’s lab, because the speed arithmetic in the second lesson is built from your numbers, not from ours.

Containers on Tracks S, X and N; containers through Docker Desktop or a dedicated user account on Track M. The memory floor is 8 GB for the sandboxing pages and 16 GB for the lab and the project, because below 16 GB the model that drives the agent is small enough that the lab measures the model’s failures rather than the tools’ differences, which is a real result but not the one those pages are for.

How to work through it

Section titled “How to work through it”

Read the first two lessons before configuring anything. The first is a map with dates on it and tells you which tools are worth your afternoon; the second decides which model you will point them at, and it is the lesson that will save you the most time.

The next five lessons are configuration, one tool family each, and they are written to be read in any order once you know which ones apply to you. Do at least two, not one: the differences between tools only become visible on the second one.

Then the lab, which is the heart of the part: one task, six tools, one model, recorded. Then the sandbox lab, which is not optional. Nothing in this course asks you to give an agent unsupervised access to your home directory, and the challenge that follows exists because the ways a sandbox quietly fails to be a sandbox are specific, common and worth recognising before they happen to you. The project assembles the whole thing into something you keep, and the capstone’s fifth deliverable is that workstation with your own improved model behind it.

Part25 of 27Level5 — Agentic EngineerPages11Estimated time7.8 hours

0 / 11 lessons in this part completed