Tracking the Cost of AI Agent Runs Across Development Teams

AI agents can automate several software development activities, including code generation, debugging, testing, repository analysis, and pull request preparation.

As teams adopt these agents, their usage can increase quickly. A developer might use an agent for a small code change, while another runs multiple agents to investigate bugs, generate tests, and review an entire repository.

Although individual tasks may appear inexpensive, the combined usage across a development team can become difficult to predict.

A single agent run may involve several model requests, tool executions, code inspections, and repeated reasoning steps. If the agent encounters an error or receives an unclear instruction, it may repeat operations and consume additional tokens.

Without proper tracking, engineering managers may know that AI tools are being used but have limited visibility into which projects, developers, or tasks generate the highest costs.

Tracking AI agent costs requires more than monitoring API token usage. Teams need to measure complete agent runs, associate usage with development activities, and understand the relationship between cost and engineering output.

This article explains how to build an AI agent cost-tracking system, collect usage data, calculate expenses, monitor team consumption, and identify opportunities to reduce unnecessary spending.

Why AI Agent Costs Are Difficult to Track

A traditional API request usually has a relatively straightforward usage pattern.

An application sends a request to a model, receives a response, and records the token usage.

An AI coding agent works differently.

One development task may involve several operations:

Receive the developer's request.
Inspect repository files.
Search for relevant code.
Send context to a language model.
Generate an implementation plan.
Read additional files.
Modify source code.
Run tests.
Analyze test failures.
Generate a final explanation.

Some of these operations involve model calls, while others involve tools such as terminal commands, file access, or Git operations.

A single agent run can therefore generate multiple model requests and tool executions.

The cost may also differ between model calls because of:

Input token volume.
Output token volume.
Cached input usage.
Model selection.
Reasoning-token accounting.
Provider-specific pricing.
Additional service charges.

A system that records only the final response will miss much of the activity.

Understand the Main Components of Agent Cost

Before building a tracking system, identify which activities generate measurable costs.

Input Tokens

Input tokens represent the information sent to the model.

For a coding agent, this may include:

Developer instructions.
Repository context.
Source-code files.
Git diffs.
Previous conversation messages.
Tool results.
System instructions.

Large repositories can produce substantial input usage when agents repeatedly send similar context.

Output Tokens

Output tokens represent the content generated by the model.

Examples include:

Implementation plans.
Source code.
Explanations.
Tool-call instructions.
Test suggestions.
Review summaries.

Some providers account for reasoning tokens separately or include them within output usage. Follow the provider's actual usage reporting rather than assuming every token category is billed identically.

Cached Tokens

Some model providers support prompt or input caching.

When previously processed input is reused, cached input may have a different price from ordinary input.

For example, a coding agent may repeatedly send the same repository instructions or project documentation across multiple requests.

If the provider reports cached input usage, record it separately.

Tool Execution Costs

An agent may also use external tools.

Examples include:

Cloud-hosted development environments.
Code execution services.
Repository analysis tools.
External search APIs.
Browser automation.
Third-party plugins.

Not every tool call generates a separate bill. Some tools run locally, while others have usage-based pricing.

Track tool execution costs separately when the provider exposes them.

Infrastructure Costs

An agent platform may require additional infrastructure.

For example:

Cloud virtual machines.
Container execution environments.
Temporary storage.
Logging services.
CI/CD runners.

These costs should not be mixed blindly with model token costs.

A useful cost report should distinguish model usage, tool usage, and infrastructure expenses.

Design a Cost-Tracking Architecture

A practical cost-tracking system should collect usage information from every agent execution and connect it with the developer task that generated it.

A simple architecture looks like this:

Developer Request
       |
       v
AI Agent Orchestrator
       |
       +------------------+
       |                  |
       v                  v
Model API Calls       Tool Executions
       |                  |
       v                  v
