Aider Model Setup: Architect Splits, Providers and Team Defaults

Aider's model configuration is a quiet superpower: architect and editor roles, any provider prefix, per-session switching — all behind flags that take seconds to change and repay forever. Most users set one model at install and never revisit it, overpaying on every bulk edit while underpowering hard problems. This guide shows how to configure models deliberately: the architect/editor split, custom provider setup, verification routines and team conventions that keep every ticket on the right model at the right price.

The architect/editor split

Aider's most underused feature is role separation: an architect model that plans and an editor model that executes, configured independently. Pair strong reasoning for architecture decisions and debugging with cheap speed for mechanical edits across files. The savings multiply with file count — bulk operations are Aider's home turf and the cheap model's favorite workload.

Switching takes a flag per session, so the habit costs nothing to maintain: default cheap, escalate deliberately. Reserve flagship reasoning for decisions that deserve it; route everything mechanical to fast models without guilt. Teams that adopt the split typically cut bills by half or more with zero quality regression, because judgment stayed exactly where judgment was needed.

• Architect plans, editor executes
• Strong reasoning where judgment matters
• Cheap speed for mechanical bulk
• Per-session switching without friction

Custom providers in minutes

Point Aider at any provider with its prefix plus the matching environment key; gateway endpoints need the base URL configured alongside. Model strings must match provider catalogs exactly — retired aliases fail confusingly, so verify against dashboards rather than memory. Run one trivial ticket after every configuration change; identical diffs and commits confirm the plumbing before real work depends on it.

Change one thing at a time: new key with the old model first, then new models on the proven key. Compound changes create compound mysteries when anything behaves differently. Document the working combination per provider — prefix, key name, base URL, verified model — so future setups copy instead of rediscover. Configuration done this way takes minutes and never needs redoing.

• Provider prefixes and environment keys
• Base URLs for gateway endpoints
• Exact model strings from catalogs
• Trivial-task verification routine

Migrate billing before models

When moving to a cheaper key, keep your trusted model initially so the only variable is billing. Verify diffs, commit messages and test loops behave identically on a familiar ticket. Only then tier downward, and only on routine tickets — the strong model stays assigned to architecture, subtle bugs and reviews where its judgment earns the premium.

This sequence prevents the classic misattribution where a simultaneous key-plus-model change behaves oddly and neither suspect can be cleared. Downgrade one tier at a time with a week of observation between steps. The patience feels excessive until the first incident it prevents; then it looks like the professionalism it is. Billing migrations should be boring — excitement here is always bad news.

• Same model first for clean comparison
• Diffs and commits as the test oracle
• Tier down on routine tickets only
• Keep strong models for hard problems

Team conventions that stick

Write the model mapping down: default model for ordinary tickets, escalation model for hard problems, bulk model for mechanical work, with one-line reasons each. Store it in repo docs next to the working provider configurations. New teammates copy working configs on day one instead of inheriting whatever the last person tried — consistency compounds savings across every developer and ticket.

Review the mapping quarterly as model generations turn over; the best-value pick rotates faster than habits do. Retire mappings that no longer win and document why, so nobody resurrects them nostalgically. The convention file is small, the savings are permanent, and the onboarding story writes itself. Teams with written routing spend less with less thought than teams improvising per ticket.

• Model-to-task mapping in writing
• Default, escalation and bulk choices
• Quarterly generation reviews
• Onboarding via copy-paste configs

Keep the mapping optimal

Reassess every model assignment quarterly against current prices and capabilities. New generations regularly obsolete last quarter's careful choices; the review takes an hour and typically finds free savings. Check prices on all keys in use, not just the headline model — providers move quiet models without announcements.

Track acceptance rates and cost per merged commit as the standing metrics; they justify downgrades with data instead of hunches. Keep fallback keys warm for outages and deprecations. The maintenance burden is tiny and compounding: each review locks in savings that persist until the next one finds more. Model configuration is a living decision that pays rent forever.

• Quarterly model value review
• Price checks on every key
• Telemetry on acceptance and cost
• Fallback keys kept warm

Frequently asked questions

Can Aider use different models for planning and editing?

Yes. Architect (planning) and editor (executing) roles take separate --model flags, so pair a strong reasoning model with a cheap fast one. The split multiplies savings across every file touched while keeping judgment where it matters.

How do I point Aider at a custom provider?

Provider prefixes plus environment keys: anthropic/, openai/, or gateway prefixes with matching base URLs. Verify with --help and a trivial task; model strings must match the provider catalog exactly.

Should I switch models and keys together?

Start with your trusted model on the new key so only billing changes, verify diffs and commits behave identically, then tier downward on routine tickets while keeping the strong model for hard problems.

How do I confirm a model name is valid?

List models via the provider dashboard or API and paste exact strings. Retired aliases and renamed offerings fail with confusing errors; a two-minute dashboard check beats a two-hour config investigation.

How do teams standardize model choice?

Keep model-to-task mapping in repo docs or settings files: default, escalation, and bulk-edit choices with reasons. Review quarterly as generations turn over; the best-value pick rotates faster than habits do.

Related guides

• Aider Running Costs: Keys, Models and Habits That Cut Bills
• Best AI coding tools 2026: an honest shortlist

Last updated: 2026-09-28