{"slug": "setting-up-a-local-ai-coding-agent-with-ollama-and-aider", "title": "Setting Up a Local AI Coding Agent with Ollama and Aider", "summary": "A developer set up a local AI coding agent using Ollama on Windows and Aider inside Ubuntu on WSL2, running the Qwen2.5-Coder model entirely on the local machine without a dedicated GPU. The architecture keeps Ollama on Windows to avoid duplicate model installations while Aider connects via mirrored networking in WSL2. The setup enables code development with LLMs while keeping all data local and avoiding cloud APIs.", "body_md": "Over the past few months, I've experimented with several workflows for using LLMs in software development. In this article, I describe the local setup I've validated on my own PC: Ollama running on Windows, Aider inside Ubuntu on WSL2, and a code-focused model running entirely on the local machine.\n\nThe machine I used for my first experiment runs Windows 11 with an Intel Core i7-1355U CPU, 48 GiB of RAM, and no dedicated NVIDIA GPU. It's generally a capable machine, but not particularly well suited for AI inference. Because it lacks a dedicated GPU, I had to run the model in CPU-only mode.\n\nThe goal of this setup was to create an environment where both the source code and the data remain entirely on the local machine—far from the cloud-based frontier model approach.\n\nFrom an architectural standpoint, I decided to keep Ollama on Windows because I also use the installed models with other Windows applications, and I wanted to avoid maintaining duplicate model installations. Aider, on the other hand, runs inside WSL, where installation and configuration are simpler and the Linux command-line environment is more convenient.\n\nOllama remains exposed on the local port 11434. Aider, running inside Ubuntu WSL2, connects to Ollama through the `OLLAMA_API_BASE`\n\nenvironment variable.\n\nThis approach avoids duplicating models inside WSL while keeping development repositories in the Linux filesystem under `~/repos`\n\n, where Git and other command-line tools work much more naturally.\n\nSince this machine is not an AI workstation, the solution had to be realistic. That meant avoiding massive GPU-hosted models, cloud APIs, and overly complex automation.\n\nThe final architecture looks like this:\n\n```\nWindows\n ├─ Ollama\n │   └─ qwen2.5-coder:14b\n │\n └─ WSL Ubuntu\n     ├─ Aider\n     ├─ Git\n     └─ Development repositories\n```\n\nKeeping **Ollama on Windows** while running **Aider inside WSL** was a natural choice. I already use Ollama with several Windows applications, so duplicating the models inside WSL made little sense. At the same time, I much prefer working with the Linux command line for software development.\n\nI installed Ollama on Windows and downloaded the primary coding model:\n\n```\nollama pull qwen2.5-coder:14b\n```\n\nI also installed the smaller model for quicker testing:\n\n```\nollama pull qwen2.5-coder:7b\n```\n\nTo verify the installation:\n\n```\nollama list\n```\n\nInitially, Aider running inside WSL couldn't communicate with Ollama running on Windows.\n\nTo make it work, I had to configure WSL to use **mirrored networking**.\n\nFrom PowerShell:\n\n```\nnotepad $env:USERPROFILE\\.wslconfig\n```\n\nThen I added the following configuration:\n\n```\n[wsl2]\nnetworkingMode=mirrored\ndnsTunneling=true\nfirewall=true\nautoProxy=true\n```\n\nFinally, I restarted WSL:\n\n```\nwsl --shutdown\n```\n\nAfter reopening Ubuntu, I tested the connection:\n\n```\ncurl http://127.0.0.1:11434/api/tags\n```\n\nThe response confirmed that WSL could successfully reach the Ollama server running on Windows at `127.0.0.1:11434`\n\n.\n\nInside Ubuntu/WSL:\n\n```\nsudo apt update\nsudo apt install -y git python3 python3-pip python3-venv pipx curl\npython3 -m pipx ensurepath\nexec $SHELL -l\npipx install aider-chat\n```\n\nTo verify the installation:\n\n```\naider --version\n```\n\nI also configured Git so I could version-control my experiments:\n\n```\ngit config --global user.name \"xxxx\"\ngit config --global user.email \"xxxxxxx@xxxxx.xx\"\n```\n\nI created a simple test project:\n\n```\nmkdir -p ~/repos\ncd ~/repos\nmkdir my-project\ncd my-project\ngit init\n```\n\nThen I launched Aider:\n\n```\ncd ~/repos/my-project\nOLLAMA_API_BASE=http://127.0.0.1:11434 aider --model ollama_chat/qwen2.5-coder:14b --no-show-model-warnings\n```\n\nWhen Aider displayed:\n\n```\nAider v0.86.2\nModel: ollama_chat/qwen2.5-coder:14b\nGit repo: .git\n```\n\nI finally knew the basic setup was working correctly.\n\nFor convenience, I also wanted to access the repository directly from Windows Explorer.\n\nFrom inside WSL:\n\n```\nexplorer.exe .\n```\n\nThis command opens the current WSL directory directly in Windows File Explorer.\n\nOnce I had Aider working with a local Ollama instance, there was still one thing I wanted to understand better: what was happening under the hood. How many tokens were being processed? How long did inference take? What kind of throughput could I expect?\n\nWe'll cover all of that in the next installment. 😉", "url": "https://wpnews.pro/news/setting-up-a-local-ai-coding-agent-with-ollama-and-aider", "canonical_source": "https://dev.to/eleonorarocchi/setting-up-a-local-ai-coding-agent-with-ollama-and-aider-1jdi", "published_at": "2026-07-11 13:41:12+00:00", "updated_at": "2026-07-11 14:13:59.897764+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "large-language-models", "ai-agents"], "entities": ["Ollama", "Aider", "WSL2", "Ubuntu", "Windows 11", "Qwen2.5-Coder", "Intel Core i7-1355U"], "alternates": {"html": "https://wpnews.pro/news/setting-up-a-local-ai-coding-agent-with-ollama-and-aider", "markdown": "https://wpnews.pro/news/setting-up-a-local-ai-coding-agent-with-ollama-and-aider.md", "text": "https://wpnews.pro/news/setting-up-a-local-ai-coding-agent-with-ollama-and-aider.txt", "jsonld": "https://wpnews.pro/news/setting-up-a-local-ai-coding-agent-with-ollama-and-aider.jsonld"}}