To track AI API costs per feature or team, give each feature its own OpenAI project (or Anthropic workspace, or Google Cloud project) and each deployment its own API key, then map every project and key to a feature and an owner. The provider's cost data, grouped by project and key, then shows what each feature spent, and it adds up to your bill. Cost per customer takes more: your code has to log token counts on every request with a customer ID, and you estimate the dollars from list prices.
Three ways to split AI API costs
1. Separate projects and API keys for each feature
OpenAI reports cost and usage grouped by project, API key and model, in the usage dashboard and through the Costs and Usage APIs. Grouping by API key arrived on August 4, 2026. If every feature has its own project and every deployment its own key, allocation is a lookup: this project is the support assistant, owned by this person.
It needs no code changes, and because it uses OpenAI's own billed figures, the lines add up to what you pay. It can't split a key that two features share, and it can't see your customers. The guide to organizing OpenAI projects and keys covers the layout that makes this work.
Separate keys also make problems easier to trace. On our own team, before Braid existed, a bug kept calling an OpenAI endpoint for almost two weeks. Daily spend went from about $2 to more than $90, and it had cost $1,051.96 by the time it was stopped. Working out which project, key and model it came from took real effort.
2. Log tokens per request with your own tags
Every API response reports the tokens it used. Your application can record them on each request alongside its own context, such as feature, customer or workflow step, and multiply by list prices. A minimal version in Python, with log_usage standing in for wherever you store events:
from openai import OpenAI
client = OpenAI()
# Example list prices per 1M tokens for gpt-6.1-terra, as of November 2026.
# Check https://developers.openai.com/api/docs/pricing before relying on them.
PRICE = {"input": 1.00, "cached": 0.05, "output": 5.00}
def ask(prompt, feature, customer_id):
response = client.responses.create(model="gpt-6.1-terra", input=prompt)
u = response.usage
cached = u.input_tokens_details.cached_tokens
estimate = (
(u.input_tokens - cached) * PRICE["input"]
+ cached * PRICE["cached"]
+ u.output_tokens * PRICE["output"] # includes reasoning tokens
) / 1_000_000
log_usage(feature=feature, customer_id=customer_id, model=response.model,
input_tokens=u.input_tokens, cached_tokens=cached,
output_tokens=u.output_tokens, estimated_usd=estimate)
return response.output_textThis is the only method that can tell you what customer X costs. Its weakness is accuracy against the bill. The sketch above ignores cache-write charges on newer models, the 50% Batch discount, Fast mode's premium, the higher rate for prompts over 272K tokens and the 10% regional processing surcharge on newer models. Tools are billed as their own line items, which token counts miss entirely. Treat request-level figures as estimates and compare their monthly total with OpenAI's cost data.
3. Route calls through a gateway
An LLM gateway or proxy sits between your code and the provider and attributes each call to a virtual key, team or metadata tag. Some can enforce budgets per team. You get request-level detail across providers with less application code, at the price of a new service in the path of every request, and its cost figures are estimates too. The guide to tracking usage across providers covers gateways alongside Anthropic and Gemini's own reporting.
How the three methods compare
| Method | Splits by | Setup | Matches the bill |
|---|---|---|---|
| Projects and keys | Feature, deployment, environment | Project and key changes, plus a mapping | Yes, it's the provider's cost data |
| Request logging | Anything you tag, including customer | Code in every call path, plus a price table | Estimated; check monthly |
| Gateway | Virtual key, team, tag | A new service in the request path | Estimated; check monthly |
We'd start almost every company on projects and keys, and add request logging only where a specific question needs it, such as pricing a plan per customer or finding which tenant drives a spike.
How to set up cost tracking per feature
- Export last month's costs grouped by project and API key. The walkthrough on seeing OpenAI costs by project, key and model shows where.
- Name the feature each line pays for, in the words your company already uses: "Support assistant", not
proj_8fA2…. - Write down one owner per feature, the person who would know whether a change is expected, and the team they belong to. Team is a column in the mapping, so a reorganization changes one cell rather than your OpenAI setup.
- If one key serves two features, create a key for each and move traffic over before revoking the old one.
- Put anything you can't place on an Unmapped line, and give someone the job of shrinking it.
- Share the table on a schedule. A weekly spend report works well, with spend by feature, what changed and who should look.
What to do with shared and unmapped costs
Some spend doesn't belong to one feature. A shared service, such as an embeddings index several features read from, can stay as its own line with its own owner, or be split by a ratio everyone agrees on, such as each feature's share of requests. Pick one and write it down next to the mapping.
Test runs, evaluations and prototypes should get their own project, owned by the team that runs them, so they don't inflate production lines. Anything you still can't place goes on the Unmapped line, which should be visible in every report. If it grows from week to week, new keys are being created without anyone updating the mapping.
Avoid splitting by headcount or seats. It's easy to compute and says nothing about who drives the spend.
Common questions
How do I track OpenAI API cost per customer?
Log token counts on each request with the customer ID and estimate the cost from list prices, as in the example above. OpenAI's cost data has no idea who your customers are. For a few large customers with dedicated deployments, a key per customer also works, and that cost comes straight from OpenAI.
Can I tag OpenAI requests for cost reporting?
Not in a way that reaches OpenAI's cost data. The Usage and Costs APIs group by project, user, API key, model and a few other fields, but not by anything you attach to a request. Per-request tags have to live in your own logs or a gateway.
Should each team get its own OpenAI project?
Usually one project per feature works better. Teams own several features and get reorganized more often than features change, so keep team as an attribute of each feature in your mapping.
What's the difference between showback and chargeback?
Showback means showing each team what its features spent. Chargeback means moving that cost into the team's budget. Start with showback until the numbers are trusted, since chargeback turns every mapping decision into a budget negotiation.
Where Braid fits
Braid uses the first method for OpenAI. It reads cost and usage by project, API key and model with a read-only Admin API key, and keeps the mapping from projects and keys to the features your company names (Braid calls them Implementations), each with an owner, a team and a monthly budget. Spend it can't place shows as unmapped, and every Monday it emails a report of spend by Implementation.
It works at project, key and model level, so it doesn't track cost per request or per customer. The beta supports OpenAI API accounts today, with more provider connections planned.