How I Keep Token Usage Under Control While Coding

When I ask an assistant to work on a project, I try to give it enough context to start in the right place. A very short request can leave it searching for information I could have supplied directly: what matters to the change, which behavior must stay intact, and how the result should be checked.

I give useful context upfront, work through unclear tasks in plan mode, maintain project instructions, and compact long sessions at useful stopping points. These are working habits; I haven't measured a fixed percentage of tokens or money saved.

Give context that helps with this task

For me, useful context means the goal, the relevant part of the project, and the boundaries of the work. It doesn't mean pasting the whole repository into a prompt.

The assistant still needs to inspect the current implementation. A file path or a short explanation can direct that inspection without replacing it. I want it to spend time understanding the code that matters, rather than rediscovering the purpose of the task.

Here's a generic example of the kind of task brief I'd provide for an API change. The paths are illustrative, and this isn't a transcript of a particular project:

Goal:
Add an optional date filter to an existing reports endpoint.

Starting points:
- src/api/reports/ handles the endpoint and request validation.
- src/services/reports/ contains the report query logic.
- tests/reports/ covers existing endpoint behavior.

Constraints:
- Keep current behavior when the filter is omitted.
- Preserve authorization, response fields, and pagination.
- Clarify date boundaries and timezone handling in plan mode.

Acceptance checks:
- Tests cover omitted, valid, invalid, and empty-result filters.
- Existing authorization and pagination checks still pass.
- The repository's lint, formatting, and build checks pass.

That gives the assistant a starting point and makes the questions about dates visible before implementation.

Spend questions on the plan before spending changes on the code

For a task like that, I use plan mode to have the assistant inspect the relevant code and ask focused questions. I answer, check its suggestions, and ask for a revised plan. We may need several rounds before the behavior, constraints, and acceptance checks are clear.

For example, should the end date include the whole day? How should a filter interact with pagination? I'd rather resolve those questions and update the plan before the assistant writes code that assumes an answer.

In my experience, this produces better results and reduces debugging caused by missing or misunderstood requirements. Planning itself uses tokens and time. The benefit I'm aiming for is less implementation rework across the task, rather than fewer messages in every session. Once the plan is clear, I move on to coding and verify the result against it.

Let project instructions carry the repeatable details

The task brief shouldn't have to repeat every rule in the repository. I keep stable guidance in the project's instruction files: conventions, documentation requirements, design decisions, and verification commands.

My post about project rules covers that setup. The reason it matters here is continuity. A new session should be able to learn the important rules without another chain of corrective prompts from me.

I try to keep the distinction clear between useful guidance and unnecessary material. Old decisions that no longer apply, duplicated explanations, and unrelated output can make the context harder to work with. More text alone doesn't make a task better specified.

Compact at a useful stopping point

I use compaction in the middle of a long session or after a stage is complete and I expect to continue working. A completed stage gives the summary a clearer shape: what was decided, what changed, what passed, and what remains.

Claude Code supports adding a focus to /compact, as described in its context-management guidance. For example:

/compact Preserve decisions, changed files, verification results, and remaining work.

That example is specifically for Claude Code. I check the available controls in the assistant I'm using instead of assuming the same command works everywhere.

Compaction summarizes earlier conversation to free space for continuing work. It can omit details, so I want the summary to preserve constraints and distinguish completed checks from planned ones. Claude Code's explanation of its context window gives the underlying model for this behavior.

Afterward, the repository remains the source for the actual code and current changes. If a detail matters and the summary is unclear, it needs checking again. Compacting a session that I'm about to abandon has little practical value; I use it to support the work that follows.

Keep usage and cost separate

Adding context consumes tokens too. The tradeoff I'm aiming for is fewer unnecessary searches and corrections across the task, rather than the smallest possible first prompt. Compaction also doesn't refund tokens already used.

Token counts, available context, subscription allowances, and billed costs describe different things. I don't assume a smaller context produces an equivalent reduction in a subscription usage meter or invoice. Model choice, caching, and the way access is billed also matter. Claude Code's usage and cost documentation explains the distinction between session token statistics and subscription usage.

For now, I'm keeping the claim modest: these habits help me organize the interaction and avoid repeating information unnecessarily. A proper savings claim would need comparable tasks and recorded usage.

This is part of the workflow I described in a year of using AI coding assistants. I'm still refining it, especially how much context to supply upfront and what needs to survive a long session.