Aider's architect mode: when the slower, more expensive workflow is worth it

Published 2026-04-28 by Owner

Aider 0.60 made architect mode much better. The pattern: a strong reasoning model (Claude 3.5 Sonnet, GPT-4o, o1) writes a high-level plan describing what should change, and a cheaper editor model (Claude Haiku, GPT-4o-mini) translates the plan into concrete file edits.

In theory: better quality from the strong model, lower cost from the cheap one. In practice, it depends heavily on the task.

The mental model

A regular aider turn looks like:

You ask for a change
Aider builds context (your files, recent edits, repo map)
The model produces both reasoning and search-replace blocks in one response
Aider applies the blocks

Architect mode splits step 3:

The architect model produces reasoning and a plan in plain prose
The editor model produces search-replace blocks based on the plan + your files
Aider applies the blocks

The architect doesn’t see the file syntax in detail; it sees the high-level structure. The editor sees the file syntax but doesn’t reason about the change deeply — it just translates the plan into edits.

When this wins

Multi-file refactors with non-obvious dependencies. When the change requires understanding how five files interact, the architect’s plan is more reliable than asking a single model to plan and edit simultaneously. The editor’s job is mechanical translation, which is harder to get wrong.

Tasks where the plan is the hard part. “Migrate this controller from Express to Fastify” requires understanding the structural differences. The architect explains them once; the editor applies the resulting changes per-file. A single model trying to do both often produces good edits in the first file and progressively worse ones as it loses track of the overall plan.

When you want to review the plan before code is touched. Aider in architect mode lets you see the plan before the editor runs. If the plan is wrong, you stop, refine, and rerun the architect — without having generated any wrong code.

When this loses

Single-file edits. The overhead of two API calls outweighs the benefit. A regular Claude 3.5 Sonnet call is faster and just as accurate.

Edits where the plan and the code are essentially the same thing. “Add a logging statement at line 45” doesn’t benefit from architectural planning. The architect produces “add a logging statement at line 45” verbatim, and you’ve paid for two calls instead of one.

Tasks where the editor model can’t handle the syntax. GPT-4o-mini and Claude Haiku are weaker at niche languages (Elixir, F#, Nix). If the architect’s plan requires careful syntax in one of these, the editor produces broken code despite a correct plan. The fix is to use a stronger editor, which mostly defeats the cost savings.

The cost math

For a real example, here’s a refactor I ran both ways. Task: extract a 200-line authentication module out of a 1500-line service file, splitting it across three new files.

Single-model with Claude 3.5 Sonnet:

1 turn, 2 retries (the first two attempts had issues with one import)
Total: ~80k input tokens, ~12k output tokens
Cost: ~$0.42

Architect mode with Claude 3.5 Sonnet (architect) + Claude 3.5 Haiku (editor):

1 turn, no retries
Architect: ~30k input, ~3k output → $0.13
Editor: ~50k input, ~12k output → $0.06
Total: ~$0.19

The architect mode was cheaper and didn’t need retries. But this is a case the mode is good at — a multi-file refactor where the plan is the hard part.

For comparison, here’s a single-line bug fix I also ran both ways:

Single-model:

~6k tokens, $0.02

Architect mode:

~6k for architect, ~5k for editor, $0.04

The architect mode cost twice as much for a task where it didn’t add value.

Choosing the editor model

The editor model needs to handle search-replace blocks correctly. The cheapest models can fail this in subtle ways — generating diffs that don’t apply cleanly, misformatting the block delimiters, producing output that aider’s parser rejects.

In my testing:

Claude 3.5 Haiku: reliable for TypeScript, Python, Go, Ruby. Occasionally fails on Rust generics and JSX. Good default.
GPT-4o-mini: similar reliability, slightly more diff format errors. Acceptable.
DeepSeek Coder V3: reliable across more languages but slower than Haiku. Worth it if you’re already paying DeepSeek.
Llama 3.1 70B (via Together): too unreliable on diff format. Skip.

Your editor model choice matters more than your architect model choice for the speed and reliability of the workflow. The architect produces text once; the editor produces text that has to apply correctly.

The slash command

Aider exposes architect mode via:

/architect "refactor the auth middleware to use the new session store"

You can also default to architect mode by setting in .aider.conf.yml:

architect: true
editor-model: claude-3-5-haiku-20241022

When architect mode is the default, you can drop into single-model mode for one-off small edits with /code (the inverse command).

My personal rule

I default to single-model with Claude 3.5 Sonnet for most work. I switch to architect mode when:

The task touches more than three files
I’m not 100% sure of the right approach and want a planning step I can review
The architect’s plan is something I’d write a comment about anyway, so I’m getting documentation for free

I avoid architect mode when:

The task is in a language where I’m not sure the editor handles the syntax (most edge cases I see are language-related)
The change is small enough that I’d review it in 30 seconds anyway
The repo’s repo-map is large enough that the architect’s input cost is high regardless

The mode is a tool, not a default. Knowing when it helps is most of the value.