How to Migrate From Cursor to Aider

April 23, 2026 · Editorial Team · 6 min read · cursor aider migration

Aider is for developers who think in terms of git commits, not GUI diffs. The typical Cursor-to-Aider migrant has been using Cursor Composer, appreciates what it does, but has started feeling friction with the application layer: managing Cursor windows across projects, the GUI overhead when you're working from a remote server, or simply preferring to stay in the terminal where everything else already lives.

The other common driver is local model support. Cursor is cloud-only with no way to route through a local Ollama instance for cost or privacy reasons. Aider runs on any model that speaks the OpenAI API format, including local models. For developers working on proprietary codebases under strict data policies, that's not a preference, it's a requirement.

What's actually different

Aider is a terminal program. Not "terminal adjacent" like Claude Code, which has a more polished interactive interface. Aider is a Python CLI tool you run from your project directory, and it communicates via a chat-like prompt where you describe changes and it applies them to git-tracked files.

Feature	Cursor	Aider
Interface	GUI (VS Code fork)	Terminal (CLI)
Inline autocomplete	Yes (Cursor Tab)	No
Multi-file edits	Composer	Yes (via `/add` commands)
Git integration	Basic	Native (commits after each change)
Local model support	No	Yes (Ollama, LM Studio, any OpenAI-compatible)
Project rules	`.cursorrules`	`CONVENTIONS.md` or `AIDER.md`
Diff review	Visual diff in Composer	Unified diff in terminal
Streaming edits	Yes	Yes
Pricing	$20/month Pro	Free (pay own API costs)
IDE required	Yes (Cursor is the IDE)	No

The git-native behavior is Aider's most distinctive characteristic. Every change Aider makes gets committed automatically with a descriptive commit message. Your change history is a record of every AI-assisted modification. If Aider's change breaks something, git revert or git reset gets you back. Cursor doesn't commit automatically; you manage git yourself.

Mapping your existing workflow

Cursor Composer. Aider's core loop is the Composer equivalent: you describe what you want, Aider edits files, you review the result. The difference is the interaction is entirely text-based in a terminal prompt, and Aider explicitly manages the git commits for each change.

.cursorrules. Aider reads a CONVENTIONS.md file (or you can specify any file via --read) at the start of a session. Move your .cursorrules content here. Aider also supports a .aider.conf.yml file for default configuration (model choice, auto-commits, etc.) and an AIDER.md or AI_RULES.md convention that it reads if present.

@Codebase context. In Cursor, @Codebase gave you semantic search over your whole repo. In Aider, you explicitly add files to the session with /add path/to/file.py or use /add with a glob pattern. Aider doesn't have a semantic index; you tell it what to look at. For targeted changes this is cleaner. For exploratory questions ("what file handles user authentication?"), you need to know your codebase well or use Aider's /ask command to search before adding files.

Cursor Tab autocomplete. Aider has no autocomplete. You write code in whatever editor you prefer, then hand off to Aider for agentic changes. Many developers use VS Code or Zed for editing and autocomplete, running Aider in a terminal alongside.

Model selection. Cursor uses Claude 3.7 Sonnet or GPT-4o via Cursor's infrastructure. Aider uses your own API keys: set ANTHROPIC_API_KEY for Claude models or OPENAI_API_KEY for OpenAI. To use a local model, set OPENAI_API_BASE=http://localhost:11434/v1 (Ollama's endpoint) and specify the model name.

The actual migration steps

1. Install Aider. Run pip install aider-chat (Python 3.9+ required). Or use pipx for isolated installs: pipx install aider-chat.

2. Set up your API key. For Claude models: export ANTHROPIC_API_KEY=your_key. For local Ollama models: export OPENAI_API_BASE=http://localhost:11434/v1 and run with --model ollama/model-name. Add the export to your shell profile.

3. Create a .aider.conf.yml at your project root. Set your defaults:

model: claude/claude-3-7-sonnet-20250219
auto-commits: true
dirty-commits: false

4. Create a CONVENTIONS.md file. Move your .cursorrules content here. Add more detail if you have it: project structure, naming conventions, testing patterns. Aider reads this at session start.

5. Start an Aider session. From your project directory: aider. Add the files you want to work with: /add src/services/auth.py src/models/user.py. Describe your task in plain language. Review the diff. Type y to accept or /undo to revert.

6. Learn the /ask workflow. Before adding files, use /ask question about the codebase to get Aider's assessment without modifying anything. This is useful for orientation before a task.

7. Configure your git workflow. Aider auto-commits by default. If you prefer to review commits before they happen, set auto-commits: false in .aider.conf.yml. This means Aider writes changes but you do git add and git commit manually, which feels more like Cursor Composer's diff-then-apply pattern.

First-day checklist:

Aider installed and API key configured
.aider.conf.yml in place
CONVENTIONS.md populated from .cursorrules
One session completed with explicit /add and task description
Git auto-commit preference set

Gotchas you'll hit

You must know which files to add. Cursor's @Codebase let you ask questions without knowing the file structure. Aider requires you to add specific files. On unfamiliar codebases, spend time with /ask before diving into tasks, and consider keeping a separate grep-capable terminal open.

No autocomplete. Like Claude Code, Aider is for changes, not continuous typing assistance. Keep a separate editor for your day-to-day editing.

Auto-commit noise in git log. Aider commits every change with an AI-generated message. In a long session, your git log fills with fine-grained AI commits. Some developers use --auto-commits false and then git rebase -i to squash before pushing.

Terminal diff reading. Aider shows changes as unified diffs in the terminal. If you're accustomed to Cursor's visual side-by-side diff, this takes adjustment. Your git client (GitKraken, Fork, VS Code's source control) can show the diff graphically after the fact.

API costs are variable. Aider uses your API key directly. A complex multi-file task with Claude 3.7 Sonnet can cost $2-8. Monitor usage in the Anthropic console.

Aider doesn't run tests. Cursor Composer can see file changes and (sometimes) read terminal output. Aider makes the changes and stops; you run your tests separately. Some developers write a shell script that runs aider followed by npm test to automate the feedback loop.

When NOT to switch

Stay with Cursor if:

Inline autocomplete is a meaningful part of your daily workflow. Aider has nothing equivalent.
You prefer a visual diff before applying changes. Cursor Composer's diff view is more ergonomic than a terminal unified diff.
Your work is exploratory and you rely on @Codebase's semantic search to find relevant code. Aider's file-explicit model requires knowing your codebase.
You work with designers or non-technical teammates who share a Cursor setup. Aider is not accessible to non-terminal users.
You don't want to manage API keys and prefer flat monthly billing.

Aider is the right move when you want git-native AI commits, local model support, or a lightweight terminal tool with no Electron overhead. The setup is quick, the resource footprint is tiny, and the git integration is genuinely useful for teams that care about change history.

Aider and Cursor fill different positions in a developer's toolkit, and the choice mostly comes down to how you want to interact with AI: through a GUI with visual diffs and autocomplete, or through a terminal with git-native commits and local model flexibility. The migration is straightforward mechanically. The adjustment is mental: learning to specify files explicitly rather than relying on semantic search, and reading diffs in the terminal rather than in a split pane.