◇ Could this help me?
Yes for the principle, with the tools vetted and a staleness plan required. The underlying observation is correct and matters more than it sounds: exploration at the start of a session is pure overhead, and an agent that already knows which functions call which can reason about the consequences of a change instead of discovering them afterwards. Putting that map where the project instructions point is the right place for it. General practice, with three honest conditions: the token-reduction multipliers quoted are vendor claims rather than measurements, both tools are third-party code that reads an entire codebase and deserve identification before approval, and a generated map goes stale silently, which is the failure mode to plan for since a confidently wrong map is worse than making the agent look for itself.
I want to stop paying for codebase exploration at the start of every session. First, before installing anything, research the available tools that generate a dependency and function map of a repository: who publishes each one, how widely it is used, what access it needs to my code, and whether any of it leaves my machine. Present that as findings and wait for my approval. Then help me design the rest properly: where the generated map should live so it is read at session start, what should be in the project instructions file to point at it, and most importantly what regenerates the map and how often, since a stale map you trust is worse than no map at all. Tell me how I would detect that it had drifted.