Any in teraction on huge repo (e.g. Linux kernel) triggers a repo scan

[sfavazza]

Issue

While working with the Linux kernel I have noticed that on each request, aider always starts a repo-scan, which takes around 20 min!

On the first request this might still be acceptable, but on every request makes it unusable. I did not experienced this with smaller repo.

Could it be that the repo is so huge that a scan fills up the context and aider thinks it has to repeat the process as it does not have the whole picture of the project is working on?

Any workaround is appreciated (is disabling the repo-scan a good move? what is the disadvantage?).

Version and model info

Aider: aider 0.86.2
Model: github_copilot/claude-sonnet-5
Git repo: linux-kernel
Repo-map: 1,112 tokens after the long scan completed

[bobleer]

The 1,112-token number is probably a red herring. In 0.86.2, auto includes the files and identifiers mentioned in the prompt in the repo-map cache key (here). A different request can miss that cache and run get_ranked_tags() over the whole file set again. The per-file tag cache avoids reparsing unchanged files (here), but the all-file pass and graph/PageRank rebuild still happen. That is probably the 20 minutes on the kernel.

I would try aider --map-refresh files before disabling the map. It leaves mentions out of the key, so the result is reused while the chat/tracked-file set is unchanged. The downside is that edits inside an existing file do not refresh its map entry as eagerly. manual is even staler; --map-tokens 0 removes the map completely.

We ran into the same shape with repeated repository search in BitFun and keep one workspace index session alive across turns, reopening it only when it becomes unhealthy (source). It is a different index, but splitting the expensive repository snapshot from cheap per-request ranking seems like the longer-term fix here too.

[goransh-buh]

Clear repro steps, that'll make this much easier for a maintainer to pick up.

[SnowingFox]

Opened a PR to address this: #5556

[sfavazza]

Clear repro steps, that'll make this much easier for a maintainer to pick up.

• clone the Linux kernel
• start an aider session in it
• choose any model you want or use the default mentioned in your config file
• type: /ask are you alive?
• expensive scan starts
• repeat the question ==> another expensive scan starts

To make sure this info is added in future issues might be helpful to update the issue template 😉

[sfavazza]

A different request can miss that cache and run get_ranked_tags() over the whole file set again.

Well I wanted to test whether the selected model was working and I asked are you alive? so no content related question. After patiently waiting for the repo scan re-asking the same question caused another scan. Would this be aligned with your guessing?

I would try aider --map-refresh files before disabling the map.

Do you mean the files I want to act on? Is there an incremental cache building that grows as we ask to act on a specific file or the whole repo scan is unavoidable?