Introduction
AI agents are becoming part of everyday software development.
A developer can ask an agent to investigate an issue, modify several files, run tests, inspect a repository, or prepare a pull request. In a larger engineering organization, those workflows can involve multiple AI models, agent services, repositories, and teams.
That creates a new accounting problem.
Traditional software cost tracking usually looks something like this:
Cloud Account
|
+---- Compute
+---- Storage
+---- Database
+---- Network
AI development introduces another layer:
Engineering Team
|
+---- AI Assistant
|
+---- Coding Agent
|
+---- Third-Party Model
|
+---- Agent Tool
|
+---- Repository
Without attribution, an organization may know its total AI spending but have little idea which teams, repositories, or workflows are responsible for it.
The solution is AI agent cost attribution.
Instead of asking only:
How much are we spending on AI?
engineering teams should also ask:
Who is using it, where is it being used, which workflows consume the most resources, and what engineering value is produced?
This article presents a practical approach to tracking third-party AI agent usage and allocating the associated costs across GitHub-based development workflows.
Why AI Cost Attribution Is Different
Traditional cloud billing usually has relatively clear ownership.
For example:
Database
|
+---- Production
+---- Staging
AI usage can be much more dynamic.
A single agent task might involve:
Developer
|
v
GitHub Repository
|
v
Agent
|
+---- Model A
|
+---- Model B
|
+---- Tool Calls
|
+---- Repository Operations
|
+---- Test Execution
The cost may therefore cross multiple services.
If everything is charged to one organization-level account, finance may see a single number:
AI Development Cost = $35,000/month
But engineering needs more information.
Platform Team $8,000
Payments Team $7,200
Commerce Team $6,100
Internal Tools $3,500
Other $10,200
That is where attribution becomes useful.
Start With a Cost Attribution Model
Before collecting data, define the dimensions by which costs should be assigned.
A practical model includes:
Organization
|
v
Team
|
v
Repository
|
v
Developer
|
v
Agent Workflow
|
v
Model / Provider
Not every organization needs all six dimensions.
For many teams, this is sufficient:
Team
Repository
Agent
Provider
Month
The important part is consistency.
Define the Cost Unit
AI costs should be represented using a standard unit.
Depending on the provider, this could include:
Tokens
Requests
Agent Sessions
Compute Time
Tool Calls
Subscription Seats
API Credits
For model-based APIs, a simplified cost model is:
Total Cost =
Input Tokens × Input Price
+
Output Tokens × Output Price
If an agent uses multiple models:
Total Agent Cost =
Model A Cost
+
Model B Cost
+
Tool Cost
+
Infrastructure Cost
The actual billing structure depends on the provider and product, so the accounting system should preserve raw usage data before calculating normalized costs.
Add Ownership Metadata
Cost attribution becomes much easier when every AI workflow carries ownership metadata.
For example:
{
"team": "payments",
"repository": "payments-api",
"environment": "development",
"agent": "coding-agent",
"provider": "third-party",
"costCenter": "ENG-PAYMENTS"
}
The exact implementation will depend on the AI platform and GitHub integration being used.
The principle is simple:
Usage without ownership metadata becomes difficult to allocate later.
Use Repository Ownership
GitHub repositories are often the most practical attribution boundary.
For example:
payments-api
|
+---- Payments Team
customer-api
|
+---- Customer Team
internal-tools
|
+---- Developer Productivity
If an agent performs 500 tasks against payments-api, those tasks can initially be attributed to the Payments team.
This is often more reliable than attempting to assign every request directly to an individual developer.
Track Team-Level Usage
A simple monthly table might look like:
| Team | Agent Tasks | AI Cost | Cost/Task |
|---|
| Payments | 1,800 | $7,200 | $4.00 |
| Commerce | 1,450 | $5,800 | $4.00 |
| Platform | 1,100 | $4,950 | $4.50 |
| Internal Tools | 650 | $1,950 | $3.00 |
This immediately gives engineering leaders a useful view.
But cost per task should not be treated as a productivity score.
Some tasks are inherently more complex than others.
Track Repository-Level Costs
Repository attribution can reveal expensive workloads.
For example:
Repository Monthly Cost
------------------------------------
payments-api $7,200
customer-api $4,800
data-platform $3,900
internal-tools $1,100
This allows teams to investigate why a particular repository consumes more AI resources.
Possible explanations include:
Large repository size
Long agent sessions
Complex tasks
Repeated failures
Large context windows
Multiple tool calls
Extensive test execution
The metric becomes useful when paired with diagnostic information.
Track Agent Sessions
An agent session is often a better unit of analysis than an individual request.
Consider:
Task
|
+---- Request 1
|
+---- Request 2
|
+---- Tool Call
|
+---- Repository Search
|
+---- Test Run
|
+---- Request 3
|
+---- Final Change
If each interaction is counted independently, the organization may struggle to understand the actual cost of completing one task.
A session identifier can connect related operations:
session_id = AGT-2026-001248
Then all associated activity can be aggregated.
Create a Usage Event
A normalized event might look like:
{
"timestamp": "2026-08-21T10:30:00Z",
"sessionId": "AGT-001248",
"team": "payments",
"repository": "payments-api",
"agent": "coding-agent",
"provider": "third-party",
"model": "model-x",
"inputTokens": 12500,
"outputTokens": 4800,
"toolCalls": 17
}
The event does not need to expose sensitive prompt content.
In many organizations, metadata is sufficient for cost accounting.
Keep Usage and Cost Separate
This is an important architectural decision.
Do not store only:
AI Cost = $5.23
Store the underlying usage:
Input tokens
Output tokens
Requests
Model
Provider
Session
Repository
Team
Timestamp
Then calculate cost from the applicable pricing data.
This makes the system adaptable when pricing changes.
Usage Data
|
v
Pricing Rules
|
v
Calculated Cost
Create a Pricing Table
For example:
| Provider | Model | Input Unit | Output Unit |
|---|
| Provider A | Model X | $X | $Y |
| Provider A | Model Y | $X | $Y |
| Provider B | Model Z | $X | $Y |
The actual prices should come from the applicable provider billing information.
The accounting pipeline can then calculate:
Cost =
(Input Units × Input Rate)
+
(Output Units × Output Rate)
This also allows historical recalculation when billing rules change.
Handle Fixed Subscription Costs
Not every AI cost is usage-based.
Some products have:
Per-user subscription
Monthly platform fee
Enterprise contract
Usage allowance
Overage
Suppose an organization pays:
Platform Subscription = $20,000/month
and has:
400 active developers
A simple allocation might be:
Cost per active user = $50
Then:
Payments Team
80 active users
= $4,000 allocated cost
This is not necessarily the provider's actual accounting method.
It is an internal cost-allocation method.
The distinction should be documented clearly.
Combine Fixed and Variable Costs
A practical model is:
Total Team AI Cost
=
Allocated Subscription Cost
+
Variable Agent Usage
+
Additional Infrastructure Cost
For example:
Payments
Subscription Allocation $4,000
Agent Usage $2,700
Tooling/Infrastructure $500
------------------------------------
Total $7,200
This is more useful than reporting only API consumption.
Track Cost by Workflow
Not all agent activity provides the same value.
Separate workflows such as:
Issue investigation
Feature implementation
Bug fixing
Test generation
Code review
Documentation
Refactoring
Migration
Then calculate:
Workflow
|
+---- Usage
+---- Cost
+---- Successful PRs
+---- Engineering Outcome
For example:
| Workflow | Cost | Merged PRs |
|---|
| Bug fixing | $2,400 | 180 |
| Test generation | $1,600 | 260 |
| Refactoring | $3,100 | 95 |
| Documentation | $600 | 180 |
Now the organization can investigate where agent usage is producing useful outcomes.
Track Cost Per Successful Outcome
A stronger metric than cost per request is:
Cost per successful outcome
For example:
Agent Cost = $5,000
Merged agent-assisted PRs = 500
Then:
Cost per merged PR = $10
Again, this does not prove that the AI agent alone caused the successful PR.
Developers still perform review, testing, debugging, and integration.
It is a workflow metric, not a causal productivity measurement.
Connect AI Cost With GitHub Events
GitHub provides useful engineering events that can be associated with AI workflows.
Conceptually:
Agent Session
|
v
Repository
|
v
Branch
|
v
Pull Request
|
+---- Reviews
|
+---- Tests
|
+---- Merge
This allows organizations to build a workflow-level cost model.
For example:
Session AGT-001248
|
v
payments-api
|
v
PR #1824
|
v
Merged
The system can then associate the session's cost with the resulting engineering workflow.
Do Not Attribute All PR Costs to AI
This is a common mistake.
Suppose an agent creates a pull request that costs $12 in model usage.
The real engineering cost also includes:
Developer review
Testing
CI
Security scanning
Reviewer time
Deployment
Therefore:
AI Cost != Total Development Cost
Instead, maintain separate categories:
AI Cost
Developer Cost
CI Cost
Infrastructure Cost
Then combine them when building a broader engineering economics model.
Track Failed Agent Sessions
Failed sessions are especially valuable for optimization.
For example:
1,000 agent sessions
750 successful
150 partially successful
100 failed
The 100 failed sessions deserve investigation.
Potential causes include:
Poor task definition
Repository complexity
Tool failures
Authentication problems
Test failures
Model limitations
Excessive context
Incorrect assumptions
Calculate:
Failure Rate =
Failed Sessions / Total Sessions
Then compare failure rate across teams and repositories.
Track Retry Cost
Agent retries can become expensive.
Consider:
Initial attempt $1.20
Retry 1 $1.40
Retry 2 $1.80
Retry 3 $2.10
Total:
$6.50
The original task may have looked inexpensive, but repeated failures multiplied the cost.
Track:
Average retries/session
Cost of retries
Failure rate
Successful completion rate
This can identify workflows that need better prompting, repository context, tooling, or model selection.
Identify High-Cost Repositories
Create a simple ranking:
Repository Monthly Cost
------------------------------------
payments-api $8,200
data-platform $6,900
customer-api $4,300
legacy-service $3,800
internal-tools $1,100
Then add usage:
Repository Sessions Cost
-------------------------------------
payments-api 1,700 $8,200
data-platform 1,100 $6,900
customer-api 900 $4,300
If data-platform has fewer sessions but substantially higher cost per session, it deserves investigation.
Calculate Cost Per Agent Session
A simple metric:
Cost per Session =
Total Agent Cost / Number of Sessions
For example:
Total Cost = $20,000
Sessions = 5,000
Cost/Session = $4
Track the median as well as the average.
A few extremely expensive sessions can distort the average.
Average: $4.00
Median: $2.20
P95: $11.80
The P95 number is particularly useful for identifying expensive outliers.
Build an Attribution Pipeline
A practical architecture might look like:
GitHub Events
|
+------------------+
| |
v v
Agent Usage Repository Data
| |
+--------+---------+
|
v
Normalization
|
v
Pricing Engine
|
v
Cost Attribution
|
+-------+-------+
| | |
v v v
Team Repo Workflow
|
v
Dashboard
This architecture separates data collection from cost calculation.
Store Raw Events
A simplified database table might be:
CREATE TABLE ai_usage_events (
id UUID PRIMARY KEY,
session_id TEXT NOT NULL,
team TEXT,
repository TEXT,
agent TEXT,
provider TEXT,
model TEXT,
input_tokens BIGINT,
output_tokens BIGINT,
tool_calls INT,
occurred_at TIMESTAMP NOT NULL
);
Then calculate costs separately.
This makes the system easier to audit.
Add a Cost Ledger
A calculated cost table could contain:
CREATE TABLE ai_cost_ledger (
id UUID PRIMARY KEY,
session_id TEXT NOT NULL,
team TEXT,
repository TEXT,
workflow TEXT,
provider TEXT,
model TEXT,
usage_cost DECIMAL(18,6),
allocated_fixed_cost DECIMAL(18,6),
total_cost DECIMAL(18,6),
calculated_at TIMESTAMP NOT NULL
);
The separation between raw usage and calculated cost is important for financial reconciliation.
Create a Monthly Cost Report
A useful monthly report could look like:
AI Engineering Cost Report
August 2026
Total AI Cost $35,200
Teams
Payments $8,200
Platform $7,100
Commerce $6,400
Data $5,700
Other $7,800
Agent Sessions 8,450
Successful Sessions 6,910
Failure Rate 18.2%
Average Cost/Session $4.17
Median Cost/Session $2.35
P95 Cost/Session $12.10
This provides both financial and engineering context.
Build Cost Anomaly Detection
Unexpected usage should trigger investigation.
For example:
Normal daily cost:
$900 - $1,200
Today's cost:
$4,800
Possible causes:
Runaway agent loop
Repeated retries
Large repository indexing
Incorrect workflow
Provider configuration change
Unexpected automation
A simple threshold can detect obvious anomalies:
if daily_cost > 2 × seven_day_average:
investigate()
More sophisticated systems can use statistical anomaly detection.
Protect Developer Privacy
Cost attribution should not become surveillance.
Avoid collecting unnecessary information such as:
Full prompts
Private conversations
Unnecessary source-code contents
Personal behavioral data
For cost accounting, metadata is often enough:
Team
Repository
Workflow
Model
Usage
Cost
Timestamp
Individual developer attribution should have a clear operational purpose and appropriate access controls.
Avoid Creating the Wrong Incentives
Suppose engineering leaders tell teams:
Reduce AI cost by 30%.
A team might simply stop using useful agent workflows.
That lowers cost but may also reduce engineering productivity.
A better objective is:
Optimize:
Cost
+
Quality
+
Speed
+
Developer Experience
Think in terms of value rather than raw consumption.
Use Cost Efficiency Metrics
A more balanced metric is:
AI Cost Efficiency =
Engineering Outcome / AI Cost
The "engineering outcome" could be defined using organizationally meaningful measures such as:
Successful PRs
Completed issues
Validated test changes
Reduced cycle time
The definition should be consistent within the organization.
Compare Models Carefully
Different models may have different costs and capabilities.
Suppose:
Model A
Average cost/session = $2.10
Success rate = 72%
Model B
Average cost/session = $3.80
Success rate = 88%
Model B costs more.
But if the workflow requires fewer retries and produces more successful changes, its effective cost may be competitive.
A useful metric is:
Cost per successful session
=
Total Cost / Successful Sessions
For Model A:
$2.10 / 0.72 = $2.92
For Model B:
$3.80 / 0.88 = $4.32
The cheaper model still wins under this simplified metric.
However, if Model B handles substantially more complex tasks, additional outcome measures may change the conclusion.
Build a FinOps-Style Review
AI spending can benefit from a regular review process similar to cloud FinOps.
Monthly review:
1. Total AI spending
2. Cost by team
3. Cost by repository
4. Cost by model
5. Cost by workflow
6. Cost anomalies
7. Failed sessions
8. Cost per successful outcome
9. Engineering impact
10. Optimization opportunities
This prevents AI spending from becoming a black box.
Best Practices
Keep Raw Usage Data
Never store only the final cost.
Use Stable Attribution Dimensions
Team, repository, workflow, provider, and model are good starting points.
Separate Fixed and Variable Costs
Subscription allocation and usage charges are different cost types.
Track Failed Sessions
Failure and retry behavior can explain unexpected spending.
Measure Outcomes
Cost without engineering context is incomplete.
Protect Privacy
Collect only the metadata needed for attribution.
Review Outliers
A small number of expensive sessions can materially affect total spending.
Avoid Individual Leaderboards
Cost data should improve systems, not create pressure to minimize useful AI usage.
Advantages and Disadvantages
Advantages
Makes AI spending visible.
Provides team and repository ownership.
Identifies expensive workflows.
Helps detect runaway usage.
Enables model cost comparisons.
Supports engineering FinOps practices.
Connects AI spending with development outcomes.
Disadvantages
Usage data can be difficult to normalize across providers.
Pricing models change over time.
Attribution can become inaccurate without good metadata.
Agent workflows may span multiple repositories and teams.
Cost does not directly equal business value.
Individual-level attribution introduces privacy and governance concerns.
Final Thoughts
AI agents introduce a new category of engineering infrastructure cost, but the answer is not simply to create another billing dashboard.
A useful cost attribution system connects usage, ownership, workflow, and outcome.
Start with repository and team ownership. Capture raw agent usage events. Preserve model and provider information. Separate fixed subscription costs from variable usage costs. Track sessions, failures, retries, and successful outcomes. Then connect those measurements with GitHub development activity.
The most useful question is not:
Which team spent the most money on AI?
It is:
Which AI workflows consume resources, who owns them, and are those workflows producing enough engineering value to justify the cost?
That shift—from consumption tracking to engineering economics—is what turns AI agent cost data into something engineering and finance teams can actually use.