Research-backed calculator guide
AI Coding Assistant Cost by Repository: A Showback and Chargeback Method
A practical, auditable method to allocate AI coding assistant spend by repository, separating direct usage, seat pools, shared platform costs, and unassigned spend.
Quick answer
To allocate AI coding assistant cost by repository, create one monthly ledger with a row for every usage event or billing line, then join each row to a repository through a trusted identifier. Split the result into four buckets: direct repository usage, shared seat or subscription cost, shared platform overhead, and genuinely unassigned spend. Allocate the first bucket directly. Allocate shared buckets with a written driver, such as active developer-days, token share, session share, or an approved fixed percentage. Keep an unassigned bucket instead of silently forcing weak matches into a repository.
The core calculation is:
Repository showback = direct repository usage + allocated seat pool + allocated shared overhead + approved adjustments.
That number is a management view, not automatically an invoice. Showback reports the cost to the team that owns the repository while the expense remains centralized. Chargeback posts that amount to a cost center or budget. Start with showback, reconcile it to vendor bills, and only charge back after the identity, repository mapping, and shared-cost rules have survived at least one review cycle.
Anthropic’s Claude Code documentation illustrates why a seat price is not enough: usage can be token-metered, per-developer costs vary with model, codebase size, and usage pattern, and the local dollar figure is an estimate rather than an invoice. [1] OpenAI’s cost endpoint similarly returns daily buckets and can group costs by project, line item, or API key, with token and request fields in related usage results. [3] These are useful source fields, but neither vendor’s native view is a complete cross-tool repository ledger.
What “by repository” should mean
A repository is an ownership and work boundary, not a billing meter. A developer can use an assistant while switching between several repositories. A shared agent can run against a monorepo, a service directory, or a pull request. A seat may be purchased for a person but consumed across many codebases. Your allocation method therefore needs to define the unit before it calculates a dollar amount.
Use the repository that the usage event actually touched when the tool records it. If the event has only a user, project, API key, or workspace, resolve the repository from session metadata, branch and pull-request data, an agent job identifier, or a documented time-window join. If several repositories are touched in one session, split only when you have a defensible measure. Token share, request share, changed-file share, or explicit job weights are reasonable candidates; an arbitrary equal split is a last-resort estimate and should be labeled.
Do not confuse repository attribution with value attribution. A repository total tells you where spend was assigned. It does not prove that the assistant caused a faster release, better quality, or higher business value. Pair spend with a consistent output or quality measure, such as merged pull requests, review hours, change failure rate, incident load, or completed tickets. The allocation ledger answers “where did the cost go?” A separate outcome analysis answers “what happened after it was used?”
The four cost buckets
Direct usage is a charge that can be mapped to a repository with high confidence. Examples include a model request tagged with a repository, a coding-agent job whose worktree is known, or a session whose commits and pull request identify one codebase. Keep model, date, user or service account, tokens, requests, and source system on the row so another person can reproduce the amount.
Seat and subscription pools cover a plan purchased for several developers when the invoice does not identify a repository. Allocate this pool using a driver that reflects access or use. Active developer-days work when a seat is available across repositories. Sessions, accepted suggestions, or attributable work hours can work when your data is consistent. If the plan is a flat entitlement and no usage evidence exists, an even split may be transparent, but call it a policy allocation rather than measured consumption.
Shared platform overhead includes an internal gateway, observability pipeline, data ingestion, administration, or a centrally operated agent runner. FinOps describes allocation as a strategy that maps costs to organizational groupings, with separate tagging and shared-cost strategies. It also notes that shared costs can be allocated by fixed, proportional, or proxy-metric methods, or kept centrally budgeted when that produces better decisions. [4] Apply the same discipline here: name the owner, driver, period, and reason for the rule.
Unassigned spend is not a failure to hide. It is the portion you cannot yet map reliably. Keep it visible, investigate the largest causes, and report its percentage of the total. Charging every unknown dollar to the largest repository makes the report look complete while making future comparisons less trustworthy.
A practical repository allocation workflow
- Freeze the accounting period. Use one timezone and one close date. Store the vendor invoice period separately from event timestamps because a billing line and a usage event may close on different days. Record currency and whether the number is a vendor quote, a contract rate, an estimate, or an internal fully loaded cost.
- Collect the raw evidence. Export vendor usage, invoice lines, seat rosters, API keys, service accounts, repository metadata, pull requests, commits, agent jobs, and any gateway or OpenTelemetry events. Anthropic documents per-user and per-model spend reporting and recommends an organization establish a baseline before a wider rollout. [1] Its analytics documentation also distinguishes usage metrics from contribution metrics and notes that contribution attribution depends on a configured GitHub integration and has coverage limitations. [2]
- Normalize the meter. Convert every row to a common schema such as
period,vendor,tool,model,user_or_service,project_or_key,repository,input_tokens,output_tokens,requests,amount_usd,allocation_method, andconfidence. Do not replace the vendor’s billed amount with a token-price reconstruction if the invoice is authoritative. Use the reconstruction as a reconciliation check.
- Resolve identity and repository. Map emails, account IDs, API keys, and service accounts to an owner and team. Then map the event to a repository. Preserve
direct,join,split,proxy, andunassignedas distinct methods. A repository field without a method is not auditable.
- Allocate the pools. Publish the driver before applying it. For example, allocate a $600 seat pool by active developer-days and a $300 shared gateway bill by each repository’s direct usage share. If a repository has no direct usage but legitimately receives a shared service, use the approved proxy rather than dropping it.
- Reconcile and review. The sum of repository totals plus unassigned spend must equal the ledger total for the period, within a stated rounding tolerance. Compare the ledger to vendor invoices. Investigate changes in tool mix, model mix, account mapping, repository splits, and shared-cost drivers before interpreting a spend increase as productivity or waste.
- Run showback first. Give repository owners a preview with the source rows, formulas, and confidence labels. Ask them to correct ownership and repository mapping, not to negotiate away measured usage. After the process is stable, finance can decide whether selected buckets become chargeback.
Worked cost example
Assume a team closes a 30-day month with an AI coding assistant ledger of $1,620 USD. This is an invented planning example, not a vendor quote. It combines three cost pools: $720 of direct usage, $600 of shared seat fees, and $300 of shared observability and gateway overhead. The organization has three repositories and chooses active developer-days as the seat driver and direct-usage share as the overhead driver.
| Repository | Direct usage input | Active developer-days | Seat allocation | Shared overhead allocation | Repository showback | Illustrative output denominator |
|---|---|---|---|---|---|---|
| payments-api | $420 | 90 of 150 | $360 | $175 | $955 | 24 merged PRs → $39.79/PR |
| product-catalog | $180 | 45 of 150 | $180 | $75 | $435 | 10 merged PRs → $43.50/PR |
| internal-tools | $120 | 15 of 150 | $60 | $50 | $230 | 6 merged PRs → $38.33/PR |
| Total | $720 | 150 | $600 | $300 | $1,620 | 40 merged PRs |
The seat calculation is repository developer-days ÷ 150 × $600. For payments-api, that is 90 ÷ 150 × $600 = $360. The shared overhead calculation is repository direct usage ÷ $720 × $300. For payments-api, that is 420 ÷ 720 × $300 = $175. The repository showback is then $420 + $360 + $175 = $955.
The per-PR figures are descriptive unit costs, not ROI. A repository with fewer but riskier changes may reasonably cost more per merged PR. If the month contained $40 of unassigned usage, the denominator would be $1,660 and the three repository totals would need to be reduced or the unassigned row shown separately, depending on the policy. Never omit the $40 simply to make the reconciliation appear clean.
How to handle difficult attribution cases
A user works in multiple repositories. Prefer session or job metadata. If none exists, use a documented split based on changed files, commits, or active work time. Record the split percentages on the allocation row and preserve the unsplit source amount.
A monorepo contains several products. Choose one reporting level and keep it stable. If the billing system sees only the monorepo, report the monorepo as the repository. Allocate to subprojects only when a repeatable path, package, team, or job label supports it. False precision is worse than a clear monorepo total.
A shared service account runs agents. Assign an accountable owner and use job, worktree, branch, ticket, or repository metadata. If the account truly serves several repositories, place the cost in a shared pool and allocate with a proxy that owners can understand.
The assistant plan includes unused capacity. The invoice may belong to a seat or workspace even when measured token usage is low. Keep the seat cost in the pool and report both entitlement allocation and observed usage. This distinguishes “paid for access” from “consumed metered capacity.”
The vendor reports an estimate. Keep an estimate label beside the amount. Anthropic explicitly says local session totals are estimates and that authoritative billing is found in the console. [1] For OpenAI, use the cost response’s monetary amount and currency when available, then retain project, API-key, line-item, time-bucket, token, and request dimensions for reconciliation. [3]
Showback, chargeback, and governance controls
A good showback report includes the repository owner, period, vendor and tool, direct amount, pool allocations, allocation method, confidence, unassigned amount, and reconciliation status. It should let an engineer trace a total back to source rows without exposing sensitive prompt content. Keep the minimum metadata needed for attribution and apply access controls to code, prompts, and user identifiers.
Use three gates before chargeback. First, completeness: all major invoices and subscription lines are present. Second, traceability: repository totals can be traced to raw usage or a named allocation driver. Third, stability: the rules do not change merely because one repository had an unusual month. FinOps calls for allocation compliance and documentation of shared-cost apportionment. [4] Those controls are as important for AI coding spend as they are for cloud spend.
OpenTelemetry can help when several assistant or gateway products must feed one ledger. Its GenAI material has moved to a dedicated semantic-conventions repository, so treat the older page as a pointer rather than as a current schema specification. [5] In practice, define your own stable minimum fields and version the mapping. A telemetry event is evidence of activity; the invoice remains the authority for billed currency.
For a broader project budget that includes engineering effort, use the AI Agent Cost Calculator or the AI agent development cost estimator. For token-level assumptions, see the AI token cost calculator. A model pricing comparison can help document why model mix changed, but it should not replace the billed-cost reconciliation.
Run your scenario
Turn this framework into an editable estimate.
Use dated, source-linked assumptions and see cost per request, successful task and month.
FAQ
Is repository-level AI coding cost the same as a vendor invoice?
No. Vendors commonly bill seats, tokens, credits, requests, or workspace usage, while a repository view is an internal allocation. Reconcile the repository ledger to the invoice, label estimates, and show any unassigned amount. The allocated total should explain the invoice, not pretend the vendor billed each repository directly.
What is the fairest way to allocate a shared coding-assistant seat fee?
Use a driver that matches the entitlement. Active developer-days are a defensible default when people work across repositories. If reliable session or accepted-change data exists, it may better reflect use. If no usage data exists, an equal split can be acceptable as a stated policy allocation. Revisit the driver periodically and do not mix measured usage with an undisclosed guess.
Can I allocate every AI coding request to a repository?
Only when the source data supports it. A request with no repository, project, worktree, or workflow identifier should go to an unassigned bucket or a documented shared pool. If you split it, preserve the source row, record the percentages and basis, and label the result as estimated. A visible unknown is more useful than a falsely precise repository total.
Should chargeback use token cost or total ownership cost?
Decide what question the chargeback answers. Token or metered cost is useful for consumption accountability. Total ownership cost can add seats, gateway operations, observability, administration, and other shared services. If you use total ownership cost, publish the buckets separately so repository owners can see what they control and what they do not.
How often should repository allocations be reviewed?
Close and reconcile monthly, with in-period alerts for unusual usage or projected overages. Review mappings when teams reorganize, repositories are archived, service accounts change, or a vendor changes its billing meter. A monthly report explains the past month; alerts give owners time to investigate before the invoice closes.
Does a higher repository allocation mean the assistant is less efficient there?
No. Spend is an input, not a verdict. Compare like-for-like repositories and add delivery and quality measures such as review time, rework, incidents, deployment frequency, or merged changes. A high-spend repository may be a critical system undergoing a large migration. A low-spend repository may have little eligible work. Allocation makes the question measurable; it does not answer the value question by itself.
Primary sources checked
Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.