Usage Metadata       Execution Metadata
       |                  |
       +---------+--------+
                 |
                 v
          Usage Collector
                 |
                 v
          Cost Calculator
                 |
                 v
          Usage Database
                 |
                 v
          Cost Dashboard
                 |
                 v
       Team and Project Reports

The agent orchestrator should assign a unique identifier to every run.

Every model request and tool execution should carry that identifier.

This makes it possible to calculate the total cost of a task rather than reporting each API request independently.

Step 1: Assign a Unique ID to Every Agent Run

Start by generating a unique run identifier whenever a developer starts an agent task.

For example:

{
  "run_id": "run-2026-1103-001",
  "developer_id": "dev-102",
  "team_id": "backend-team",
  "project_id": "payment-api",
  "task_type": "code_generation",
  "started_at": "2026-11-03T10:30:00Z"
}

The identifier should be included in every related model request, tool call, and usage event.

Without this relationship, it becomes difficult to determine which requests belong to the same task.

For example, a developer might run three agents simultaneously:

One agent investigates a production bug.
Another generates unit tests.
A third reviews a pull request.

All three runs may use the same model and API account.

The run identifier separates their usage.

Recommended Tracking Dimensions

Field	Purpose
run_id	Identifies the complete agent run
developer_id	Identifies the responsible developer
team_id	Groups usage by engineering team
project_id	Connects usage with a project
repository	Identifies the source repository
task_type	Classifies the development activity
model	Identifies the model used
provider	Identifies the model provider
started_at	Records the start time
completed_at	Records the completion time
status	Tracks success, failure, or cancellation

Use stable identifiers rather than storing unnecessary personal information.

Step 2: Capture Token Usage From Model Responses

Most model APIs provide usage metadata in their responses.

For example, a response may contain information similar to:

{
  "usage": {
    "input_tokens": 12000,
    "output_tokens": 2500,
    "cached_input_tokens": 4000
  }
}

The exact response structure depends on the model provider.

Some providers expose additional categories, such as reasoning tokens or cache creation tokens.

Your usage collector should normalize these fields into a common internal format.

For example:

def normalize_usage(response):
    usage = response.get("usage", {})

    return {
        "input_tokens": usage.get("input_tokens", 0),
        "output_tokens": usage.get("output_tokens", 0),
        "cached_input_tokens": usage.get(
            "cached_input_tokens", 0
        )
    }

This is a simplified example. Adapt it to the actual response schema of the selected provider.

Do not estimate usage from the length of the generated text when the provider already supplies authoritative usage metadata.

Also record the model identifier used for each request. Pricing can differ between models and change over time.

Step 3: Calculate the Cost of Each Model Request

Once token usage is available, calculate the cost using the applicable provider pricing.

A basic calculation is:

[
\text{Cost} =
\frac{\text{Input Tokens}}{1,000,000}
\times \text{Input Rate}
+
\frac{\text{Output Tokens}}{1,000,000}
\times \text{Output Rate}
]

If cached input has a separate price, include it as another component.

For example, assume the following illustrative pricing:

Usage type	Example rate per million tokens
Input	$2.00
Cached input	$0.50
Output	$8.00

Suppose an agent request uses:

12,000 input tokens.
4,000 cached input tokens included within the input total.
2,500 output tokens.

If the 4,000 cached tokens are a subset of the 12,000 input tokens, calculate ordinary and cached input separately:

[
\text{Ordinary Input} = 12,000 - 4,000 = 8,000
]

[
\text{Cost} =
\frac{8,000 \times 2.00}{1,000,000}
+
\frac{4,000 \times 0.50}{1,000,000}
+
\frac{2,500 \times 8.00}{1,000,000}
]

This example uses hypothetical rates to demonstrate the calculation.

In production, use the provider's current pricing and the exact billing categories reported by the API. Avoid double-counting cached tokens if the provider already includes them in another usage field.

Implement a Basic Cost Calculator

