In this article
Aider combines a selected local model, an explicit editable file set, and Git history; connecting Ollama alone establishes only generation.
Start Aider with a local model in a small repository whose initial Git state you understand. The first useful result is a reviewed edit to an explicitly selected file, not merely a successful connection to Ollama.
The concrete application boundary
Aider makes the editable file set an explicit part of the conversation. Add source files that actually require modification rather than handing the entire repository to the first task. The repository map can supply reference context, but seeing a symbol in that map does not make its file editable. Git integration also means the starting repository state matters: user changes may already exist before Aider begins. The documented modes separate asking, direct edits, and architect/editor work. A simple question should use the asking path before a correction is authorized. This order lets you inspect whether the assistant understood the function before evaluating its ability to rewrite it. Keep the initial test result beside the new result, so an existing failure is not mistakenly attributed to the assistant’s change (Aider chat modes).
A practical route
Verify the actual local model name and select its documented Ollama integration in Aider. Start inside the intended repository, inspect the current diff, and add only the relevant file with /add. Use /ask to discuss the behavior before requesting an edit in the appropriate mode. Review the resulting diff and commit information before continuing (Aider Ollama integration).
A worked example
Create a small text formatter with an existing test file. Ask why its empty-input branch differs from normal input, then request a narrow correction and a corresponding test adjustment. Keep unrelated repository files out of the editable set. A local model may propose a plausible but wrong patch, so inspect the changed branch and run the relevant check.
| Check | Record |
|---|---|
| Starting state | The repository diff before Aider begins and the file intentionally made editable. |
| Interaction | The explanation question followed by the narrowly described correction. |
| Result | The actual file diff, relevant check output, and Git commit created if applicable. |
Reading the failure correctly
Reference information about a file is not the same as making it editable. A missing context file can produce an incorrect proposal even with a working model connection. Existing uncommitted changes also complicate undo: inspect Aider’s Git behavior and commit boundaries rather than assuming every change belongs to the latest assistant request (Aider Git integration).
What completes the check
Finish the first task with an explainable diff and an understood repository state. Keep the model configuration separate from the editable file set so that a later scope problem does not trigger an unnecessary runtime change.
Related background: Reproducible inference stacks: preserving a GPU pilot’s result, Coding LLMs on 12GB VRAM: Budget Context and Headroom.