Per-Token Billing for Coding Agents: A Walkthrough

A coding agent’s bill is not the price of its final patch. It is the accumulated cost of the model requests used to inspect code, propose changes, and respond to results. To understand spending, follow the requests rather than counting completed tasks. Agent usage tracking can aggregate token consumption across those requests. ([openai.github.io](https://openai.github.io/openai-agents-python/usage/?utm_source=openai))

1. Start with the billing unit

A token is a unit of model input or output, not a line of code. Identifiers, punctuation, comments, and prose all contribute to token counts. Different models can tokenize identical content differently, so file size and word count are only rough budgeting signals. Use token estimates for planning and reported usage for reconciliation. ([help.openai.com](https://help.openai.com/en/articles/4936856-what-are-tokens-and-how-to-count-them%23.xlsx?utm_source=openai))

2. Separate input from output

Input includes the material submitted to the model; output includes what the model generates. These categories can have different rates. For tool-enabled requests, tool definitions and supporting instructions can also contribute to input usage. Your typed request is therefore not necessarily the largest part of the payload. ([platform.claude.com](https://platform.claude.com/docs/en/about-claude/pricing?utm_source=openai))

Before investigating an expensive task, inspect the actual request construction. Ask which files, instructions, conversation messages, and tool definitions the client includes. Do not estimate the bill from the length of the user’s instruction alone.

3. Follow the agent loop

Consider a hypothetical task: fix a failing parser test. The agent requests a file, examines the returned contents, proposes an edit, runs a test, and examines the failure output. Each subsequent model request has its own usage. Generated tool calls and returned tool content can contribute tokens, while some provider-hosted tools also carry separate charges. ([platform.claude.com](https://platform.claude.com/docs/en/about-claude/pricing?utm_source=openai))

When reviewing a run, group requests under one task identifier. Include subagents, retries, and summarization requests if the client makes them. Otherwise, a cheap-looking primary conversation can conceal work billed elsewhere in the same task.

4. Apply rates without double-counting

For rates quoted per million tokens: multiply each billable category’s token count by its applicable rate, divide by 1,000,000, and sum the results. Add separately priced features where applicable. Categories may include ordinary input, cached input, cache writes, and output; the exact categories depend on the model and service. ([developers.openai.com](https://developers.openai.com/api/docs/pricing?utm_source=openai))

Read usage-field definitions before implementing this calculation. For example, OpenAI reports cached tokens within input tokens and reasoning tokens within output tokens. Adding those detail fields to their parent totals would count them twice. Other response formats need their own normalization rules. ([developers.openai.com](https://developers.openai.com/api/docs/guides/agents-api/observability?utm_source=openai))

5. Treat caching as measured behavior

Prompt caching can change how eligible repeated input is priced, but repeated content does not automatically prove a cache hit. Inspect the reported cached-token counts and any cache-write categories. Keep stable instructions and reusable context consistent where practical, then verify the outcome rather than assuming the discount. ([developers.openai.com](https://developers.openai.com/api/docs/guides/prompt-caching?trk=article-ssr-frontend-pulse_x-social-details_comments-action_comment-text&utm_source=openai))

For budgeting, distinguish a cold first request from subsequent requests. Use the service’s actual cache rates and eligibility rules; do not apply a universal discount to the entire conversation.

6. Count more than the visible answer

A concise explanation or small patch does not guarantee low output usage. Reported output can include generated tokens that are not visible in the response text. Inspect the complete usage record rather than counting the displayed answer, and check reasoning details when the endpoint exposes them. ([developers.openai.com](https://developers.openai.com/api/docs/guides/token-counting?utm_source=openai))

7. Keep a request-level ledger

With CodeRelay Hub, a shared endpoint provides one integration path across model families. Build your accounting around explicit request records rather than assuming every model returns identical usage fields.

• Record the task identifier, request identifier, model, timestamp, and outcome.
• Preserve raw usage alongside normalized billing categories.
• Record the applicable rate and calculated charge for each request.
• Reconcile task totals against the service’s billing records.

8. Control the work, then compare outcomes

Set task budgets, bound iteration counts, and request focused file reads instead of indiscriminate repository dumps. Investigate repeated failures before allowing another retry. Compare total spending against an accepted result: a reviewed patch with passing checks. The useful target is predictable cost per successful task, not merely fewer tokens per response.

Open a free CodeRelay Hub workspace.