AI Coding Agent Token Consumption: Where It Comes From

AI coding agents consume tokens mainly by sending conversation history, instructions, code and tool results to a language model, then counting the model’s generated response. Repeated calls can make the same context recur, so a long agent run may use far more tokens than the final code change suggests.

What a token means

A token is a unit of text processing, not necessarily a word or a character. Depending on the tokenizer and text, a token might be part of a word, a short word, punctuation, or a code fragment. Whitespace, symbols, and formatting can contribute too. Token counts therefore cannot be estimated reliably by counting lines or words alone.

For a model call, usage is commonly divided into input tokens and output tokens. Input is everything supplied for the model to consider; output is what it generates. Some services separately report cached input, reasoning tokens, or other categories. The labels and billing treatment depend on the model provider and product, so the usage report for the specific system is the source to consult.

Where the tokens go in an agent run

An agent is often a loop rather than a single request. It receives context, proposes an action, uses a tool such as a shell or file editor, receives the result, and then makes another model call. The main sources of consumption are:

• System and developer instructions: persistent directions about the agent’s role, available tools, output format, and constraints.
• Conversation history: the user’s request and earlier assistant and tool messages, when the system includes them again.
• Repository context: relevant source files, configuration, documentation, test fixtures, or search results added to the prompt.
• Tool descriptions and actions: schemas explaining available tools, plus generated commands or proposed edits.
• Tool results: terminal output, compiler diagnostics, test logs, search matches, and file contents returned to the agent.
• Model responses: explanations, plans, tool calls, patches, and final summaries.

For example, an agent asked to fix a failing test may receive a task description and instructions, inspect files, run a test command, read its output, edit code, and run the test again. Each model decision can add generated tokens, while each returned test log can add input tokens to a later call.

Why repeated calls can multiply usage

In a simple chat, the model may receive the current message plus some history once. An agent can make many successive calls. If the application resends the accumulated transcript on each call, earlier instructions and results are counted again as input, even though they have not changed. This is one reason total consumption can grow faster than the amount of new information exchanged.

That pattern is not universal. An implementation may summarize old messages, omit irrelevant results, keep state outside the prompt, or use provider-supported prompt caching. Caching can reduce repeated processing charges in some systems, but it does not necessarily mean those tokens disappear from usage accounting. Check the provider’s definitions rather than assuming that a cached prompt is free or excluded.

Tool calls also have different effects. A compact command that returns a short status is usually a smaller context addition than a command that prints a large file or a long test trace. The agent’s own request to run a tool and the tool’s returned output are separate pieces of the interaction; how they are counted depends on how the product represents the call.

How to trace a real run

To understand consumption, follow the sequence of model requests and responses, not just the final answer. If your coding environment exposes a usage view or request logs, compare each call’s input and output counts and note the tools used between calls.

1. Record the task and model. Note the exact request and which model or model configuration handled it; different tokenizers and context handling can change counts.
2. Inspect each request’s inputs. Identify persistent instructions, conversation history, file excerpts, tool definitions, and any retrieved context.
3. Inspect each response. Separate ordinary text from generated tool calls or code, where the usage view makes that distinction.
4. Follow tool results into the next call. See whether logs or file contents were returned and whether they were included again as context.
5. Compare usage totals with the product’s report. Confirm whether it distinguishes cached tokens, reasoning tokens, or other categories, and whether its totals are per call or per run.

Some interfaces expose only a session total, not raw prompts or per-call accounting. In that case, you can still compare runs with the same task while changing one factor, such as limiting test output. Avoid putting secrets or private source code into third-party logging tools just to inspect token use.

What usually drives high consumption

Large context and repeated work are common drivers. A broad repository search may return many irrelevant files; verbose tests may return thousands of lines; repeated retries may resubmit prior context; and a vague task may lead the agent to explore several approaches. A long generated explanation can also increase output usage, though input context is often a substantial part of multi-step runs.

Token totals alone do not show whether the work was wasteful. A run that reads more code may be justified if it prevents an incorrect edit, and a short run may miss necessary tests. Look at the task outcome alongside the token breakdown and call sequence.

Ways to reduce avoidable usage

Reduce unnecessary context without removing information the agent needs to work correctly. Practical options include:

• Give a specific task, relevant file paths, and clear acceptance criteria.
• Ask the agent to inspect targeted files before broad searches, where your workflow allows it.
• Limit command output, for example by selecting relevant test failures instead of printing every passing test.
• Keep tool results focused and avoid repeatedly asking for full-file dumps when a diff or excerpt is enough.
• Set a reasonable stopping condition and review changes before allowing repeated repair attempts.
• Use summaries or context-management features only when available, and verify that important requirements remain in context.

These measures can reduce token use, but they may trade off against completeness. For a change that affects many modules, broader inspection or a full test suite may be appropriate.

Frequently Asked Questions

Do tool calls use tokens?
Usually, the model-generated tool request and the tool’s returned text can affect usage when they are part of model requests or responses. The exact accounting depends on the agent and provider.

Why does the token count rise when I did not send another message?
The agent may be making additional model calls on its own to inspect files, run tools, interpret results, or revise a change. Those steps can add both input and output tokens.

Does a longer code file always mean more tokens?
Not in a direct, fixed ratio. Tokenization depends on the text, and a system may send only selected portions of a file rather than the whole file.

Are cached tokens counted?
That depends on the provider’s reporting and pricing rules. Some usage reports show cached input separately, so read the definitions for the service you use.

Is output or input the bigger source of usage?
It varies. Agent runs can accumulate substantial input from repeated context and tool results, while large patches or explanations add output. Per-call usage data is the best way to tell for a particular run.

Related

• AI Assistant Long-Term Memory With Hindsight
• Halo Infinite vs Halo: What Returning Players Need
• Can an AI Coding Agent Remember Without Making Things Up?