Aider's --weak-model: the second model that pays for itself

Published 2026-05-11 by Owner

Aider runs two models, not one. The main model does the real work: reads files, plans edits, writes code. A second model — the weak model — handles the administrative layer: writing commit messages, summarizing long conversations, and suggesting names when Aider needs a short description of something. The split is intentional. Most of what makes a session expensive isn’t commit messages.

The --weak-model flag lets you specify which model fills the secondary role. If you don’t set it, Aider picks a default based on your main model. But you can override it.

aider --model claude-opus-4-5 --weak-model claude-haiku-4-5

The main model gets the hard problems. The weak model gets the paperwork.

What the weak model actually does

Three tasks go to the weak model by default:

Commit messages. After Aider makes changes, it auto-commits with a message. That message is generated by the weak model looking at the diff and producing a one-line description. No code context needed — just the diff.

Chat summaries. When a conversation gets long, Aider compresses earlier turns into a summary to stay within the context window. The weak model writes that summary. The main model only ever sees the condensed version of old turns.

Name and description suggestions. When Aider needs to describe a file, a function, or a change for display purposes, it uses the weak model. These are informational — never load-bearing.

None of these tasks require deep reasoning. A diff-to-message translation is pattern matching. A summary is compression. These are tasks where a smaller model is nearly as capable as a frontier model for a fraction of the token cost.

One thing worth understanding: the weak model only sees a narrow slice of context for each task. For a commit message, it sees the diff — not the full conversation. For a summary, it sees the turns being compressed — not the entire session history. This narrow context window is by design, and it’s also why the weak model can fail: it’s summarizing without the full picture of what you’ve been building.

The cost arithmetic

Frontier models cost significantly more per token than mid-tier models. Claude Opus 4.5 is roughly 15–20x more expensive per output token than Claude Haiku 4.5 (at typical API list prices). GPT-4o is similarly more expensive than GPT-4o-mini.

The weak model’s share of a session’s total cost is small — usually 10–15%. That’s not nothing, but it’s also not the place to hunt for savings. If cost is a serious concern, the bigger lever is shortening context windows and being selective about which files Aider loads, not the weak model selection.

That said, if you’re already doing everything else right, specifying a cheap weak model is a free optimization. It takes one flag. The main model’s quality is unchanged. The commit messages are slightly more generic, but they were already auto-generated.

A rough estimate for a two-hour session with Claude Opus 4.5 as the main model:

• With default weak model (also Opus 4.5): ~$4.20
• With --weak-model claude-haiku-4-5: ~$3.60

About a 15% reduction. Not dramatic, but consistent across every session.

The math changes if you’re running many Aider sessions per day. Ten sessions a week with a 15% discount is real money over a month. Not a reason to choose the weak model flag as your first optimization — context management matters far more — but it’s worth setting once and forgetting.

What the weak model flag doesn’t change: the quality of code Aider writes, the accuracy of its reasoning, or how well it reads your codebase. Those all run through the main model. The weak model is invisible during the session itself; it only shows up in the commit log and in how Aider summarizes old turns.

The right weak model for the job

The best weak model choices are models that are fast, cheap, and capable of instruction-following on short, well-defined tasks:

• Claude Haiku 4.5 — fast, very cheap, follows formatting instructions well
• GPT-4o-mini — good alternative if your main model is from OpenAI’s stack
• Claude 3.5 Haiku — reliable if you want something slightly more capable on summaries
• Gemini Flash — valid choice, especially paired with Gemini main models

What you’re selecting for: reliable short-form output, instruction-following, and low latency. The weak model is called frequently and in quick succession — a slow model adds noticeable lag to every commit.

What you’re not selecting for: long-context reasoning, multi-step planning, or nuanced code judgment. Those requirements are handled by the main model.

A mismatch between providers can cause problems. If your main model is GPT-4o and your weak model is a Claude model, you’re making two separate API calls with two separate authentication setups. Aider handles this cleanly, but if API keys are misconfigured on either side, the session breaks in a confusing way — Aider fails at commit time, not at the start where you’d notice it immediately. Make sure both models are reachable before starting a long session.

