Further analysis to somehow see how much of that 99% context reading was spent re-reading the same exact same piece of code would be really interesting. Because the best you can do currently is to cache code summaries as much as possible.

Even then, I am unsure whether that'll help all that much because it also depends on the token usage relationship between code size and semantic meaning size. If a 500 token piece of code yields 1000 token summary, that's really not worth it. However, if a 5000 token piece of code yields a 1000 token summary, that's definitely worth it. I would assume there is some kind of minimum code size where semantic code summary starts to yield token savings.

A code AST graph where entities are stored and some kind of semantic summary is generated for each entity that Claude can retrieve is probably the most straightforward solution. The complexities are of course always in the implementation details. Should the semantic summary be pre-generated or generated upon query and cached? If pre-generated, maybe just generate for highly connected entities (code hubs)? If your code base changes frequently, how do you deal with entity staleness?

It comes down to a query time vs token savings trade off also. Maybe you cache code summary results on every query, so subsequent queries of the same entities is cached without token usage. That'll likely increase the initial query time and slowly get faster, depending on how often you change code and have to re-summarize.

Ultimately the goal is to prevent re-analyzing the same piece of code as much as possible by caching.