Describe the behavior, not the whole repository
Start with an observable problem, the expected result, and a likely entry point when you know it. Ask the agent to locate the implementation and relevant callers before editing. Pasting the entire repository can bury the files that matter and spend context on generated or unrelated material.
The total is wrong when an item quantity changes.
Start with the cart calculation and its tests.
Trace the callers before editing; preserve discount rules.
Add a regression for quantity 2 -> 3 and run the cart suite.
Report what passed and what you could not verify.Use symbol context and bounded tool output
- Use definitions and references when a configured language server can identify a symbol and its callers. Read additional context when the symbol’s behavior depends on it.
- Pass the specific error, stack trace, failing assertion, and relevant command instead of an entire repetitive log. Keep enough surrounding output to preserve the cause.
- Identify generated files and build artifacts before a search. Do not exclude source, fixtures, or configuration merely to make the context smaller.
- Keep follow-ups in the same conversation when they depend on earlier findings. If the goal changes substantially, begin a new task with a short, factual handoff.
Keep the checks that establish correctness
Dropping tests to save tokens trades evidence for a smaller transcript. Choose the checks that exercise the changed behavior, preserve existing assertions, and broaden verification when the patch affects more than the initial scope. A frontend interaction may need a browser check as well as unit tests.
A failed command is evidence, too. Ask the agent to explain the failure and change the next action based on it. Repeating the same command without a new hypothesis can increase cost without improving the outcome. Distinguish an environment failure from a failing assertion.
Measure complete runs, including retries
Compare repeated trials with the same acceptance criteria. Calculate cost per accepted change where costs can be attributed, and label unavailable data instead of estimating it. Do not compare raw token counts across models as if their tokenization and pricing were identical.
| Record | Why it matters |
|---|---|
| Repository commit, task, model, and permissions | A changed baseline can make a cost comparison misleading |
| Input, cached input, output, and all attempts where exposed | A final answer omits the work and retries that produced it |
| Usage limits and the actual billing basis | Subscription allowances and token-based API charges are different |
| Accepted result and independent check output | A cheap failed run is not an accepted change |
| Review effort and unresolved work | The developer’s correction time is part of the workflow |
What token efficiency means for LoopCode
LoopCode is designed for focused project work with repository tools, language-server context when available, and visible verification steps. Those capabilities let you narrow the investigation while keeping the final change reviewable. They do not establish a universal accuracy score or a fixed token reduction.
A defensible efficiency comparison needs a stated baseline, task set, models, settings, repeated runs, and equivalent acceptance checks. Use the evaluation worksheet to collect evidence from your own project.
KEEP GOING
A useful next step.
Put it to work in your project.
Desktop, CLI, and VS Code. One LoopCode account. Free to start.