def calculate_request_cost(
    input_tokens,
    output_tokens,
    cached_input_tokens,
    input_rate,
    output_rate,
    cached_rate
):
    ordinary_input = max(
        input_tokens - cached_input_tokens,
        0
    )

    input_cost = (
        ordinary_input * input_rate
    ) / 1_000_000

    cached_cost = (
        cached_input_tokens * cached_rate
    ) / 1_000_000

    output_cost = (
        output_tokens * output_rate
    ) / 1_000_000

    return input_cost + cached_cost + output_cost

The function expects rates expressed as currency per million tokens.

Store the rates used for every calculation so historical reports remain reproducible when provider pricing changes.

Step 4: Store Usage Events in a Database

A cost-tracking platform should retain individual usage events rather than storing only daily totals.

This makes it possible to investigate expensive runs and recalculate historical costs when pricing information changes.

A relational database can store usage records using a structure like this:

CREATE TABLE agent_usage (
    id BIGINT GENERATED ALWAYS AS IDENTITY
        PRIMARY KEY,

    run_id VARCHAR(100) NOT NULL,
    developer_id VARCHAR(100) NOT NULL,
    team_id VARCHAR(100) NOT NULL,
    project_id VARCHAR(100) NOT NULL,

    provider VARCHAR(50) NOT NULL,
    model VARCHAR(100) NOT NULL,

    input_tokens BIGINT DEFAULT 0,
    output_tokens BIGINT DEFAULT 0,
    cached_input_tokens BIGINT DEFAULT 0,

    request_cost DECIMAL(18, 8) DEFAULT 0,

    created_at TIMESTAMP NOT NULL
        DEFAULT CURRENT_TIMESTAMP
);

A separate pricing table can maintain provider rates:

CREATE TABLE model_pricing (
    id BIGINT GENERATED ALWAYS AS IDENTITY
        PRIMARY KEY,

    provider VARCHAR(50) NOT NULL,
    model VARCHAR(100) NOT NULL,

    input_rate DECIMAL(18, 8) NOT NULL,
    output_rate DECIMAL(18, 8) NOT NULL,
    cached_input_rate DECIMAL(18, 8) NOT NULL,

    currency VARCHAR(10) NOT NULL,
    effective_from TIMESTAMP NOT NULL
);

The effective_from field helps identify which pricing configuration applied to a particular request.

For a production system, also consider storing the provider request identifier, usage-event timestamp, pricing version, and additional token categories.

Step 5: Calculate the Total Cost of an Agent Run

An agent run may generate multiple model requests.

For example:

Request	Input tokens	Output tokens
Repository analysis	12,000	2,000
Implementation planning	8,000	1,500
Code generation	15,000	4,000
Test analysis	10,000	2,500
Final explanation	6,000	1,000

The total run cost is the sum of all billable model requests and any separately charged tools or infrastructure.

A SQL query can calculate the total model cost per run:

SELECT
    run_id,
    SUM(request_cost) AS total_model_cost
FROM agent_usage
GROUP BY run_id
ORDER BY total_model_cost DESC;

This report helps identify which agent runs consume the most model resources.

It also makes it possible to compare the cost of different task types.

For example, repository-wide analysis may cost more than generating a small unit test.

That does not automatically mean the expensive task is inefficient. Its value must be evaluated against the work completed.

Step 6: Track Costs by Developer, Team, and Project

A team-level cost report is more useful than a single account-level usage total.

Consider an engineering organization with three teams:

Backend Engineering.
Frontend Engineering.
Quality Engineering.

Each team may use AI agents differently.

Backend engineers might use agents for debugging and code generation. Frontend engineers may use them for component development. QA engineers may use them for test generation and test-case analysis.

Use SQL to calculate usage by team:

SELECT
    team_id,
    SUM(request_cost) AS total_cost,
    COUNT(DISTINCT run_id) AS total_runs
