Aider’s open-source, model-agnostic approach gives you flexibility no commercial tool matches. But that flexibility means there are more knobs to tune. Here are the tips that experienced Aider users rely on.
1. The Model Switching Strategy
Don’t pick one model and stick with it. Different tasks need different models:
# Complex refactoring, architecture changes
aider --model claude-opus-4-20250514
# Daily development, feature implementation
aider --model claude-sonnet-4-20250514
# Quick edits, simple fixes
aider --model gpt-4o
# Exploratory work, prototyping (cheapest)
aider --model deepseek/deepseek-chat
# Offline work, privacy-sensitive code
aider --model ollama/qwen2.5-coder:32b
You can also switch mid-session with /model claude-sonnet-4-20250514. This is one of Aider’s biggest advantages — no vendor lock-in, ever.
2. The /add and /drop Discipline
Context management is everything for both quality and cost:
Be surgical with /add. Only add files directly relevant to your current task. Aider’s repo map gives it awareness of your entire project structure without needing every file in context.
/add src/services/orderService.ts
/add src/types/order.ts
/add src/routes/orders.ts
Use /read-only for reference files that shouldn’t be edited:
/read-only src/services/userService.ts
This lets Aider see the patterns without risking edits to working code.
Drop files aggressively when switching tasks:
/drop src/services/orderService.ts
/add src/services/notificationService.ts
This keeps context focused and costs down.
3. Use /test for Test-Driven Workflows
The /test command is Aider’s superpower for quality:
/test npm test
The tests in src/__tests__/orderService.test.ts are failing.
Fix the implementation to make all tests pass.
Do not modify the test files.
Aider runs the tests, reads the failures, fixes the code, re-runs the tests, and iterates until they pass. This automated test-fix loop is incredibly efficient for TDD.
You can also use it proactively:
Write comprehensive tests for src/services/authService.ts,
then run them with /test npm test and fix any issues.
4. Git History as Documentation
Every Aider edit creates a git commit. Use this strategically:
# See everything Aider did today
git log --since="8am" --oneline
# Review all changes to a specific file
git log --follow -p src/services/orderService.ts
# Undo the last Aider change
/undo
# Undo multiple changes
git reset --hard HEAD~3
Before pushing, squash Aider’s granular commits into logical units:
git rebase -i HEAD~8 # squash the last 8 commits into meaningful groups
5. The .aider.conf.yml Power User Setup
model: claude-sonnet-4-20250514
auto-commits: true
show-diffs: true
dark-mode: true
# Always include project context
read:
- CLAUDE.md
- ARCHITECTURE.md
- docs/API.md
# Lint after every edit
lint-cmd: npm run lint -- --fix
auto-lint: true
# Test after every edit
test-cmd: npm test
auto-test: false # manual — auto-test on every edit gets expensive
# Git settings
attribute-author: true # marks commits as AI-authored
attribute-committer: false
commit-prompt: "Write a conventional commit message (feat/fix/refactor/docs)"
This config means Aider automatically lints after every change and you can manually trigger tests when ready.
6. Use /web for Current Documentation
Libraries change. Training data gets stale. Use /web to ground Aider in current docs:
/web https://supabase.com/docs/reference/javascript/auth-signinwithoauth
Implement Google OAuth sign-in using the approach from this
documentation. Use the PKCE flow, not the implicit flow.
Aider scrapes the page and uses it as context for code generation. This is essential for fast-moving libraries where the API you learned six months ago might have changed.
7. Multi-File Refactoring Patterns
Aider handles multi-file changes cleanly. The key is being specific about the pattern:
/add src/routes/*.ts
Refactor all route handlers to use this pattern:
1. Extract request validation into a separate validateRequest() call
2. Wrap the handler body in a tryCatch that calls handleError()
3. Add request logging at the start: logger.info({ method, path, userId })
4. Standardize response format to { data, meta: { requestId, timestamp } }
Apply to all files. Keep the business logic unchanged.
Aider processes each file systematically. Review the commits one by one — they’ll be atomic per file.
8. Local Models for Free Practice
Set up Ollama for zero-cost coding:
# Install Ollama
curl -fsSL https://ollama.ai/install.sh | sh
# Pull a coding model
ollama pull qwen2.5-coder:14b
# Use with Aider
aider --model ollama/qwen2.5-coder:14b
Local models are great for:
- Learning Aider without API costs
- Working offline (flights, travel)
- Quick edits where quality doesn’t need to be perfect
- Privacy-sensitive code you don’t want leaving your machine
Quality is lower than Claude or GPT-4o, but for many tasks it’s sufficient.
9. The /architect Command for Planning
For complex tasks, use Aider’s architect mode:
/architect
I need to add a real-time notification system.
Users should see notifications in a dropdown, receive push
notifications on mobile, and get email digests daily.
Plan the implementation: data model, API endpoints,
WebSocket integration, background jobs, and which existing
files need modification.
The architect mode uses a stronger model to plan, then a faster model to implement. This saves money while maintaining quality on the thinking stage.
10. Cost Tracking and Optimization
Monitor your spending:
/tokens
Shows current session usage. Keep costs down:
- Claude Sonnet is the sweet spot for daily use (~$3/1M input, $15/1M output tokens)
- GPT-4o is cheaper for simple tasks
- DeepSeek is very cheap with surprisingly good quality
- Local models cost nothing after the initial download
- Use
/clearbetween tasks to reset context instead of carrying unnecessary history
A typical active development day costs $2-8 with Sonnet. That’s less than a monthly Cursor subscription if you code a few days per week.
What’s your Aider model strategy? Share your .aider.conf.yml setup below. 