The API bill behind a merged pull request

An AI coding session can look inexpensive on its own. A few prompts, some edited files, and a small API charge seem easy to judge. But the useful result is not a prompt or a generated patch. It is a change that passes review and gets merged.

Cost per merged pull request connects spending to that result. It is a practical starting point for understanding AI-assisted development, especially when an agent makes several attempts before producing something your team can use.

§ Start with a clear definition

A pull request is a proposed change to a codebase. Merging it means accepting that change into the target branch, usually after checks and review. To calculate a basic API-only metric, choose a reporting period and divide the AI coding spend by the number of pull requests merged during that period.

API cost per merged pull request = AI coding API spend ÷ merged pull requests.

Suppose a small project spends $24 on AI coding calls over a week and merges eight pull requests. Its API cost per merged pull request is $3. These are illustrative numbers, not model prices or an expected result.

Include spending on unsuccessful attempts, not just the final successful sessions. Otherwise, the metric hides the cost of work that was abandoned or repeatedly restarted. If nothing merges, report the spend and zero merges rather than trying to divide by zero.

§ Count the work around the first answer

A coding agent often does more than generate one patch. It reads files, inspects errors, runs tools, and revises its work. Depending on the client and protocol, later requests may include substantial context from earlier steps.

The final diff therefore tells you little about the token bill. A five-line fix might require a long investigation, while a larger routine edit might finish quickly. Common sources of extra spending include:

• Repeatedly sending repository context or long conversation histories.
• Retrying after failed tests or an incorrect diagnosis.
• Exploring approaches that are later discarded.
• Continuing a session after its task has become unclear.

With Vana API, usage is billed per real token with no monthly fee. That makes usage charges a direct starting point for this calculation. It does not make every session equally efficient: the task, model, context, and number of attempts still matter.

§ Keep API spend separate from human time

The API-only number is useful, but it is not the full cost of delivering a change. Someone still defines the task, reviews the patch, checks edge cases, and handles problems after merging.

If you want a broader estimate, track human time separately, then apply an internal hourly cost. For example, $3 in API usage plus half an hour of review at an assumed $60 per hour gives an estimated total of $33. Keep that assumption visible; it is not an invoice amount.

A lower token bill is not automatically a cheaper merged change. A session that saves a little API spend but creates an hour of extra review may be a poor trade. Equally, a higher-priced model is not automatically worth using for every small edit.

§ Use a small, repeatable record

Begin with a spreadsheet rather than a complicated dashboard. For each task, record its identifier, API spend, outcome, and approximate review time. Mark abandoned tasks too. If you cannot attribute usage precisely, start with a project-level weekly total and label it as an estimate.

Vana API provides one endpoint at https://api.vanaapi.com that supports OpenAI-compatible requests, Anthropic Messages, and Gemini native protocols. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDKs. Keeping experiments behind one service can make usage accounting simpler, though you still need a way to associate sessions with tasks.

If you want to measure your own workflow, create a Vana API account and start with a few well-scoped tasks.

§ Read the number alongside the work

Pull requests vary in size and difficulty. Splitting one change into several pull requests can lower the average without improving productivity. Compare similar work, keep your counting rules stable, and watch review effort and follow-up fixes alongside spending.

The goal is not the smallest possible number. It is a clearer picture of what it costs to turn a request into an accepted, maintainable change.