FROM agent_usage
GROUP BY team_id
ORDER BY total_cost DESC;

For project-level reporting:

SELECT
    project_id,
    SUM(request_cost) AS total_cost,
    SUM(input_tokens) AS input_tokens,
    SUM(output_tokens) AS output_tokens
FROM agent_usage
GROUP BY project_id
ORDER BY total_cost DESC;

These reports help identify:

Projects with increasing AI usage.
Teams with unusually high consumption.
Developers running repeated expensive tasks.
Models generating the largest share of costs.
Tasks that may benefit from better context management.

Do not use individual developer cost rankings without considering task complexity and output quality.

Step 7: Measure Cost Per Completed Task

Total spending alone does not tell you whether an AI agent is providing value.

A team spending $500 on AI agents may complete more useful work than a team spending $200.

The more meaningful metric is often cost per successfully completed task.

For example:

[
\text{Cost per Completed Task} =
\frac{\text{Total Agent Cost}}
{\text{Successfully Completed Tasks}}
]

Suppose a team spends $300 and completes 60 verified development tasks.

[
\frac{300}{60} = $5
]

The average cost is $5 per completed task.

However, define task completion carefully.

A task should not be counted as successful merely because the agent generated code.

A more reliable definition might require:

Required implementation completed.
Relevant tests passed.
Pull request accepted.
No unresolved blocking review findings.

You can also measure cost by task category.

For example:

Task type	Total cost	Completed tasks	Cost per task
Code generation	$120	30	$4.00
Bug investigation	$90	15	$6.00
Test generation	$60	30	$2.00
Pull request review	$30	15	$2.00

These are illustrative values, not industry benchmarks.

The report can help teams compare workflows and identify where additional prompt or tool optimization may be worthwhile.

Step 8: Build a Cost Monitoring Dashboard

A dashboard should provide a clear view of AI usage without overwhelming engineering managers with raw token counts.

Useful dashboard sections include:

Overall Usage

Display:

Total model cost.
Total agent runs.
Total input tokens.
Total output tokens.
Average cost per run.
Cost per completed task.

Team Usage

Show cost distribution across engineering teams.

Project Usage

Identify projects with increasing consumption.

Model Usage

Compare cost by provider and model.

Expensive Runs

List the agent runs with the highest costs.

Usage Trends

Track daily, weekly, and monthly spending.

A simple dashboard layout might look like this:

AI AGENT COST DASHBOARD

Total Monthly Cost       $1,250
Total Agent Runs           850
Average Cost per Run       $1.47
Completed Tasks             620

Team Cost
--------------------------------
Backend Engineering       $600
Frontend Engineering      $400
Quality Engineering      $250

Top Cost Categories
--------------------------------
Code Generation           40%
Repository Analysis       25%
Testing                   20%
Code Review               15%

Highest Cost Projects
--------------------------------
Payment API
Customer Portal
Inventory Service

The values above are sample data for illustrating the dashboard.

For more useful reporting, allow managers to filter by date, team, project, model, and task type.

Step 9: Set Budgets and Usage Alerts

Once usage is visible, teams can establish spending limits and notification thresholds.

For example, an engineering team may define a monthly AI budget of $1,000.

It could create internal alerts at:

50% of the budget.
75% of the budget.
90% of the budget.
100% of the budget.

The tracking system can send notifications when usage crosses a threshold.

Example notification logic:

def check_budget_usage(
    current_cost,
    monthly_budget
):
    usage_percentage = (
        current_cost / monthly_budget
    ) * 100

    if usage_percentage >= 100:
        return "Budget exceeded"

    if usage_percentage >= 90:
        return "Critical usage warning"

    if usage_percentage >= 75:
        return "High usage warning"

    if usage_percentage >= 50:
        return "Budget usage notification"

    return "Usage within expected range"

This example provides basic notification logic.

A production system should also account for delayed provider usage reports, concurrent requests, and requests that have started but have not yet returned final usage data.

