Research-backed calculator guide

AI Coding Assistant Cost per Task: Build a Cost-per-Accepted-Task Model

Learn how to calculate AI coding assistant cost per task with token spend, retries, review time, CI, acceptance rate, and a transparent worked example.

The useful answer to AI coding assistant cost per task is not a seat price or a token rate. It is the total attributable cost of getting one coding task to an agreed outcome. That outcome might be a merged pull request, a passing bug fix, a reviewed migration, or a change accepted by a human reviewer.

A practical formula is:

Cost per accepted task = total cost of all attempts and delivery work ÷ accepted tasks

Include model and platform usage, retries, tool calls, CI and test runs, review time, rework, and a separately labeled risk or remediation reserve. Keep provider spend visible as its own line, but do not present it as the full cost of shipping code.

This guide uses a dated, US-English planning context checked on November 2, 2026. Vendor pricing and product limits change, so replace the example rates with the invoice or pricing page applicable to your account. The worked numbers below are estimates for method demonstration, not vendor quotes.

What belongs in the cost per task?

Start with the task boundary. A task should have an ID that can be joined to the model request, repository, branch or pull request, test runs, review events, and final status. Useful statuses include accepted, accepted_after_rework, rejected, abandoned, rolled_back, and still_open.

The first numerator category is AI usage. Capture input tokens, output tokens, cached tokens, tool calls, model choice, and any platform credits or subscription allocation. If an editor or agent hides the underlying model, record the platform event and the plan or credit rate used on the invoice date. Do not convert a plan into a per-task number until you state the allocation rule.

The second category is retry and loop cost. Include automatic retries, follow-up prompts, tool failures, context expansion, and repeated test-fix cycles. A failed attempt still consumed tokens and developer attention. If the agent makes three low-cost attempts before one passes, the successful patch does not have the same cost as a first-pass success.

The third category is delivery cost. A task can trigger CI minutes, ephemeral environments, test databases, artifact storage, or code-scanning jobs. Amazon Q Developer, for example, publishes a $19-per-user monthly Pro tier and a free tier with 50 agentic requests per month; its Java transformation feature also has line-of-code allowances and an overage rate. ^[3] That illustrates why “per task” can require more than a request count: one product exposes multiple meters.

The fourth category is human time. Measure review, debugging, requirements clarification, approval, and release work. Use a loaded hourly rate that your finance or engineering organization approves. If you do not have one, show a planning estimate and a sensitivity range rather than presenting a salary-based number as a fact.

The fifth category is rework and rejected work. If a generated change needs a rewrite, failed-test investigation, or security correction, assign that time to the task when the connection is reasonably clear. A rejected attempt belongs in the numerator and not in the accepted-task denominator.

Keep a reserve separate from realized cost. A rollback or incident reserve can represent anticipated risk, but it is not an invoice. When an actual incident occurs, replace or supplement the reserve with evidence. This separation makes the ledger auditable.

The cost-per-accepted-task formula

Let:

• T = total generated task attempts.
• A = accepted tasks under the documented quality rule.
• M = model, platform, and automated-review spend.
• R = retries and follow-up agent usage.
• C = CI, tests, runners, and temporary environments.
• H = human review and approval time.
• W = engineering rework after a failed test or review finding.
• D = investigation or handling of rejected and abandoned work.
• Q = separately labeled remediation reserve.

Then:

total attributable cost = M + R + C + H + W + D + Q

cost per accepted task = total attributable cost / A

Also calculate:

acceptance rate = A / T

This formulation aligns with the broader FinOps emphasis on shared accountability, accessible usage data, and ownership across engineering, finance, and business teams. ^[4] It does not prove that an assistant saves money. It gives you a comparable unit for testing that question against a human-authored baseline.

Allocate a subscription without fooling yourself

A monthly subscription does not automatically equal a task price. Choose a defensible allocation method. You can allocate a seat fee by accepted tasks, by active hours, by model usage credits, or by a fixed period cost assigned to a team. Each method answers a different question.

For a product whose plan includes a usage allowance, allocate the consumed portion first and leave unused capacity visible. If a $100 monthly plan produces 100 accepted tasks, a simple full-cost allocation is $1 per accepted task before other delivery costs. If only 20 tasks use the plan and the remaining capacity is reserved for other work, do not push the entire fee onto those 20 unless that is your agreed cost-center rule.

For API billing, calculate from the actual meter. With tokens billed per million, use (input tokens / 1,000,000 × input rate) + (output tokens / 1,000,000 × output rate), then add cache, tool, search, container, or regional modifiers where applicable. Anthropic’s documentation notes that prompt-cache writes and cache hits have distinct multipliers, so repeated repository context should not be priced as ordinary uncached input. ^[2]

Worked cost example

Assume a US engineering team pilots one coding-agent workflow for one month. It starts 100 bug-fix attempts and accepts 72 after review and testing. The following are planning assumptions, not vendor quotes. The $1.20 model amount is a blended estimate created for this example; replace it with your provider usage export.