The easiest safe default: keep both models within the same provider family. Frontier main model + that provider’s mini/haiku/flash equivalent as the weak model.

When the weak model produces bad output

This is the part most posts skip. The weak model can make sessions worse, not just cheaper.

Misleading commit messages. If the weak model misreads the diff or doesn’t understand the change, it writes a commit message that doesn’t match the actual change. Over a long session with 20 auto-commits, you end up with a history that’s hard to read in retrospect. A weak model that writes “refactor component” for a commit that actually changes database query logic is worse than no commit message at all.

Lossy conversation summaries. When Aider compresses old turns, the summary goes back into the main model’s context. If the summary drops a constraint you established early (“don’t use class components in this repo”), the main model no longer knows about it. This is an underappreciated failure mode — the session looks normal, but the main model is working from an incomplete picture.

The pattern: both failure modes get worse when the conversation is technically dense. A weak model summarizing a discussion about a tricky async pattern is more likely to lose the important detail than a weak model summarizing “add a blue button to the header.” The more technical the session, the more the weak model’s quality matters for summaries.

A concrete example: in a session where the first 20 turns established that a particular function needed to be idempotent, a weak-model summary might compress that to “discussed function behavior.” When the main model later encounters that function, it no longer has the idempotency requirement in context. It makes a change that violates the invariant. The session looks like a main model failure, but the real cause was a lossy summary written by the weak model three hours earlier.

This is the kind of failure that’s hard to diagnose after the fact. The commit history and session log look normal. Only if you reconstruct the full session do you see where the constraint was dropped.

Checking what weak model Aider is using

Before adjusting the flag, verify what model Aider is currently using for the secondary role. Run Aider with --verbose on startup:

aider --verbose --model claude-opus-4-5

The output includes a line like:

Weak model: claude-opus-4-5

If the weak model matches the main model and you didn’t set --weak-model explicitly, Aider defaulted to the same model. Some model configurations do this when there’s no obvious cheaper alternative in the same family. In those cases, setting the flag explicitly is the only way to get the split.

You can also check your .aider.conf.yml if you’ve configured Aider via config file:

model: claude-opus-4-5
weak-model: claude-haiku-4-5

Any flag available on the CLI maps to the same key in the config file (replacing -- with nothing, keeping hyphens). The config file is the right place for settings you want persistent across all sessions rather than re-specifying on the command line.

Turning it off entirely

The safest option for important sessions is removing the weak model split:

aider --model claude-opus-4-5 --weak-model claude-opus-4-5

This makes both roles use the same model. Cost goes up slightly — you’re paying main-model rates for commit messages — but behavior is maximally consistent. No risk of the weak model mangling a summary and injecting a bad assumption into the main model’s context.

For exploratory work or prototyping, the default split is fine. For sessions where the commit history matters and where early conversation context is technically critical, running the same model for both roles removes a class of subtle bugs.

A middle path: keep the weak model for commits (low stakes, no context injection) but disable it for summaries. Aider doesn’t expose a per-task flag today, so the all-or-nothing approach is the practical choice.

The configuration that’s worth setting

The practical recommendation for most setups:

# In .aider.conf.yml or as CLI flags
model: claude-opus-4-5
weak-model: claude-haiku-4-5

This is the configuration I run for the majority of sessions. The cost savings are real and consistent. The weak model is capable enough for commit messages on typical changes.

When a session gets into complicated territory — refactoring a module with non-obvious invariants, or extended back-and-forth establishing constraints — switching to same-model mode is worth the minor extra cost. The summary fidelity difference becomes material at that level of complexity.

The flag exists because Aider’s authors understood that the administrative layer of a coding session doesn’t require frontier intelligence. That’s a correct insight. Using it well means knowing when “good enough for paperwork” isn’t good enough anymore.