If an AI coding agent uses more tokens than you expect, the cause is often the work around the prompt. It may inspect a large repository, read the same files again, receive a long test log, or take extra turns because the task was unclear. The aim is not to make every request tiny. It is to provide enough relevant context for a correct change and avoid paying for context that does not help.
Give the agent a bounded task
Name the behavior that should change, the part of the project that owns it, and how you will check the result. A request such as “improve the app” leaves the agent to explore and invent a finish line. A request that identifies the failing behavior, relevant route, and expected result gives it a place to begin and a reason to stop.
For work that spans a few steps, ask the agent to inspect first and report the likely files before it edits. This can prevent a broad implementation based on the wrong assumption. For a tiny change, skip the extra planning turn and give a direct, testable instruction.
A prompt to adapt
Fix the failing date validation in the signup form. First identify the owning component and the test that covers it. Make the smallest change, add a regression case, and run that test. Do not refactor unrelated files. Summarize the diff and the exact command result.Send useful context, not a repository dump
Point the agent to the relevant package, error message, interface, or test. Avoid pasting generated bundles, dependency folders, minified files, or a full log when a short excerpt captures the failure. If project instructions already explain the test command or coding conventions, do not repeat the same long rules in every request.
Keep durable guidance short and specific. Project instructions are useful when they prevent repeated mistakes, such as choosing the right package manager or naming the check to run. Instructions that repeat generic advice on every task can make the context larger without making the change clearer.
Control tool output and retry loops
Ask the agent to run the narrowest relevant test first, then expand to a broader check when the local result is promising. If a command prints hundreds of lines, save the full output where it belongs and give the agent the failing section. Avoid asking it to rerun an unchanged command repeatedly without a new hypothesis.
Set a stopping point. Ask for the smallest passing patch and a summary of anything still unresolved. If it starts unrelated cleanup or keeps changing code after the acceptance check passes, stop the run and review the work already made.
- Write an observable acceptance check before starting.
- Give the agent only the files and logs that help with that check.
- Run one focused test before broader commands.
- Stop once the requested behavior passes and the diff is reviewed.
Measure spending as well as token count
Products do not all show raw tokens. Some show credits, requests, or a plan meter. Record the unit the product actually provides and compare similar tasks. If a provider reports cached input, output, and uncached input separately, preserve those fields because they may be priced differently.
Reducing token count does not always reduce the bill by the same percentage. A cached prompt may be cheaper than an uncached prompt, and some subscription plans use a meter that is not a direct token count. Compare cost, accepted result, and review time together. See the prompt caching guide before using a cache hit rate as a cost estimate.