Budget Alerts Are Not the Same as Hard Limits

A notification does not automatically prevent additional model requests.

If the organization needs hard spending controls, implement an authorization layer in the agent orchestrator.

For example, the orchestrator can check the remaining budget before starting a new task.

It can then:

Allow the task.
Restrict the maximum number of model calls.
Require approval for expensive models.
Switch to an approved lower-cost model.
Reject new runs when a defined limit is reached.

Be careful when switching models automatically. Different models may produce different results, and critical tasks should not silently receive a lower capability level.

Step 10: Identify and Reduce Unnecessary Agent Costs

Cost tracking becomes valuable when teams use the collected data to improve their workflows.

Common optimization opportunities include:

Reduce Unnecessary Context

Sending an entire repository to a model for a small code change increases input usage.

Use repository search, file filtering, and retrieval to provide only relevant context.

Reuse Stable Instructions

Repeatedly sending large instruction documents can increase input usage.

Use provider-supported caching where appropriate, and keep repository instructions focused.

Select Models Based on Task Complexity

Not every task requires the most expensive model.

A simple formatting task may need less reasoning capability than a complex architectural review.

Define approved model choices based on task requirements and validate the quality of lower-cost alternatives before adopting them.

Prevent Repeated Tool Calls

An agent that repeatedly reads the same files or runs identical commands may waste resources.

Use tool-result caching where safe and avoid unnecessary execution loops.

Limit Unbounded Agent Runs

Set limits for:

Maximum model calls.
Maximum execution time.
Maximum tool retries.
Maximum context size.
Maximum task cost.

These limits help prevent a poorly configured agent from consuming resources indefinitely.

Common Mistakes in AI Agent Cost Tracking

Mistake	Why it causes problems	Better approach
Tracking only final model responses	Earlier model calls are omitted	Record every request
Ignoring cached token categories	Cost calculations may be inaccurate	Record provider-reported usage separately
Using one fixed price for every model	Different models have different rates	Maintain versioned pricing data
Counting only token costs	External tools and infrastructure may also cost money	Track each cost category separately
Failing to associate requests with run IDs	Total task costs become difficult to calculate	Propagate run identifiers
Counting generated code as completed work	Cost-per-task metrics become misleading	Define verified task completion
Ignoring failed agent runs	Failed tasks can still consume resources	Include unsuccessful runs in reports
Relying only on monthly totals	Expensive individual workflows remain hidden	Analyze costs by run, team, and project
Treating alerts as spending limits	Usage can continue after notification	Enforce limits in the orchestrator

Advantages and Disadvantages of AI Agent Cost Tracking

Advantages

Provides visibility into AI spending across teams.
Identifies expensive development workflows.
Helps compare model usage and pricing.
Supports project-level budget planning.
Makes cost-per-task analysis possible.
Helps detect repeated or inefficient agent operations.
Provides historical usage data for capacity planning.
Supports internal budget and approval policies.

Disadvantages

Requires instrumentation across model and tool calls.
Provider usage formats may differ.
Pricing changes require regular updates.
Cost attribution can be difficult when tasks share resources.
Token cost alone does not measure engineering value.
Usage reporting may be delayed or incomplete.
Building and maintaining the tracking platform introduces additional work.

Summary

Tracking AI agent costs across development teams requires visibility into the complete execution lifecycle.

Start by assigning a unique identifier to every agent run and recording usage from each model request. Normalize provider-specific usage data, apply the correct pricing, and store events with developer, team, project, and task information.

Build reports that show total cost, model usage, expensive runs, and cost per successfully completed task.

Most importantly, use the collected information to improve agent workflows. Reduce unnecessary context, prevent repeated tool calls, select models based on task complexity, and enforce appropriate execution budgets.

The objective is not simply to minimize AI spending. It is to understand where the money goes and ensure that agent usage produces measurable engineering value.