Comparison: Token efficiency of Aider's diff engine vs. raw chat.

Hi user838, I'm Avery. I run developer tooling for a mid-size fintech, and we've used Aider in pilot projects for about six months to assist with internal tool development.

On the token efficiency question, here's a concrete breakdown:

1. **Token Savings on Iterative Edits:** The difference is massive, not minor. For a typical 50-line function where you ask for a 5-line tweak, a raw chat will resend the entire 50+ lines (200+ tokens) with each follow-up. The diff engine sends only the changed lines, often under 20 tokens. Over a 20-message refactoring session, this can save thousands of tokens.

2. **Where Raw Chat Wins for Clarity:** The diff approach can backfire when the required change is highly structural or the AI's previous context is stale. If you're completely rewriting a function's logic or moving code between files, I sometimes manually paste the full new version. The diff can get confusing for the model if the "before" state in its memory is wrong.

3. **Cost Impact at Scale:** For our team, using the diff engine reduced our GPT-4 API costs for coding tasks by roughly 60-70% compared to our initial raw-paste experiments. That's the difference between a $50/month and a $150/month pilot budget.

4. **The Hidden Limitation:** The efficiency depends on Aider's diff being accurate and minimal. I've seen it occasionally send a diff that's too large or misaligned, usually when git is confused by whitespace. You lose efficiency if you then have to paste the whole file to correct it.

My pick is to use Aider's diff engine as your default; it's the main reason to use the tool. I only switch to manually pasting raw code for major, single-turn rewrites or when I sense the AI is misunderstanding the file's current state. To make the best call for your workflow, tell us how long your average coding session is and if you're usually editing single files or coordinating changes across several at once.

Avery's point about massive savings on iterative edits is spot on, but I think they're glossing over the main trade-off. The efficiency win is real, but you asked if it gets harder for the AI to understand context.

It absolutely does. The diff engine works best when changes are linear and additive. If you're asking for a complex refactor that moves logic around, the AI is now working from a mental patchwork of diffs instead of a current, complete file. I've had it confidently introduce bugs because it "remembered" a line from three diffs ago that was actually deleted two steps back.

So yes, you save a fortune in tokens, but you pay for it in cognitive load on the model. For a medium function, that's usually fine. For a sprawling module, you're better off occasionally forcing a full resend for clarity, even if it costs more.

That's exactly the trade-off. I've found the "mental patchwork" problem gets worse in longer sessions, especially when you switch between multiple files. The AI can lose track of what the actual current state is.

A good middle-ground I use: after a few complex, interconnected changes, I'll run `/git commit` to snapshot the diff engine's state. Then I can ask the next question with a cleaner slate, often referencing that last commit message for context. It's a manual "context reset" that's cheaper than a full file resend.

Have you tried any specific tactics to mitigate the context drift, or do you just bite the bullet and resend the whole file?

The git commit trick is clever, I'll give you that. But it's treating a symptom, not the cause. You're essentially paying with your own time and mental overhead to paper over the engine's flaw. If I have to stop my train of thought to stage, commit, and craft a useful message just to keep the AI's context clean, that's a cognitive tax. The token savings start to look a lot less impressive against the minutes you burn orchestrating the tool.

My tactic is more brute force. After two or three rounds of edits on the same chunk, I just resend the whole file. I know, I know, heresy. But the time I save by not debugging a hallucinated line from a diff three steps back is worth the token spend. The real fix would be for the diff engine itself to manage a more robust internal representation, not make me its janitor.

I feel you on the cognitive tax. Your brute-force method makes total sense, especially under a deadline. That time saved debugging is real.

I've landed on a similar hybrid approach. For me, it's not after a set number of edits, but when I see the change touching a lot of the same lines. That's when the diff context seems to fray fastest. I just paste the current block back in with a quick "Here's the updated function."

It's not elegant, but it keeps momentum. The diff engine is fantastic for quick, isolated tweaks, but yeah, sometimes you just have to give it a fresh snapshot to work from.