OpenCursor: a local-first AI coding agent inside VS Code
Open-source Cursor-like AI coding agent for VS Code — agentic chat, multi-provider LLMs (OpenAI, Ollama, llama.cpp), semantic search, and MCP support
At a glance
- What is it?
- OpenCursor is an MIT-licensed VS Code extension that runs an agentic chat loop against cloud subscriptions, API keys, or a fully offline llama.cpp and Ollama stack. The interesting part is not the chat panel; it is the local embedding index and the per-hunk review model, and those are also where the sharp edges sit.
- Who is it for?
- Adopt OpenCursor if you want an agent loop inside VS Code that can run against a local llama.cpp or Ollama model with an on-device embedding index, and if you are comfortable with a 0.1.x extension whose native dependencies are fetched after install. Do not adopt it if you need a stable, heavily documented toolchain or if your team cannot allow a first-activation download from outside the VSIX.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap OpenCursor is aimed at
Cursor is a separate editor. Adopting it means moving your workspace, your keybindings, and your extension set into a fork of VS Code, and paying a subscription for the privilege. OpenCursor takes the opposite position: stay in the VS Code you already have, install one extension, and get an agent that reads the workspace, edits files, runs shell commands, and searches the codebase by meaning rather than by keyword. The README frames the project as "the open-source AI coding agent for VS Code, built local-first", and the local-first half is the part that distinguishes it from the many thin chat wrappers on the Marketplace. The audience is developers who want agentic editing but do not want to change editors, and specifically those who either cannot send source code to a hosted API or would rather not. The provider list is deliberately broad: OAuth sign-in against an existing Claude Code, OpenAI Codex, or Google Antigravity account, plain API keys for OpenAI, Anthropic, Gemini and OpenRouter, and any OpenAI-compatible or Anthropic-style endpoint you point it at. That breadth is the adoption argument. You are not asked to buy a new model subscription to try it.
How the agent loop, the index, and the tools fit together
Three mechanisms are visible in the repository material. The first is the chat loop itself: a multi-tab sidebar where you address context with @-mentions covering files, folders, selections, @Docs, git commits, branch diffs, terminals, rules and past chats. The second is the tool layer. The README states the extension ships 25 tools, listing read, write and edit, shell, grep and glob, semantic search, web search and fetch, notebooks, todos, subagents and MCP. Those tools are what turn a chat panel into an agent: the model can call them, observe results, and continue. The third mechanism is the retrieval path. Semantic search is not delegated to a cloud embeddings API by default. The README describes an on-device ONNX MiniLM model that builds an index automatically, updates it incrementally, and stores it locally, with the option to point at any OpenAI-compatible /embeddings endpoint instead. That combination is what makes the airplane-mode claim coherent: a local model plus a local index means no request has to leave the machine. Routing is handled by an auto mode in which a judge model picks the best enabled model per task, with per-model settings for reasoning effort, thinking mode and context size. On the editing side, every agent edit gets per-hunk Keep and Undo CodeLenses, so review happens in the editor buffer without requiring a git commit first. The extension also ships a full MCP client and 11 lifecycle hooks that the README describes as Cursor and Claude Code compatible.
What you type to get it running
Installation has two paths. The normal one is installing OpenCursor from the VS Code Marketplace, or grabbing the .vsix from the Releases page, then opening the sidebar and choosing a provider: a one-click llama.cpp install, a running Ollama instance, an account sign-in, or an API key. The source path is explicit in the README: clone the repository, run pnpm install, then pnpm run compile, or pnpm run watch for a rebuild loop. Pressing F5 launches the Extension Development Host, and pnpm run vsix produces a package. Two operational details matter more than the commands. First, the README warns that native runtime dependencies, specifically ONNX runtime and image processing, are downloaded once on first activation with integrity checks because they are too heavy to ship in the VSIX. That means a fresh install is not self-contained, and an air-gapped machine needs those artifacts staged before activation. Second, the approval policy is configurable per action with allow, ask, review and deny, backed by risk heuristics that the README says flag patterns such as rm -rf, sudo, .env and secrets, plus wildcard allow and deny lists. That policy is the main control you have over an agent that can write files and run shell commands, so it is worth reading before the first session rather than after.
Modes, approval policy, and the limits of each
OpenCursor ships five modes: Agent, Ask, Plan, Debug and Multitask, with Ask and Plan described as read-only. The distinction is the useful part. If you want the model to reason about a change without touching the tree, Ask or Plan gives you that guarantee at the mode level rather than relying on the model to behave. Agent mode is where the write and shell tools become live, and that is where the approval policy does the actual work. The README's heuristics are pattern-based, which is a real limitation: a destructive command that does not match a known pattern, or one assembled inside a script, will not trip the heuristic. Wildcard allow and deny lists are the escape hatch, but they are also a footgun if you write a broad allow rule to reduce prompt fatigue. The honest reading is that the safety model here is layered prompts plus static patterns, not a sandbox. Nothing in the material suggests the shell tool runs in a container or a restricted filesystem view, so treat agent mode as equivalent to giving the model a terminal in your working directory and configure the policy accordingly.
The local stack is the differentiator and the biggest source of friction
The README's local story is unusually complete for this category. OpenCursor can search Hugging Face for GGUF models, let you pick a quantization, download it, and then spawn and manage llama-server itself, with launch control over context size, GPU layers, flash attention, KV cache types, speculative decoding and vision via --mmproj. Ollama is supported as a zero-config alternative. Local embeddings come from the ONNX MiniLM model. The friction is proportional to that ambition. GGUF quantization choice, GPU layer count and KV cache type are not settings most developers have intuitions about, and getting them wrong produces either an out-of-memory failure or a model that is too slow to be useful. Managing llama-server as a child process also means the extension inherits responsibility for port conflicts and process cleanup on shutdown. This is not a criticism of the design; it is the price of the offline guarantee, and it is the reason the local path is best suited to someone who has already run llama.cpp by hand and knows what those flags do. If you have not, start with Ollama or a hosted provider and treat the built-in llama.cpp management as a later step.
Where it sits next to Continue and Cline
The closest comparison is Continue, which is also an MIT-licensed VS Code extension with multi-provider support, @-mention context and an agent mode. The difference in approach is where the intelligence lives. Continue's design centers on configurable model and context providers declared in config files, and it has historically leaned on hosted or self-hosted embedding and reranking endpoints for codebase retrieval. OpenCursor pushes the retrieval layer on-device by default with the ONNX MiniLM index and treats the fully offline path, including model serving, as a first-class feature rather than an integration you assemble. Cline is the other reference point: it is an agent-first extension with a strong emphasis on explicit approval of each action and on plan-then-execute workflows, and it does not ship a local model manager. OpenCursor sits between them, with the broadest surface area of the three and the least time in the field. If your priority is a mature configuration system, Continue is the safer bet. If your priority is never sending code or prompts off the machine, OpenCursor's combination of a bundled local index and managed llama-server is the more direct fit.
Release cadence, licence, and what to check before adopting
The version history is short and recent: 0.1.1 in late July, 0.1.2 in early August, 0.1.3 in early September, all within roughly six weeks. A 0.1.x line with three releases in that window tells you the API surface and the settings keys are still moving, so pinning a specific .vsix rather than tracking the Marketplace latest is a reasonable precaution on a team. The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved; that is a permissive baseline, and if you fork the extension you inherit the obligation to keep the notice. The README does not discuss telemetry, crash reporting or what, if anything, is sent when you use a hosted provider, and it does not describe a support or deprecation policy, so those are open questions rather than documented guarantees. Two concrete things to verify on your own machine before a team rollout: that the first-activation download of the ONNX runtime and image processing dependencies completes behind your proxy or firewall, and that the approval policy behaves as you expect by running an agent-mode task against a scratch repository and watching which actions prompt. The README's own example of the local stack is the claim to test first: a local model plus a local index, with the network disconnected.
Editorial conclusion
Adopt OpenCursor if you want an agent loop inside VS Code that can run against a local llama.cpp or Ollama model with an on-device embedding index, and if you are comfortable with a 0.1.x extension whose native dependencies are fetched after install. Do not adopt it if you need a stable, heavily documented toolchain or if your team cannot allow a first-activation download from outside the VSIX. Before rolling it out, verify two things yourself: that the agent's write and shell tools respect your allow/ask/review/deny policy on a throwaway repository, and that the ONNX embedding model downloads and indexes cleanly on your platform, since the README warns the runtime dependencies are fetched with integrity checks rather than shipped.
Community notes