Why Developers Are Moving AI Code Assistants Local

From Cloud Copilots to Local LLMs: What’s Really Changing

Local LLM integration for coding means running language models on your own machine with direct, sandboxed filesystem access so they can read, write, and organize project files without sending your data to remote servers, giving developers offline AI coding, tighter filesystem access control, and a single, persistent context across tools instead of scattering code and notes through disconnected cloud sessions.

Cloud AI code assistants such as Claude Code and popular VS Code extensions have become the default way to get help with refactors, documentation, and even non-code chores like bulk file renames or markdown cleanups. The appeal is obvious: no setup, frontier models, and deep IDE integration. But every file these tools touch is streamed to a vendor’s servers as part of the conversation, and in the case of Claude Code that data can be retained for up to five years or thirty days if you opt out. For many developers, that is no longer an acceptable trade. A folder of open-source code might feel harmless; a directory of tax forms, medical PDFs, or personal notes does not. The direction of travel is clear: the more our code assistants act like general-purpose agents, the more pressure there is to bring them home.

Privacy and Filesystem Access Control: The Local Argument

The most compelling reason developers are moving away from cloud-first assistants is AI code assistant privacy. A remote interpreter must read every file into the session, which means your filesystem becomes part of someone else’s telemetry by design. That model might be excellent at debugging, but it is overkill for sorting receipts or pruning a chaotic Obsidian vault. Some files are probably best kept on your own hardware.

Local LLM alternatives flip that power dynamic. The filesystem MCP server is a small Node.js service published on npm as @modelcontextprotocol/server-filesystem and maintained by the same MCP team that supports cloud tools. It gives any model you run a toolkit for touching files in a folder you specify—reading, writing, editing lines with diff previews, moving, renaming, searching, listing trees, and more—inside a sandboxed path so nothing outside that directory is reachable. In plain terms: you decide exactly which part of your disk the assistant can see. You also eliminate rate limits, data transfer, and recurring trust negotiations every time you drag a sensitive file into a chat. For "look at this folder and tell me what’s in there, then sort it into categories," a local model with filesystem access does the same job at zero cost, data transfer, or rate limits.

Turning Local Models into Real Assistants, Not Chatbots in a Box

Before filesystem tools, most people treated local LLMs as offline chatbots with occasional "chat-with-files" support. You dropped in a document and got a summary back, but the model did not act on your disk. Adding the filesystem MCP changes that role completely: the same weights, same VRAM footprint, but now the assistant can organize folders, clean up markdown, or maintain a note vault as if it were a human operator with clear constraints.

Setting this up is surprisingly direct. In LM Studio, the author’s daily driver, it comes down to a single mcp.json edit and a restart. Jan includes the filesystem MCP in its default server list, so you flip a setting; llama.cpp ships a built-in MCP client in its web UI that you enable with the --webui-mcp-proxy flag. Ollama is the odd one out, requiring a bridge such as MCPHost or ollmcp. Once configured, models like Qwen 3.5 9B and Gemma 4 stand out for tool calling, with Qwen 3.5 9B running multi-step sequences reliably on 8GB of VRAM. That turns local assistants into credible Claude Code alternatives for admin tasks and light project maintenance, even if they still fall short of frontier cloud models for serious agentic development work.

Your Obsidian Vault as Shared Memory for Every AI Tool

The shift to local LLMs is not only about where the model runs; it is about where your long-term context lives. Coding tools are sold as helpers for software projects, but in practice they are LLMs with shell and file access that can do work on your behalf. Treat them as a productivity system wearing a coding label, and you start to ask a different question: why is each assistant learning your preferences separately when they could all read from the same source of truth?

One answer is to turn your Obsidian vault into shared memory. By creating a "meta" folder with markdown files describing machine specs, vault organization, current work, connected MCPs, and response preferences, the author instructs every tool to onboard itself by reading those files first. At the vault root, pointer files such as CLAUDE.md for Claude Code, AGENTS.md for Codex (the file Codex looks for at startup), and lm-studio-prompt.md for LM Studio all direct agents to the same meta folder. Projects live alongside these instructions, so when Claude Code makes a decision about a landing page, Codex can see it later because it reads the same file, and a local Qwen 3.5 instance in LM Studio can summarize decisions across tools thanks to the same filesystem MCP. Individual pricing for this shared memory is modest: Obsidian itself is free, with Obsidian Sync available at USD 4/month (approx. RM18.40). The tools come and go, but the vault persists and carries context across sessions.

The Trade-Off: Capability vs Control

Moving AI coding local is not a free upgrade; it is a deliberate trade. On one side you gain offline AI coding, granular filesystem access control, and the ability to keep sensitive folders—tax paperwork, medical PDFs, personal research—off remote servers entirely. On the other side you accept more setup, hardware constraints, and a ceiling on model capability compared to frontier cloud systems. Tool calling is more demanding than plain chat, and if you are on something like 6GB of VRAM you will end up with smaller models where multi-step reliability drops. The author’s experience suggests that 8GB with Qwen 3.5 9B is roughly the floor for confident chained sequences.

The practical conclusion is not that cloud assistants are obsolete. Claude Code is still the tool to reach for when the work is complicated and model capability matters more than privacy or control. But for the growing slice of developer life that looks like "organize my vault," "clean this folder," or "keep my project notes consistent across tools," local LLM integration backed by a shared filesystem is already better. The smartest move is to let the vault matter more than any single tool in it, and choose between cloud and local moment by moment instead of by habit.