The resulting cost is:

$3,475.20 ÷ 72 accepted tasks = $48.27 per accepted task

The acceptance rate is 72 ÷ 100 = 72%. For comparison, cost per attempt is $3,475.20 ÷ 100 = $34.75. The $13.52 difference is not a rounding issue. It is the cost of producing work that did not become an accepted outcome, allocated across the accepted tasks.

The shape of the ledger is more useful than the final cents. Human review is about 57% of the total. Rework is about 25%. Model usage and retries together are about 4%. If the team optimizes only token rates, it is optimizing a small share of this scenario. A shorter review loop, better task scoping, or a higher first-pass acceptance rate may have more leverage.

If accepted tasks rise to 80 while the numerator stays at $3,475.20, the result falls to $43.44. If rework minutes fall by one-third, the numerator falls by about $290.89 and accepted-task cost becomes about $44.23 at the original 72 accepted tasks. These are sensitivity calculations, not forecasts.

How to measure an AI coding agent fairly

Create a small event schema before building a dashboard. At minimum, store task ID, repository, task type, model or product, input and output usage, cache state if available, retry count, CI attempts, human review minutes, rework minutes, final status, merge time, and rollback link.

Use a consistent quality bar. A bug fix might require tests, review approval, and no rollback within 14 days. A documentation task may need a human acceptance label. A large migration may need a checklist and staged deployment. If two tools are evaluated against different bars, their cost per task is not comparable.

Segment by task family. “Coding task” can mean a typo fix, dependency upgrade, test generation, bug diagnosis, multi-file refactor, or greenfield feature. Average them together only after you can see each class. A cheap model may be appropriate for formatting but costly after retries on a cross-module change.

Keep the denominator stable. Count one accepted task once. If one request creates three merged changes, define whether that is one business task with three outputs or three tasks. Record the rule before comparing months. If an accepted change is rolled back, either remove it from the denominator or add a documented rollback penalty.

Use the AI token cost calculator to separate input and output assumptions, then compare the result with the model pricing comparison when model selection changes. For a broader team budget, the AI Agent Cost Calculator can hold monthly seat and usage assumptions. These tools support the model; they do not replace invoice reconciliation or outcome tracking.

Common mistakes and limitations

Using a seat price as task cost. A seat is a procurement unit, not an accepted engineering outcome. Allocate it transparently and show unused capacity.

Counting requests instead of work. One task may include many agent turns, tool calls, retries, and CI cycles. One request may also contain several unrelated edits. Use a task ID and outcome state.

Ignoring human time. If the question is total delivery cost, review and rework are not optional. If the question is provider-only spend, label it narrowly as provider cost per task.

Treating estimates as invoices. The worked example uses assumed rates. Vendor pages can provide a rate or plan rule, but they do not know your repository size, context reuse, retries, or acceptance process.

Comparing unlike quality bars. A workflow that merges quickly and fixes defects later can look cheaper than a workflow that requires tests and review before merge. The standard must be comparable.

Assuming lower task cost equals ROI. ROI needs a counterfactual: the cost, cycle time, quality, and risk of comparable work without the assistant. This article supplies a cost measurement method, not a savings guarantee.

FAQ

What is the best denominator for AI coding assistant cost per task?

Use accepted tasks that satisfy a documented quality rule. For code, that commonly means merged, tested, reviewed work that remains valid during a stated observation window. Keep cost per attempt as a companion metric, but do not call it cost per accepted task.

Should retries be included in coding assistant cost?

Yes. Include automatic retries, human-requested follow-ups, tool failures, and context-expansion calls that belong to the task. A failed attempt consumed resources even if a later attempt succeeds. Separate retry categories so you can diagnose the cause rather than hiding them in one blended rate.

Does prompt caching lower cost per coding task?

It can lower the metered input portion when repeated repository or instruction context is served from a cheaper cache-hit meter. The benefit depends on cache-write cost, hit rate, cache lifetime, provider pricing, and whether caching changes behavior. Measure cached and uncached tokens separately; do not assume every repeated prompt is a cache hit.

Should human review be included in an AI coding agent cost model?

Include it when the metric represents the cost of delivering accepted code. Use a stated loaded hourly rate and measured minutes. If you are budgeting only a vendor invoice, exclude human time but label the result “provider cost per task” so it is not mistaken for full engineering cost.

How do I estimate cost per bug fix when I lack token data?

Start with a dated planning estimate based on a sample of tasks. Record attempts, retries, review minutes, CI runs, and accepted outcomes. Use the provider invoice to allocate the AI line later. Show low, base, and high cases, and replace the estimate with observed usage as soon as the platform exposes task-level events.

Can this model compare a subscription with an API workflow?

Yes, if the boundary and quality bar are the same. For the subscription, allocate the applicable seat or plan cost and usage allowance. For the API workflow, calculate token and tool charges from the provider meter. Then add identical review, CI, rework, and acceptance rules. Do not compare a capped subscription’s sticker price with an uncapped API workflow’s full production workload without stating the capacity difference.