Every AI coding tool you use today — Claude Code, Cursor, GitHub Copilot, Opencode — is an explore agent.
Before it can help you, it has to figure out where it is.
It opens files. It greps for symbols. It reads the same module twice because it forgot it read it the first time. It infers relationships between packages that a static analyser would simply know. It rebuilds a working model of your codebase from scratch, in every session, every time.
This behaviour has a name now: explore agent behaviour. And it has a cost that almost nobody is measuring.
What an explore agent actually does
Ask Claude Code to explain the authentication flow in a mid-sized codebase. Watch what happens in the tool call trace.
It doesn't look up authentication. It goes looking for it.
First it lists the directory structure. Then it opens a likely-sounding file. Then another. It finds an import and follows it. It reads a handler, then the middleware it references, then the package that middleware lives in. It discovers a dependency on an external library and reads enough of it to understand the interface. Somewhere in the middle of this it opens a file it already opened four calls ago, because the thread of inference led it back there.
By the time it can answer your question, it has made 50, 60, 70 tool calls. It has read tens of thousands of tokens of source code. It has spent valuable time. And when you start a new session tomorrow and ask a related question, it will do all of this again. From scratch. Because nothing persisted.
This is explore agent behaviour: the pattern of discovering codebase structure through inference and file traversal rather than querying a pre-built structural map.
This is how current AI coding tools work by design. The agent has no prior knowledge of your codebase beyond what fits in its context window. So it explores.
Why every AI coding tool is an explore agent today
The architecture of current AI coding tools is roughly this: a language model, a set of tools (read file, list directory, run search), and a context window.
The agent uses the tools to gather information, accumulates it in context, and reasons over what it has collected. (This is all vast simplification, but for the sake of this post.)
This works. It works well enough that millions of developers use these tools every day and find them useful. But it has a structural property that is rarely discussed: the agent's understanding of your codebase is ephemeral and re-derived on every task.
There is no architectural memory between sessions. There is no persistent graph of what connects to what. There is no pre-computed answer to "what depends on this module?"
The agent has to figure it out from first principles, every time, using the same tools a human would use if they were new to the codebase and had no documentation.
The result is that a meaningful portion of every AI coding session is not coding. It is discovery.
The hidden cost
We measured this directly.
We gave Claude Haiku a set of architectural questions about three repositories — questions about different flows, dependency relationships, and the impact of proposed changes.
We ran the same questions twice: once with the agent exploring freely, once with enola providing a pre-built architectural snapshot via MCP.
The results were not insignificant.
Seventy tool calls to answer questions that fifteen could answer. Two hundred and nineteen thousand tokens to arrive at understanding that five thousand tokens could have served directly. Sixty-eight seconds of waiting for what took five.
Those extra 55 tool calls are the explore cost. They are not answering your question. They are finding out where to look for the answer.
What the explore costs at current model pricing
Abstract token counts are hard to reason about.
Here is what 219,000 input tokens costs across the models you are likely using, assuming the explore baseline from our benchmark:
A single session on Claude Haiku costs $0.22 in pure exploration. That sounds small. It is not small at scale.
A team of 20 developers, each running 8 sessions per day, 22 working days per month:
20 × 8 × 22 = 3,520 sessions per month.
At Claude Haiku pricing, that is $775 per month in explore cost alone — before the model writes a single line of code. At Sonnet pricing, $2,323 per month. At Opus pricing, $3,872 per month, just for the exploration phase.
These numbers assume one explore session per task. Developers context-switch. They start sessions, abandon them, start again.
Why agents explore instead of knowing
The honest answer is that there is no good alternative yet — or there wasn't.
Handwritten context files (AGENTS.md, CLAUDE.md, copilot-instructions.md) help at the margins.
A well-written AGENTS.md tells the agent where to look first, which conventions to follow, which modules to avoid. Teams that maintain these files spend less time on exploration and more time on execution.
But handwritten context files have three structural problems.
They drift. The codebase changes. The file does not. Within weeks of a significant refactor, the AGENTS.md describes a codebase that no longer exists. The agent reads it, forms wrong assumptions, and explores to correct them.
They are incomplete. A human writing a context file describes what they think is important. They miss the dependency edge that matters for this specific task. They do not enumerate every symbol in the module. They do not know which cross-repo edges the agent will need to follow.
They do not scale to multiple repositories. A backend service has an AGENTS.md. The web client that calls it has a separate AGENTS.md. The auth provider they both depend on has nothing. When the agent needs to follow a call across three service boundaries, the handwritten context ends at the first one.
The alternative: repository map
The core insight behind enola is simple: the structure of a codebase is deterministic. It can be computed once and served on demand, rather than re-inferred on every session.
Your modules do not change between when you write them and when the agent needs to understand them. The dependency graph is not probabilistic. The call relationships between functions are facts, not inferences. These things can be extracted, stored in a graph, and served to an agent as structured answers.
That is what enola does.
It is a local MCP server that builds a precise architectural graph of your codebase — modules, symbols, routes, dependencies, cross-repo edges — and exposes tools your agent can call to query it directly.
Instead of opening 70 files to understand the dependency tree, the agent calls enola and gets the exact answer.
The result of having a map before exploring is not just faster sessions. It is a qualitatively different kind of reasoning.
An agent that starts from architectural ground truth makes fewer wrong decisions, not just fewer tool calls. It does not hallucinate dependencies that do not exist. It does not miss the cross-repo edge that would have told it the change it is about to make will break three other services.
Determinism added where AI lacks it.
What comes next
This is the first post in a series on explore agent behaviour. Over the coming weeks we will publish:
- Benchmark: Claude Haiku explores Apache Airflow — with and without a codebase map. The full methodology, results table, and what the numbers mean for teams running Python services.
- The explore cost across models. The same benchmark run on Claude Opus, Gemini 2.5 Pro, Qwen, Kimi, and DeepSeek. Does a larger context window reduce exploration? Does a smarter model explore less? The answers are not what you would expect.
- We mapped Apache Airflow with enola. What the architectural graph of one of the most widely deployed Python projects in the world actually looks like — and what it tells you about how AI agents navigate it.
- Why AI agents relearn your codebase every session. A deeper look at the mechanism: session isolation, context window limits, and why the current architecture of AI coding tools makes explore behaviour structurally inevitable without a persistent map.
FAQ
What is an explore agent?
An explore agent is any AI coding tool that discovers codebase structure through inference and file traversal rather than querying a pre-built structural map. Every current AI coding tool — Claude Code, Cursor, GitHub Copilot, Opencode — is an explore agent. Before it can answer your question, it opens files, greps for symbols, and rebuilds a working model of your codebase from scratch, in every session.
How much does explore agent behaviour cost?
In benchmarks, explore agent behaviour consumed 219,000 tokens and 70 tool calls to answer questions that required only 5,000 tokens and 15 tool calls with a pre-built codebase map. For a team of 20 developers running 8 sessions per day, that translates to $775/month at Claude Haiku pricing, $2,323/month at Sonnet pricing, or $3,872/month at Opus pricing — just for the exploration phase, before the model writes any code.
Why do AI coding tools re-explore the codebase every session?
Current AI coding tools have no architectural memory between sessions. There is no persistent graph of what connects to what and no pre-computed answer to questions like "what depends on this module?" The agent has to figure it out from first principles every time, using the same tools a human would use if they were new to the codebase and had no documentation. This makes explore behaviour structurally inevitable without a persistent map.
What is the alternative to explore agent behaviour?
The alternative is a pre-built structural map of the codebase. Tools like enola parse your repositories and build a deterministic graph of modules, symbols, routes, dependencies, and cross-repo edges. Instead of the agent opening 70 files to understand a dependency tree, it queries the graph and gets the exact answer. The structure of a codebase is deterministic — it can be computed once and served on demand, rather than re-inferred on every session.
Measure the explore cost in your own codebase, enola is open source under Apache 2.0.
curl -fsSL https://raw.githubusercontent.com/enola-labs/enola/main/install.sh | sh