Aider Context Budget: Cut Repeated Input Without Losing the Files You Need
TL;DR: Start an Aider task with the files you expect to edit, a short read-only conventions file, and a repo map for discovery. Inspect token usage before buying a larger context window or changing models. Smaller prompts save money only when they do not create extra repair turns or hide information needed for a correct patch.
What you’ll be able to do after this guide:
- Distinguish editable files, read-only reference material, the repo map, and chat history.
- Build a focused Aider session and verify what remains in its context.
- Calculate the cost of repeated input using your actual provider rates and accepted changes.
Honest take: Keep enough context to finish the task correctly; remove irrelevant repeated material before paying for a different model or a bigger local machine.
This is a workflow tutorial based on official Aider documentation checked November 1, 2026. The numerical worksheet is an explicitly hypothetical scenario, not a benchmark, provider quote, or report of savings we measured. No paid API calls were used to produce the article.
What does Aider send besides your latest question?
Aider’s context can include files, conversation history, instructions, and a repository map. The repo-map documentation describes a selected overview of symbols and relationships that helps the model locate relevant code. It is not the full text of every file, and it does not guarantee that an omitted implementation detail is available to the model.
Treat the context as a working set for the current change. A bug in a parser may need the parser, its tests, and a short description of the input contract. It probably does not need every historical design note or a generated dependency bundle. Conversely, stripping out the caller that defines an important invariant can make a small prompt dangerously incomplete.
| Context component | Useful role | Common mistake | What to inspect |
|---|---|---|---|
| Editable files | Exact implementation and tests to change | Adding the entire repository | Whether each file is needed for this task |
| Read-only references | Conventions and contracts | Treating read-only as free context | Size and relevance of the reference |
| Repository map | Finding related symbols and files | Assuming it contains every function body | Whether it helps locate the next file |
| Chat history | Decisions and feedback during this task | Carrying unrelated completed work | Whether old messages still affect the decision |
For a concrete starting point, use a small parsing change: make blank input return a documented validation error while preserving valid input behavior. Select the implementation file and its existing test file. Keep the acceptance criteria visible. The target is an accepted, tested patch, not the lowest token count displayed by the tool.
How do you start with a focused set of files?
Pass only the intended edit files and add a concise conventions document as read-only material. Aider’s conventions guide documents --read for this purpose. A read-only file supplies context without being one of the files you are asking the coding workflow to modify; it is not a security sandbox or a billing exemption.
For an existing Python project, an example CONVENTIONS.md might contain:
# Parser change constraints
- Preserve the public parse_config(text) signature.
- Use the project's existing validation exception.
- Add no new runtime dependency for blank-input handling.
- Keep valid-input behavior covered by the existing tests.
These are example project rules, not universal Python conventions. Replace them with the actual contract in your repository. A false constraint is worse than an omitted preference because it can steer every subsequent edit in the wrong direction.
Launch Aider with your already-configured provider and model:
aider --read CONVENTIONS.md --map-tokens 1024 src/parser.py tests/test_parser.py
The paths and map budget are proposed inputs for this example. Check that the paths exist first. Do not copy a provider key into a tracked configuration file just to run the command; retain your established authentication setup.
Inside the session, inspect the file list and token estimate:
/ls
/tokens
The expected result is a listing that identifies the selected files and a token-usage report for the current context. The exact totals depend on the files and model. If an unrelated large file appears, remove that file from the session and inspect the report again. Do not assume that opening Aider from a subdirectory automatically establishes the context boundary you intended.
Is the repo-map budget a hard context limit?
No: --map-tokens is a suggested budget for the map, not a ceiling on the complete request. The options reference describes it that way and documents 0 as disabling the map. It separately describes --max-chat-history-tokens as a soft threshold for history summarization. Neither option is an invoice cap.
The repo-map documentation also explains that the map adapts to the conversation, including expansion when no files have been selected. This is a reason to inspect the actual context after choosing files rather than calculating total request size from one startup flag.
Our recommendation is to leave discovery available while controlling the full files you explicitly supply. Disable the map only as a comparison for a tightly scoped task whose dependencies you already know. If removing it forces you to paste more files or repeatedly explain relationships, the apparent reduction has not helped.
For a large refactor, first ask for a proposed file list and rationale. Read that list before adding the files. If the task crosses a public API boundary, include its callers or tests deliberately. This human review takes effort, but it is also where you catch a model that has misunderstood the change before paying for a large edit.
Which commands reduce files versus conversation history?
Use /drop for a file you no longer need in the session, and /clear for conversation history. These are distinct actions in Aider’s in-chat command reference. /ask lets you discuss the code without requesting edits, while /diff shows changes since the previous message.
An illustrative session might look like this:
/ask Which existing test covers blank parser input?
/tokens
/drop docs/old-parser-notes.md
/tokens
Only issue the /drop command if that example file is actually loaded and irrelevant. The before-and-after token report is evidence that the session changed; it is not proof that the provider billed less. Provider usage records are the evidence for billing.
Before clearing a long conversation, write a short handoff in your own words: the accepted requirement, the current failing check, the relevant files, and the remaining work. Preserve decisions that still matter. Starting a fresh task with a compact, accurate handoff is often easier to reason about than carrying every abandoned approach forward.
There is a practical failure mode here: a developer clears the conversation, then assumes the model remembers a constraint that existed only in chat. The next patch violates it, requiring another repair. Put stable constraints in the conventions file and task-specific acceptance criteria in the new request. Context cleanup should remove noise, not erase the definition of success.
How much can repeated input cost?
Repeated input cost equals the billed token quantity multiplied by the applicable input rate. A simple uncached estimate is useful before adding caching or provider-specific discounts. It must remain separate from output charges, auxiliary calls, subscriptions, and local operating costs.
Consider this hypothetical worksheet: ten requests, each with 2,000 other input tokens, plus either 20,000 or 5,000 tokens of selected file material. Those numbers are chosen to illustrate arithmetic. They are not observed Aider request sizes.
| Assumed quantity | Broad file selection | Focused file selection |
|---|---|---|
| Repeated file material per request | 20,000 tokens | 5,000 tokens |
| Other input per request | 2,000 tokens | 2,000 tokens |
| Requests | 10 | 10 |
| Total uncached input | 220,000 tokens | 70,000 tokens |
| Input cost at your rate R per million | 0.22 × R | 0.07 × R |
The difference is 150,000 tokens, or 0.15 × R. At an illustrative rate of $3 per million, the input-only totals would be $0.66 and $0.21, a $0.45 difference. The $3 rate is a user-selected example, not a current price claim about any model. Replace it with the official rate for your exact provider, model, and context tier.
You can reproduce the calculation locally without a model call:
requests = 10
other_input = 2_000
rate_per_million = 3 # Hypothetical; replace with your verified rate.
def input_cost(file_tokens):
tokens = requests * (file_tokens + other_input)
return tokens, tokens * rate_per_million / 1_000_000
for label, file_tokens in [("broad", 20_000), ("focused", 5_000)]:
tokens, cost = input_cost(file_tokens)
print(f"{label}: {tokens:,} input tokens; ${cost:.2f}")
Expected arithmetic output:
broad: 220,000 input tokens; $0.66
focused: 70,000 input tokens; $0.21
The model may produce different output lengths, repeat context differently, or make extra calls during real work. Use this calculation to understand the direction of the cost, then replace every assumed quantity with usage data. Do not multiply a tiny experiment into an annual savings claim before measuring how often the workflow actually occurs.
Can prompt caching make large context harmless?
Prompt caching can change the bill, but it does not make irrelevant context useful. Aider’s caching documentation describes support that depends on the selected model and provider. Check those conditions and the provider’s cache accounting before estimating a discount.
For an honest comparison, record ordinary input, cache reads, cache writes where applicable, and output as separate categories. If the provider reports a combined number, understand its definition before subtracting a cached count. Double-counting cached input can make the same workflow appear more expensive than it was.
Keep the comparison’s task and completion standard fixed. A broad session with mostly cached context can cost less than your uncached worksheet predicts. A focused session may still win on clarity but save little cash. Either result is useful; neither justifies reporting a fixed savings percentage for every Aider user.
If subscription economics are your actual decision, compare the complete month rather than treating unused subscription allowance as cash returned. Our current versus legacy Cursor pricing guide illustrates why plan labels and billing generations need to be identified before comparing tools.
What changes when Aider uses a local model?
With a model running on your own machine, context still consumes finite memory and processing time even when there is no provider invoice per token. The Aider Ollama integration documentation is the starting point for that backend; our Aider and Ollama setup guide covers the surrounding workflow.
There is no single hardware requirement for the Aider frontend that describes every local model. Your selected model, quantization, context allocation, and runtime determine the inference requirement. Start with a model that already works locally, then test the coding task. Do not buy a GPU because one unnecessarily broad prompt exceeded memory. Use RunAIHome’s VRAM planning calculator after identifying the model and required context.
For hosted inference, your computer runs the client while the provider runs the model, so this context cleanup does not require a local GPU purchase. For local inference, include electricity, existing hardware opportunity cost, and time spent maintaining the server in the decision. A claim of zero subscription cost is not a claim of zero total cost.
What if the smaller session still hits a token limit?
First distinguish input overflow from output exhaustion. Aider’s token-limit documentation says its counts are estimates and that it reports limits returned by the provider. Removing input files cannot guarantee that a requested giant rewrite fits within the output allowance.
Break a large change into independently reviewable edits with clear acceptance checks. For the parser example, fix blank-input behavior before attempting a wholesale validation redesign. Keep the valid-input regression tests. If the tool fails to apply an edit even with sufficient context, inspect the specific failure rather than continuing to shrink the prompt; the SEARCH/REPLACE mismatch guide addresses a different failure class.
Record repairs as part of the original task’s cost. A cheap initial request followed by repeated correction is not a cheap completed feature. Likewise, a technically passing patch that changes the public contract fails the comparison if preserving that contract was an acceptance criterion.
Honest verdict: what should you keep in the next session?
Keep a narrow editable working set, a short truthful conventions file, and enough repository discovery to find missing dependencies. Measure the total cost and review time of an accepted patch. This beats optimizing a token display in isolation, and it gives you evidence for a model or hardware change if the focused workflow still cannot meet your needs.
FAQ
Q: Does —map-tokens 1024 limit every Aider request to 1024 tokens?
A: No. It is a suggested budget for the repository map. Files, instructions, conversation, and output have separate effects on the complete request.
Q: Are read-only files free to include?
A: No. Read-only describes their role in the editing workflow. Included content can still contribute tokens, even if provider caching changes how those tokens are billed.
Q: Should I switch providers before reducing context?
A: For an otherwise working setup, first inspect irrelevant repeated input and the full cost of accepted changes. Change providers when measured cost or capability remains unacceptable after that controlled check.
Sources
- Repository map behavior — Aider
- In-chat commands — Aider
- Read-only coding conventions — Aider
- Options reference: map and history budgets — Aider
- Token limits and estimated counts — Aider
- Prompt caching — Aider
- Ollama backend — Aider
Last updated November 1, 2026. Verify software behavior against your installed release and pricing against your provider. Worksheet values are assumptions, not measured usage or current model prices.
Was this article helpful?
Thanks for the feedback — it helps improve future articles.
Need hands-on help?
I offer 1-on-1 technical consulting for local AI setup, GPU selection, and AI coding tool configuration — same topics covered on this site.
Book a session — $49 / hour →Know which coding tool is worth paying for
Hands-on comparisons of AI coding assistants and what each one costs to run — including the local-model path. Sent only when something changes. Unsubscribe anytime.