The cost of one small coding task

A coding agent fixes a failing test in a few minutes. The bill shows token usage, but that does not immediately tell you what the fix cost. The agent may have read several files, tried an unsuccessful change, and run another round after seeing the test output.

To measure coding agent cost per task, start with the work you wanted finished. Then collect the charges for every attempt needed to finish it. This gives you a more useful number than the price of a single request.

§ Define a task before starting

A task should have a clear boundary and an observable result. “Improve the application” is difficult to measure. “Fix the date parser so the three failing tests pass without changing existing behavior” is easier.

Write down the acceptance condition before the agent starts. Otherwise, a short, inexpensive answer can look successful even when it leaves the work unfinished.

• Task: the specific change you want.
• Acceptance: the tests, review, or checks that establish completion.
• Boundary: when you start counting and when you stop.

If you send a follow-up because the first patch fails, keep that follow-up inside the same task. A new chat is not necessarily a new piece of work.

§ Read the bill in tokens

Tokens are pieces of text processed by a model. Input tokens include instructions, conversation history, file contents, and tool results sent to it. Output tokens include the response it generates, such as explanations and proposed edits.

An agent usually makes several model requests during one task. Running a local test does not itself consume model tokens, but sending the test output back to the model adds input to a later request.

For a basic estimate, cost equals input tokens divided by one million times the input rate, plus output tokens divided by one million times the output rate. Use the applicable billing categories when cached input or other separately priced usage appears. Do not assume every token has the same price.

For example, suppose a request uses 40,000 input tokens and 4,000 output tokens. At hypothetical rates of $2 per million input tokens and $10 per million output tokens, it costs $0.12. These are example rates, not a Vana API price quote. If a follow-up costs $0.04, the task total becomes $0.16.

§ Keep a small task log

You do not need a dashboard to begin. A spreadsheet with one row per task is enough. Record the task name, model, start and end time, total API charge, number of attempts, and whether the result passed your acceptance check.

Use reported usage or billing records wherever possible rather than estimating tokens from file sizes. If several tasks run at once, capture request identifiers or use separate sessions so you can attribute charges accurately. Record the rates and date too, since pricing can change.

Vana API provides an OpenAI-compatible endpoint at https://api.vanaapi.com and also supports Anthropic Messages and Gemini native protocols. It works with tools such as Claude Code, Codex, and Gemini CLI, with billing per real token and no monthly fee. Create a Vana API account to start collecting a small set of task measurements.

§ Count unsuccessful work too

A useful summary is total spending divided by accepted tasks. Suppose a batch costs $2.40 and produces 12 accepted results. The average API cost per completed task is $0.20. Include spending on abandoned attempts in that total; otherwise, failures disappear from your measurement.

Keep human review time and local compute costs separate from API charges. They matter, but combining them without explanation makes the result harder to interpret.

§ Compare similar tasks

Start with a small group of similar jobs, such as isolated bug fixes. Keep repository context, permissions, and acceptance checks reasonably consistent. Note unusually expensive tasks rather than hiding them inside an average.

The goal is not the cheapest individual response. It is a repeatable cost for work you can accept. Once you know that baseline, change one setting at a time and measure again.