Be Specific, Save Tokens: How a Precise File Path Saves a Whole Exploration Phase

•By Blacdisk Team

Be Specific, Save Tokens: How a Precise File Path Saves a Whole Exploration Phase

Key Takeaways

  • "Fix the bug" and "fix the bug in src/auth/session.ts, line 84" trigger two completely different workflows — one includes a search phase, the other doesn't.
  • Exploration isn't free: agents spend the majority of their working time just locating the right code before they can act on it.
  • A precise path collapses that search into a single read, which is the cheapest possible way to give an agent context.
  • This isn't a one-time trick — it compounds. Every vague prompt in a long session re-triggers exploration; every specific one skips it.

There's a small habit that separates people who get fast, cheap results from a coding agent from people who don't: naming the file. Not "the auth code" or "the config somewhere in the backend" — the actual path. src/auth/session.ts. It looks like a minor courtesy, the kind of detail you'd skip because the agent can obviously just find it. But finding it is the expensive part, and skipping past it is one of the highest-leverage things you can do in a prompt.

Exploration is where most of the agent's effort actually goes

It's easy to picture an agent's work as mostly writing code, with a quick lookup beforehand. The reality is closer to the reverse. (cite index="4-1">Coding agents spend more than 60% of their time searching for context, and the quality of that search — not the model's size, not the size of the context window — determines whether the agent succeeds or fails. Writing the fix is often the fast part. Finding where the fix belongs is what eats the clock and the token budget.

That search isn't a single lookup — it's a loop. (cite index="4-1">The agent plans and executes multi-step searches with reasoning between each step: it forms a hypothesis about where the code might live, tests it with a tool call, and follows the resulting chains across files rather than retrieving everything in one pass. Each of those steps — a grep, a file read, a moment of reasoning about what to try next — adds up. A precise path removes the entire loop. There's no hypothesis to form when you've already told the agent where to look.

What a vague prompt actually costs

Anthropic's own guidance on Claude Code is blunt about the underlying constraint. (cite index="10-1">Most best practices are based on one constraint: Claude's context window fills up fast, and performance degrades as it fills. Every exploratory grep call and every file the agent opens "just to check" adds to that fill — and it adds up faster than it looks in the moment.

One developer who tracked this in practice put concrete numbers on the gap between a vague, open-ended instruction and a scoped one. Their comparison: (cite index="12-1">a bad prompt like "understand the auth system and fix the bug" tends to cause broad scanning of the wrong files and unnecessary context usage, versus a better prompt that says "find the login entrypoint, read only the files needed to explain token validation, do not scan unrelated directories". The second version isn't just more polite — it's a direct instruction to skip the search loop the first version forces the agent into.

The same practitioner's fix for their own workflow was to front-load specificity once, in a reusable form: (cite index="12-1">maintaining a docs/repo_map.md listing main entrypoints, key modules, test commands, auth and payment flows, generated folders to avoid, and the files Claude should read first. That's the file-path habit scaled up — instead of specifying the path fresh in every prompt, it's written down once so every future prompt can point at it.

Precision works because it replaces search with retrieval

There's a real distinction between an agent that searches for code and one that retrieves it, and the gap between them is almost entirely about whether you already know the target. Tooling built specifically to speed up agent workflows leans hard on this distinction. One code-intelligence project frames the difference this way: (cite index="16-1">most AI agents explore repositories the expensive way — opening entire files, skimming thousands of irrelevant lines, and repeating — while structured retrieval lets an agent search for a symbol once and fetch the exact implementation instead. A file path in your prompt gives the agent that same shortcut without needing any extra tooling at all: it already has the symbol's address.

[Chart: Time or token cost per task — "vague prompt (search + read)" vs. "precise file path (read only)", illustrating the exploration phase that a specific path removes]

This is also why Claude Code's own built-in agents are split by role. (cite index="21-1">The Explore agent runs on a fast, cheap model, skips loading project-level instructions for faster startup, and is best suited for quick keyword searches and "where is this code" questions — it exists precisely because locating code is a distinct, high-volume task worth isolating from the more expensive reasoning work of actually writing the fix. When you supply the path yourself, you make that entire agent unnecessary for the task at hand.

The habit compounds over a session

A single precise path saves one exploration cycle. But sessions rarely involve just one request — they're a sequence of them, and vagueness in each one re-triggers the same cost. The core loop Anthropic recommends for agentic coding makes the split explicit: (cite index="10-1">enter plan mode so Claude reads files and answers questions without making changes, then ask for a detailed implementation plan, then switch out of plan mode to let Claude code against that plan. Naming exact files during the explore step is what makes that step fast instead of another open-ended scan.

The token cost of skipping this compounds badly on longer tasks. As one practical guide to cutting Claude Code's token usage puts it, the alternative to bounded, targeted requests is scope creep: (cite index="13-1">subagents are useful but only when tightly controlled, since they tend to wander off — instead of prompting "investigate the repo," the better version is "inspect only src/auth and tests/auth, return max 15 bullets, include exact files, no implementation, no broad repo scan". That's file-path precision applied at the instruction level, not just to a single lookup — bounding where the agent is allowed to look, not only what it's looking for.

What this means for how you write requests

None of this asks you to do the agent's job for it. You're not writing the fix — you're just skipping the part of the process where it has to go find where the fix belongs, which happens to be the most expensive part.

Frequently Asked Questions

Isn't finding the right file part of what I'm paying the agent to do?

Sometimes, yes — when you genuinely don't know where the code lives, search is the right tool and worth the cost. But (cite index="4-1">since search consumes the majority of an agent's working time on a typical task, it's worth paying that cost only when you actually need to. If you already know the path, spending tokens to have the agent rediscover it is pure overhead.

Does this still matter with a very large context window?

It matters more, not less. A bigger window doesn't change the underlying pattern — (cite index="10-1">Claude's context window fills up fast, and performance degrades as it fills, regardless of how large that window starts out. A precise path keeps the fill rate low no matter how much room you have to spare.

What if I don't know the exact path myself?

Approximate specificity still helps. Naming a directory ("look in src/auth, not the whole repo") narrows the search space even without the exact filename, and a maintained repo map — as one practitioner's workflow shows, (cite index="12-1">listing entrypoints, key modules, and files to read first — gets you most of the benefit without requiring you to memorize the codebase yourself.