Last reviewed: September 2026. This category moves faster than any other in the hub; I re-check it twice a year and note changes in the log at the end.
There are two independent questions hiding inside “is this AI coding tool open?”, and most confusion comes from mixing them up. The tool itself can be open source or proprietary. The model the tool calls can be open-weight or a closed API. Claude Code is a closed tool calling a closed model. OpenAI’s Codex CLI is an open source tool (Apache-2.0) that calls a closed model by default. Cline pointed at Qwen3-Coder running in Ollama is an open tool calling an open model, on your own hardware, with nothing leaving the building. All three are legitimate choices; only the last one is what this chapter is about.
This is chapter 6 of the Open Source AI Hub. I have written setup guides for Claude Code, GitHub Copilot and the Codex CLI, and I use all three. This chapter is the open column of that comparison.
What “local-model-backed” really requires
Four things. An endpoint the tool can talk to, which in practice means an OpenAI-compatible API or the Ollama API; every runtime in chapter 5 provides one. A code-capable model that fits your memory at a usable speed; AILane will tell you what that is for your machine, and chapter 4 which families to look at. Reliable tool calling, because the agentic assistants below work by asking the model to run commands, read files and edit them, and a model that fumbles the tool-call format fumbles everything. And a large context window, since an agent that reads your codebase needs room to hold it.
The honest floor, from my own use: for agentic work, where the tool plans and edits across many files, you want a 30B-class model or larger; Qwen3-Coder, Devstral and gpt-oss-20b are the smallest I would rely on, and the 70B to 120B class is noticeably better. For autocomplete and chat about a file, 7B to 14B models are fine and fast. Below that, expect to do the thinking yourself.
The tools
OpenCode
OpenCode (MIT) is a terminal-based coding agent that works with any provider, including local models through Ollama or an OpenAI-compatible endpoint, with a clean interface, sessions, and a client-server design that lets you drive it from an editor. It is the tool I use most on client work, and the one behind the education marketplace case study. One naming note: two projects shared the name in 2025, and the one I mean is the project at github.com/sst/opencode; the other was renamed Crush.
Aider
Aider (Apache-2.0) is the veteran: a terminal pair-programmer that edits files in your repository and commits as it goes, with first-class git integration and a repository map that keeps the model oriented in large codebases. It supports local models through Ollama and any OpenAI-compatible server, and it remains the tool I recommend for people who live in the terminal and want something predictable.
Continue
Continue (Apache-2.0) is an extension for VS Code and JetBrains that gives you autocomplete, chat and edit inside the editor, configured to any model per feature, so you can run a small fast local model for completion and a larger one for chat. It is the closest open equivalent to Copilot’s editor experience, and the easiest of these to hand to a developer who has never used a local model.
Cline
Cline (Apache-2.0) is a VS Code agent that plans, asks for permission, runs commands and edits files, with a plan-then-act workflow that makes its behavior legible. It works well with local models that handle tool calls properly. When a client wants an agent inside the editor rather than the terminal, this is where I start.
Roo Code
Roo Code (Apache-2.0) began as a fork of Cline and added modes, so the same agent can behave as an architect, a coder or a reviewer with different instructions and models. If you like Cline but want more control over how it works, this is the one.
Tabby
Tabby (Apache-2.0) is different in kind: a self-hosted completion server with its own editor plugins, designed to run on a team’s GPU and serve everyone, with usage reporting and an admin interface. It is the right shape for an organization that wants Copilot-style completion without any code leaving the network; some enterprise features are licensed separately, so check the repository.
OpenHands
OpenHands (MIT), formerly OpenDevin, is an autonomous agent that works in a sandboxed environment: give it a task and it browses, codes and tests until it thinks it is done. It is the most ambitious tool here and the one that needs the strongest model; with a frontier-class open model it is genuinely useful for well-specified tasks, and with a small one it wanders.
Goose
Goose (Apache-2.0), from Block, is an extensible agent built around the Model Context Protocol, so the tools and connectors you write for one MCP-aware client work in it too. It runs in the terminal or as a desktop application, supports local models, and is the best of these for building your own workflows around an agent.
Also worth knowing
Google’s Gemini CLI and Alibaba’s Qwen Code are both Apache-2.0 terminal agents; Qwen Code is tuned for Qwen3-Coder and works well with the open version. Void is an open source fork of VS Code with AI features built in. New entries appear monthly; the four requirements above will sort them.
How they compare with Claude Code, Copilot and Codex
Fairly, then. On hard, multi-file tasks with ambiguous requirements, the frontier proprietary models are still better, and the tools built around them by their makers are polished in ways the open tools are still catching up on. If the task is difficult and the code can leave your network, Claude Code with a frontier model is the strongest single option I know, and I say that as someone who sells private AI.
What the open tools give you is different: choice of model, including switching models per task; complete control of where your code goes; no per-seat pricing; and the ability to read, modify and pin the tool itself, so nobody can change its behavior under you. Two developments in 2025 blurred the line: the GitHub Copilot Chat extension for VS Code went MIT, and OpenAI’s Codex CLI shipped as Apache-2.0 with support for open-weight models, so “proprietary vendor” no longer means “closed tool”. The model behind Copilot and the Codex service remain proprietary, and your code still goes to them.
The security side of this decision is a chapter of its own; I wrote it up in Security Risks of AI Coding Tools. The short version: if the code must never reach a third party, the open tool with the local model is the only configuration that keeps that promise by construction rather than by contract.
What I actually do
On the education marketplace project, OpenCode on each developer’s machine drove pinned open-weight models served by Ollama on private infrastructure. About two thirds of the first-draft code was generated locally, and no proprietary code left the client’s network during generation. We chose the stack, Angular, FastAPI and PostgreSQL, partly because open coding models are strongest on well-documented mainstream technology, and we wrote the product requirements before the first prompt, so the agent always had a specification to work from. When a local model falls short on a genuinely hard design problem, the human does the design and the model does the typing. That division of labor is the whole trick.
The review discipline
Open or closed, local or remote, generated code is reviewed exactly like a pull request from a capable junior: read every line, run the tests, and never merge what you do not understand. Three rules I hold to. Every generated change gets a test that the human wrote. Every dependency the model adds gets checked against the license rules in chapter 3. And the person who prompted is the person who reviews, so responsibility never diffuses. I wrote a whole book on this discipline, You Are the Quality Control, and nothing about the tool being open changes a word of it.
Change log
- September 2026: first published.
Next steps
Continue to chapter 7, Why Choose Open Source AI, and When Not To. To see these tools in use on a real project, read the case study, and for more hands-on work, the AI and code experiments page.