Open-Source CLI Coding Agents Compared: Gemini CLI, Codex, Aider

AI coding assistants started out inside editors, suggesting the next line as you typed. The more interesting development of the last year and a half has happened in the terminal. Command-line agents can read your whole project, plan a change across many files, run your tests, fix what fails and commit the result, all from a shell prompt.

Several of the best-known ones are open source, which matters: you can read what they do with your code, run them against local models, and avoid being tied to one vendor. This guide covers the main open-source options, how to install them, how they differ, and how to use them without creating a mess in your repository.

What a CLI coding agent actually does

A CLI agent is a program that runs a loop: it sends your request and some project context to a language model, the model asks to use a tool (read a file, search the code, run a command, edit a file), the program runs that tool and returns the result, and the loop continues until the task is done or the agent needs your input.

The quality of an agent depends on three things: the model behind it, the tools it gives that model, and the guardrails around those tools, such as which commands it may run without asking. The open-source agents below differ mostly in those last two.

The main open-source options

Gemini CLI (Google)

Gemini CLI is Google’s terminal agent, released under the Apache 2.0 licence. It uses Google’s current Gemini models with a very large context window, which helps on big codebases.

npm install -g @google/gemini-cli
gemini

Its biggest draw is the free tier: signing in with a personal Google account gives, per the project’s README, up to 60 requests a minute and 1,000 a day. It supports project instructions in a GEMINI.md file, Model Context Protocol (MCP) servers for extra tools, Google Search grounding and sandboxed execution.

Codex CLI (OpenAI)

Codex CLI is OpenAI’s open-source terminal agent, also Apache 2.0, with its core written in Rust.

npm install -g @openai/codex
codex

You can sign in with a ChatGPT plan (Plus, Pro, Business and others) or use an API key. Project instructions go in an AGENTS.md file, a convention several other tools now read too. It has approval modes that control whether the agent must ask before editing files or running commands, and it runs commands in a sandbox on supported platforms.

Aider

Aider is one of the oldest and most respected open-source terminal coding tools. It’s model-agnostic: it works with Anthropic, OpenAI, Google, DeepSeek and local models, among others.

python -m pip install aider-install
aider-install
cd your-project
aider --model sonnet --api-key anthropic=your-key

Aider is built around Git. It builds a map of your repository so the model understands the structure, and it commits each change it makes with a descriptive message, which makes undoing a bad edit as simple as a Git revert. Its maintainers also publish a well-regarded code-editing leaderboard comparing how well different models edit code.

Goose (Block)

Goose, originally from Block, is an open-source agent available both as a CLI and a desktop app. It works with many model providers and is built around MCP extensions, so it’s aimed at general engineering automation as well as code editing.

What about Claude Code?

Claude Code, Anthropic’s terminal agent, is often mentioned alongside these tools and is widely used, but it isn’t open source. It launched as a research preview in February 2025 and became generally available in May 2025. If you need an open-source licence, it doesn’t qualify. If you just want a strong terminal agent, it’s worth comparing.

How to choose

Want free usage to start with? Gemini CLI’s free tier is the most generous.
Want to switch between models, or use local ones? Aider and Goose are provider-agnostic.
Already paying for ChatGPT? Codex CLI can use your existing plan.
Want every change in Git automatically? Aider’s auto-commit approach is hard to beat.

The honest answer is that the model matters at least as much as the tool. Try two agents on the same real task in your own codebase before settling on one.

A sensible first session

Whichever tool you pick, a careful first session looks similar:

Start on a clean branch. git switch -c try-agent, so you can throw everything away if needed.
Add a project instructions file. A short AGENTS.md or GEMINI.md telling the agent how to build and test the project, and any rules, such as which folders not to touch.
Ask for understanding before changes. “Explain how authentication works in this project” is a good first prompt. It shows you whether the agent has understood the code.
Give a small, testable task. “Add input validation to the signup endpoint and a test for it” beats “improve the backend”.
Review the diff. Read every change with git diff before you commit or merge.

Running with local models

If your code can’t leave your machine, pair a provider-agnostic agent with a local model server such as Ollama. With Aider, for example:

ollama pull qwen2.5-coder
aider --model ollama_chat/qwen2.5-coder

Be realistic about the trade-off. Local models that fit on a typical laptop are much weaker at multi-step agent work than the best hosted models. They’re fine for small edits and explanations, less so for large refactors.

Safety habits

An agent that can run shell commands can also run the wrong ones. A few habits prevent most problems:

Keep approval prompts on for commands until you trust the agent in that project. Auto-approve only safe, read-only actions.
Don’t put secrets where the agent can read them unless it needs them. Keep production credentials out of the working directory.
Use sandboxing where the tool offers it, or run the agent in a container or dev VM for untrusted code.
Be careful with MCP servers. Each one gives the agent new abilities. Only install ones you trust.
Watch costs. Long agent sessions with large contexts use a lot of tokens. Most tools show usage; check it.

Where these tools are useful, and where they aren’t

CLI agents are very good at tasks with a clear definition of done: adding tests, fixing a failing build, migrating an API call across many files, writing a script, or explaining unfamiliar code. They’re weaker at vague design work and at changes where the right answer depends on context that isn’t in the repository.

Used well, they take the tedious parts of programming off your plate. Used carelessly, they produce large, confident diffs that nobody fully understands. The difference is mostly in how you use them: small tasks, clear instructions, tests, and a proper review before anything is merged.