Precise Requests Are Token Economics, Not Politeness — Using LLMs Well (1)

If you use a coding agent, this will feel familiar. You say "take a look at the login stuff," and the agent immediately starts sweeping the codebase. It opens plausibly-relevant files one by one, follows the router, checks the middleware. What you actually wanted was "the 401 that loops forever after the session expires" — but the agent doesn't know that, so it reads everything from the login UI to token issuance. By the time an answer arrives, there is less room left to actually fix anything.

We tend to file this under manners: "be clearer." But it isn't manners — it's performance. Why a precise request produces a better result follows inevitably from how an LLM actually works. This post walks that mechanism and derives the practical technique from it. It applies to anyone building on LLM agents, regardless of product.

What actually happens

A vague request forces the agent into "exploration." Since nothing is specified, the only thing it can do is read files hunting for clues. That exploration isn't free. Everything it reads piles into the agent's working space, and that space is finite. The longer exploration runs, the further your actual requirement gets pushed back and blurred. The outcome is one of two things — it fixes the wrong place, or it fixes the right place slowly and with a lot of backtracking.

Why — how an LLM works

Three things overlap here.

First, context is a fixed budget. An LLM only sees the world inside a context window of a fixed size (roughly 200k tokens on current models). The system prompt, your instructions, the files it reads, tool output — all of it shares this one budget. Reading a single source file costs roughly 1,100–2,400 tokens. A vague request that triggers ten file reads burns 20k tokens on that alone. As the budget fills, your original instruction near the front gets summarized or truncated away. Anthropic states this plainly in its own docs — "File reads dominate context usage. Be specific in prompts so Claude reads fewer files."

Second, attention is a zero-sum competition. In a transformer's self-attention, the model references every prior token when producing the next one — but the total of that reference (the attention mass) is normalized to sum to 1. So the more tokens in context, the smaller the share the important tokens — your actual requirement — receive. Load the window with irrelevant file contents and the core instruction is diluted into noise. The operation is also O(N²) in the number of tokens N, so long context is slow on top of everything.

Third, the middle of a long context gets read poorly. Known as "lost in the middle," models attend more strongly to the very start and end of the context and recall middle content less reliably. If a long exploration pushes your initial instruction into the middle of a pile of file dumps, that instruction is physically present but functionally weak.

Put together: the real cost of a vague request is not "the annoyance of being asked again" — it is signal dilution and budget exhaustion. Narrowing a request is not courtesy; it's token optimization.

So how should you write requests

Give the agent, up front, what it would otherwise have to discover by reading — and it reads that much less. Put three things in the request.

• A verb — what action you want. Fix / add / move.
• A symptom or location — "401 loops after session expiry," or if you know it, auth.middleware.ts.
• The expected result — "when it detects an expired cookie, redirect quietly to re-login."

The difference is stark side by side:

• ❌ "look at the login stuff"
• ✅ "After the session expires, a 401 loops forever. In auth.middleware.ts, detect the expired cookie and route to the re-login flow."

One extra sentence, and the agent skips the wide sweep and goes straight to the spot. If you don't know the file path, a specific symptom alone still narrows the search — the tighter the symptom, the tighter the exploration.

RoutineCode runs on the same principle

The way RoutineCode handles work is this principle implemented at the product level. Rather than blindly reading files, it skips exploration when the request is precise, and when a broad search is genuinely needed it pushes that cost into a separate subagent context to protect the main conversation's budget. If an investigation needs to read twenty files, those twenty are read in an isolated window and only a summarized conclusion returns to your session.

This is also where the difference from vanilla Claude Code shows. The base agent, even for repetitive lookups — "does this project build," "where is this symbol used," "how are the dependencies tangled" — ends up opening files, loading them into context, and answering by reasoning; the reading itself eats the budget. RoutineCode adds a layer on top: it handles these routine lookups with deterministic tools instead of reasoning, returning a structured answer instead of file bodies into context. Because the bodies never enter the reasoning window, the context spent on the same question is fundamentally different. And when a broad search is warranted, it decides "handle directly, or delegate to an isolated exploration agent" before reading anything — cutting needless exploration before it starts.

Your writing a precise request and RoutineCode isolating exploration serve the same goal — keeping the core signal from being diluted into noise, and keeping the budget available for the actual work — from two directions.

What you get

• Faster first response. Fewer exploration rounds mean it touches the right spot from the start.
• Right on the first try. The requirement isn't diluted into noise, so there's less fixing-the-wrong-thing-then-reverting.
• Your intent survives long tasks. With budget to spare, your instruction isn't pushed into the forgotten middle.

In practice, the "explain again, redo again" loop shrinks noticeably. Using an agent well comes down to giving it good input, and the first rule of good input is narrowing what it has to explore before it explores.

---

This is part 1 of the "Using LLMs Well" series. Next: why always-loaded instructions like CLAUDE.md get followed less the longer they get — the paradox that more rules means worse adherence — explained by the same principle.

References

• Best practices for Claude Code — Anthropic
• Explore the context window — Anthropic