2026-10-31Gunner Technology
Your Agent Starts Spending Before It Starts Coding
Your coding agent can spend its budget reading files, searching the repository and interpreting tool results before it changes anything. Give that exploration an allowance and require it to produce a useful finding before the factory pays for a wider search.
What are you paying for while it reads?
You're paying for the model to choose its next action and interpret what its tools return. Tokens are the pieces of text a model processes or generates. Context is the material available to it for a request, including instructions, conversation history and retrieved files. Reading a repository can put substantial material into that context before there is a patch to inspect.
The billing mechanism is explicit in Anthropic's tool-use documentation: tool definitions, calls and returned results contribute tokens to API requests. A local file search can therefore create model usage when its output is sent back for interpretation. The shell command and the model processing its output are separate parts of the job.
That makes an unchanged repository a poor signal of spending. The agent may be learning exactly what it needs. It may also be rereading a broad search result because it still hasn't found the relevant boundary. As we explain in The Price Card Is Not the Bill, charge the complete route to the work that requested it.
How do you recognize useful exploration?
Useful exploration leaves the next step better defined: it locates the behavior, identifies a constraint or rules out a plausible cause. Keep those findings beside the task. A transcript of searches is useful evidence, but the checkpoint should say what those searches established and what remains unknown.
Consider a hypothetical request to change an export. A productive investigation finds the export handler, the rule for archived records and the test that checks it. Another search may be warranted if the rule conflicts with the request. Repeatedly scanning unrelated directories without identifying a missing fact gives the factory a reason to interrupt the route.
Gunner Technology's position is that exploration should earn more room by narrowing uncertainty. Judge the finding against the requested behavior and the files that support it. Let a separate check reject a confident but unsupported explanation. The agent's claim that it understands the repository cannot be the only evidence that the search paid off.
How should you bound repository search?
Bound search by the question being investigated, the material returned and the allowance left for the job. Start with the repository's current entry points and operating instructions. Ask for matching filenames or focused excerpts before loading entire files. Expand when the result shows why another part of the system matters.
This fits Anthropic's guidance on context engineering, which describes retrieving material as needed through lightweight references and targeted queries. The factory can keep a pointer to a large artifact and retrieve the relevant part when the agent needs it. The whole artifact doesn't have to accompany every decision.
Make output limits visible. If a search returns only part of its matches, the worker needs to know that and have a way to narrow or continue it. Otherwise a smaller response can hide the evidence that would overturn the plan. Check that the selected material still includes the rules, dependencies and counterexamples the task needs.
When should the factory stop and ask?
Stop when the exploration allowance runs out or the next step requires a decision the agent doesn't own. Preserve the findings, the unresolved question and the proposed next action. A stopped investigation should be something a person can judge without opening the entire conversation.
If the missing fact is available through an approved tool, the machinery should retrieve it within the remaining allowance. If the request leaves a product choice open, ask the person who owns that choice. Those situations need different responses. Buying a larger context window won't decide whether archived records belong in the export.
Keep implementation and verification funded when exploration stops. Our argument in The Budget Is Part of the Harness applies here: the builder mustn't consume the capacity reserved for checking its work. A larger search allowance needs an explicit reason and an authorized change to the budget.
Measure exploration before expanding the line
Start with a recurring class of work in a repository you own. Record model usage during investigation separately from implementation and verification. Keep the abandoned investigations in the record too. Connect each completed search to its finding, then follow the task through acceptance so a cheap investigation doesn't hide an expensive mistake later.
When repeated searches expose the same missing entry point, improve the repository's navigation or task context. When a bounded search regularly misses a relevant dependency, repair that boundary. When the request itself stays ambiguous, fix intake. Each response addresses a different reason the agent needed more material.
People decide what deserves building and whether the result is right. The factory should assemble context, meter exploration and carry the findings forward. Before buying more agent capacity, inspect what the last investigation actually taught the next stage. That's where you can tell whether more spending will move the work forward.
Quick answers
Should a read-only agent have a spending limit?
Yes. Reading through model-driven tools consumes capacity even when the agent cannot change files, so attach the allowance to its task.
Should every search require human approval?
No. Let approved retrieval run inside the task's scope and allowance, and ask a person when the next step needs their judgment or more authority.
Can we share exploration findings with the next worker?
Yes. Preserve the finding with references and the repository version it was checked against, then recheck anything the next change could have invalidated.