Aider 0.60 lands with two changes worth highlighting: meaningful improvements to architect mode (the planner-plus-editor split that uses a smart model for planning and a faster model for editing), and a new per-task model routing feature that lets you specify different models for different kinds of work.

For light users, neither change is dramatic. For heavy users — engineers running Aider for hours a day on real work — both compound into a noticeably better experience.

Architect mode improvements

Architect mode in Aider uses two models: a “planner” (typically Claude Sonnet or GPT-4o) that decides what to do, and an “editor” (typically Haiku or GPT-4o-mini) that executes the plan. The split is meant to capture planning quality at editor-tier cost.

The 0.60 changes:

• Better handoff prompting between planner and editor. Previous versions sometimes lost detail in the handoff; the editor would get an underspecified plan and produce sloppy execution. The new prompting templates are more specific and the handoff loses less.
• Detection of plan complexity. The planner now flags steps that are too complex for the editor model and routes those back to the planner for direct execution. This avoids the “Haiku tries to implement something subtle and gets it wrong” failure mode.
• Diff-aware editing. The editor model now sees the planned diff structure, not just the prose plan. Cleaner outputs, fewer “the editor didn’t understand the plan” issues.

In practice, architect mode quality is now closer to using the planner model alone, while costing closer to using the editor model alone. The cost-quality tradeoff that was always architect mode’s pitch is meaningfully better realized in 0.60.

For my own usage, switching to 0.60’s architect mode dropped my Aider API bill roughly 30% across two weeks of comparable work, with no visible quality regression. Your mileage will vary based on what kinds of work you do, but the direction is clearly favorable.

Per-task model routing

The other addition: a routing config that lets you specify different models for different kinds of tasks.

# .aider.conf.yml
model: claude-3-5-sonnet-20241022  # default

routes:
  - pattern: "test|spec"
    model: claude-3-5-haiku-20241022
  - pattern: "refactor|rename|move"
    model: claude-3-5-sonnet-20241022  
  - pattern: "design|architect|propose"
    model: claude-3-7-sonnet-20250227

Aider matches the prompt against each pattern; the first match’s model is used. Default falls through if no pattern matches.

This is configuration over convention — what people have been doing manually (switching models with /model mid-session) becomes automatic based on prompt content.

The pattern matching is regex-based, case-insensitive, applied to the prompt text. Simple and predictable.

When this matters

Three scenarios where the new features are worth your attention:

Heavy mixed-use Aider workflows. If you’re using Aider for hours a day across different kinds of tasks, the cost difference between “always use the smart model” and “route by task type” is meaningful. Per-task routing automates the discipline that saves money.

Teams trying to standardize Aider configuration. Per-task routing in .aider.conf.yml (which is checked into the repo) means everyone on the team gets the same model selection automatically. Less to coordinate, less drift.

BYOK users sensitive to API costs. The combination of better architect mode and per-task routing can drop a heavy user’s monthly bill by 40-50%. If your Anthropic invoices are in the $50+ range, this is worth setting up.

For light users — anyone running Aider for an hour or two a week — the differences are small. The default model: ... config that uses Sonnet for everything stays fine. The routing is overhead without much payoff.

What this doesn’t change

A few things to clarify:

Aider’s design philosophy stays the same. Terminal-first, git-native, file-explicit. The improvements are quality-of-life within that frame, not a directional shift.

No new features for non-Anthropic models. The improvements work with OpenAI, Anthropic, OpenRouter, and others, but the architect mode quality gains have been tuned mostly against Claude variants. Other model combinations may benefit less.

Watch mode is unchanged. If you use --watch-files (the AI! comment trigger feature), it works as before. The 0.60 improvements don’t directly affect it.

Conventions still matter. Per-task routing routes by prompt pattern, but conventions files are still what shape the model’s output. If your CONVENTIONS.md is weak, faster cheaper models won’t fix the output quality.

Upgrade path

For existing Aider users:

pip install --upgrade aider-chat
aider --version  # confirm 0.60 or later

To opt into the new features:

• Add --architect to your Aider invocation, or set architect: true in .aider.conf.yml
• Define routes in .aider.conf.yml if you want per-task model routing

Both features are off by default; existing configurations keep working unchanged.

The takeaway

Aider 0.60 is a quality release rather than a feature release. No new commands, no new UI, no new providers — but the existing capabilities work better and cost less when configured to take advantage of the new features.

This pattern — incremental refinement rather than dramatic addition — is becoming common across AI tooling. The major capabilities are mostly in place; the improvement is in efficiency, reliability, and configuration depth. Aider 0.60 is a representative example.

For Aider users, the upgrade is low-risk and worth the small configuration effort. For people who haven’t tried Aider, 0.60 doesn’t change the value proposition meaningfully — Aider is still terminal-first, still git-native, still strong on the multi-file commit-per-step workflow. If those things appealed before, they appeal now. If they didn’t, this release won’t change your mind.