How to Track Claude and GPT Token Costs by Developer, Team, and Model

Your AI bill shows how much you spent. It may not explain which developer, team, or workflow generated the cost.

That gap becomes harder to manage when engineers use multiple models, shared credentials, and coding agents that make several requests to complete one task.

To track Claude and GPT spending accurately, you need three connected layers: provider usage and billing data, reliable ownership information, and AI observability that connects requests to the work behind them.

This guide explains how to build that visibility and turn token costs by developer and model into useful budget decisions.

What does tracking AI token costs involve?

Tracking AI token costs means recording token consumption, applying the correct pricing, and attributing the resulting expense to an owner.

A useful system answers three questions:

• Developer: Who initiated the request or owns the automation?
• Team: Which department, project, or cost centre should receive the expense?
• Model: Which exact model handled the request, and what pricing applied?

Keep two cost figures distinct: estimated request cost, calculated from usage and pricing, and provider-reported billed cost, used for financial reconciliation. A detailed estimate should not automatically be presented as an exact invoice amount.

1. Identify where Claude and GPT spending originates

Before building a dashboard, inventory the tools and accounts your organisation uses.

Separate direct API usage, AI subscriptions, usage-based extras, and models accessed through another provider. Record the billing account, payment owner, and available reporting method for each.

Do not assign a token-derived API cost to a subscription invoice unless the billing arrangement actually charges those tokens separately. Otherwise, you can double-count expenditure.

Also distinguish developer activity from production traffic. A service account serving customers should usually be attributed to its application and owning team, rather than the developer who created its key.

Your inventory becomes the checklist for reporting coverage. Any missing account or unmonitored tool is a gap in the total.

2. Start with native provider reporting

Provider reports establish the baseline for token consumption and billed expenditure.

OpenAI’s text-generation Usage API supports grouping by model, project, API key, and user. Those dimensions can help organise GPT usage, provided you understand which identity or credential each record represents.

Anthropic’s Usage API supports breakdowns including API key, workspace, and model, with separate categories for uncached input, cache reads, cache creation, and output. Its Cost API offers workspace and description grouping. Reporting access depends on the product and organisation setup; Claude Enterprise uses a separate analytics route.

For implementation, start by collecting daily usage and cost reports into one reporting dataset. Retain the original provider fields so you can investigate discrepancies later.

Native reports provide a foundation, but they cannot supply business context you never captured. A shared API key identifies a credential; it does not necessarily identify the person behind every request.

3. Make developer and team attribution reliable

Reliable attribution starts before the AI request leaves your application.

For individual development, use separately managed credentials where appropriate. For shared applications and agents, capture the authenticated initiator or accountable owner in your own telemetry.

Maintain an ownership mapping that connects provider identities, credential IDs, projects, and workspaces to internal developer and team IDs.

For example:

Resolve identity through trusted authentication or managed configuration. Avoid letting callers choose arbitrary team labels that determine financial ownership.

Store credential identifiers, never secret API key values. Preserve historical ownership so a developer changing teams does not silently rewrite previous reporting.

You cannot reliably reconstruct individual spending from a shared key alone if no request-level identity was recorded.

4. Use AI observability to explain the spending

AI observability connects usage to requests, sessions, workflows, and operational outcomes.

For cost tracking, design your telemetry to capture:

For Claude Code specifically, OpenTelemetry monitoring exposes token and approximate cost metrics, including model breakdowns. Identity availability varies by authentication method, so verify how users are identified in your deployment. Official billing remains with the provider.

For your own applications, instrument the request path or use a compatible gateway that records authenticated ownership and usage.

Capture all billable activity for accounting. If you sample diagnostic traces, keep the cost ledger complete. Likewise, when an SDK, gateway, and agent all report the same request, deduplicate the records rather than adding them together.

Start with metadata and usage counts. Full prompt and response content is not required for a basic cost dashboard.

5. Calculate token costs using the right categories

A single token total is insufficient for accurate pricing.

Providers distinguish input, output, and cached usage, while applicable rates can also depend on the model and processing mode. Use the pricing for the actual provider and configuration handling the request.

For a text request, the general calculation is:

Estimated token cost = sum of each billable token category × its applicable rate

If rates are quoted per million tokens, divide each category’s count by 1,000,000 before multiplying.

Consider this illustrative example:

These are hypothetical rates, not current prices for a named Claude or GPT model.

Normalise provider fields before calculating costs: ensure categories do not overlap, and do not charge cached tokens twice. Where cache writes have a separate price, record them separately.

Keep non-token charges in additional cost fields. Version your pricing table so historical usage retains the rates applicable when it occurred.

6. Build dashboards for developers, teams, and models

A useful dashboard supports decisions at each level.

Developer reporting should show attributed spending, token categories, model mix, and expensive workflows. Treat spending as context for investigation, rather than a productivity score.

Team reporting should show actual expenditure against budget, trends, project allocation, and unattributed spending. Separate experimentation from production so managers understand what drives changes.

Model reporting should compare spending, latency, and quality on equivalent tasks. Include the complete workflow: a cheaper request can become an expensive task if it needs repeated attempts.

A practical efficiency metric is:

Cost per successful task = total attributable workflow cost ÷ successfully completed tasks

Define success explicitly. For a coding workflow, that might mean a change passes tests and is accepted after review.

7. Add budget alerts and reconcile the totals

Once attribution works, introduce team and project budgets.

An example policy might notify owners at 50%, 80%, and 100% of their monthly allowance. Choose thresholds that fit your organisation, and specify what each notification requires.

Distinguish an alert from enforcement. A hard spending limit needs a control that can block or redirect requests, including a policy for concurrent requests and approved exceptions.

Use anomaly alerts to investigate sudden token growth, repeated agent attempts, or unexpected premium-model usage.

Finally, reconcile your internal totals with provider cost reports and invoices. OpenAI’s Costs API supplies monetary cost records that can support this process.

Check differences such as reporting delays, missing accounts, pricing changes, duplicate records, and non-token charges. Label unresolved differences rather than forcing the numbers to match.

Frequently asked questions

Can I track token costs by developer and model?

Yes, when usage records include a verified developer identity and the model used. Provider reports offer useful dimensions, but shared applications often require additional request-level attribution.

Is AI observability enough to verify my invoice?

Use observability to explain activity and estimate detailed costs. Reconcile those estimates against provider billing records for financial reporting.

Can I combine Claude and GPT spending in one dashboard?

Yes. Collect both providers’ records, normalise token categories and currency units, and apply consistent ownership mappings. Preserve provider-specific pricing details.

What should I implement first?

Start with one team. Inventory its billing sources, capture verified ownership and token usage, calculate model-specific estimates, and reconcile the results before expanding.

Make AI spending accountable

To track Claude and GPT spending effectively, connect each billable activity to an owner, a team, and a model.

That makes it possible to explain rising costs, compare workflows fairly, and set budgets based on evidence. With reliable attribution and AI observability, engineering leaders can see where expenditure supports useful work and where a change to the workflow could improve efficiency.