How to track OpenAI and Anthropic API costs by project

1. Keep billing and usage in separate ledgers

A reliable AI cost review needs two views. The billing view records monetary amounts reported by the provider for a defined period. The usage view records the activity behind them: requests, tokens, models and the project or workspace where available. These views complement each other, but they should not be silently substituted for one another.

OpenAI and Anthropic document organization-level usage and cost reporting interfaces. Their dimensions and access requirements differ, so verify the current documentation linked below before building an integration. Do not assume that every billing amount can be attributed to every usage dimension.

Store the source, date range and currency beside each amount. Keep estimated costs in a separate column with the pricing assumptions and date used. If only usage is available, label the result as computed; do not present it as a reconciled invoice amount.

2. Establish project ownership before analyzing models

Start with a mapping that a teammate can maintain: provider organization, project or workspace identifier, internal product, environment and owner. A model name tells you which technology was used, but rarely tells you which team should investigate a change.

Keep unknown ownership visible. A shared project used by several products is a reporting limitation, not a reason to invent a precise split. Choose a documented allocation method or improve project separation for future traffic. Never include API secrets in a reporting export; project identifiers and owner labels are enough for this review.

• Map each reporting project or workspace to a product and an owner.
• Separate development and production where your account structure supports it.
• Identify shared projects and explicitly unallocated cost.
• Review the mapping when a new product or team starts using an API.

3. Explain a cost change with a small set of questions

When the bill rises, compare equivalent periods for the same project. Then ask whether request volume increased, inputs or outputs became longer, the model mix changed, or retries became more frequent. Also check whether background jobs or evaluation runs changed. A project can become more expensive even when the user-facing feature appears unchanged.

Separate an operational issue from a product decision. Retrying a failed request repeatedly deserves a different response from intentionally enabling a more capable model. Assign an owner and record the change you intend to make before changing provider settings. Recheck quality, failure rate and latency alongside cost.

4. Measure a successful outcome, not only tokens

Choose a business unit that describes value: a completed support resolution, an accepted document extraction or a successful workflow. Define success explicitly. Counting all requests as useful work can make an inefficient retry loop look productive.

The numerator and denominator must cover the same period and product. If your billing data is daily and outcomes are hourly, aggregate outcomes to the billing period before calculating the ratio. When there are no successful outcomes, show the ratio as unavailable and investigate; do not display zero cost per outcome.

5. Turn the review into an operating routine

Use a weekly review to examine the largest changes, unallocated spend and one concrete improvement per owner. Keep separate alerts for budget consumption and unusual behavior: being inside a monthly budget does not mean a new retry loop is acceptable.

Maintain a short experiment log with the starting cost, chosen change, quality criteria, owner and review date. Test changes such as shorter context or a different model against representative tasks before wider rollout. Retain only improvements that meet the required outcome quality. The objective is an efficient product, not merely the lowest token count.