How to attribute AI costs to teams when there is no team field

This guide shows how to set it up, and the naming rules that make it work.

Why there is no team field

When you look at AI usage data, you'll find the model, the number of tokens, the cost and the time. You won't find a team. Not in OpenAI's data, not in Anthropic's, not on your Amazon Bedrock bill, and not in the gateways most teams use.

That's because the AI provider doesn't know how your company is organised. It only knows which credential sent the request. So if you want to know which team spent the money, the answer has to come from the credential, or from something you attach to the request.

What you can use instead

There are three things you can use to show who spent what.

API keys. Every request is sent with a key. If each team has its own key, the key tells you the team. This is the simplest option and it works almost everywhere.

Tags on requests. Some gateways let you attach extra information to each request, like a team name, a feature or a customer. This gives you more detail than a key, because one key can carry many different tags.

Cloud accounts and IAM identities. If your engineers call Amazon Bedrock or Microsoft Foundry directly, there are no keys to name. Instead you separate teams by AWS account or by IAM identity. We explain the options in Why your Amazon Bedrock bill has token counts but no owner →

Most companies end up using keys for teams, and tags for extra detail.

Step 1: Decide what you want to see

Before you create or rename anything, decide which views you'll need. The most common ones are:

• Team, for budgets and showback
• Service or product, for cost per feature
• Environment, so test spending doesn't hide inside production
• Process, for background jobs and agents that run on their own

You don't need all four. But it's much easier to decide now than to rename two hundred keys later.

Step 2: Give every team its own key

This is the most important step. If three teams share one key, no tool can ever separate their costs, because the data simply isn't there.

Start with one key per team. If you want more detail, go further and give each service, or each background process, its own key. For example, a job that summarises support tickets every night should have its own key, so you can see exactly what that one job costs each month.

Background jobs and AI agents are worth special attention. They run on their own, often around the clock, and they're often the biggest spenders. They're also the ones most likely to be using a shared key someone created months ago.

Step 3: Name keys with a pattern

A key name is only useful if everyone follows the same pattern. A simple one that works well:

team-service-environment

For example:

payments-checkout-prodpayments-checkout-stagingsupport-ticket-summary-proddata-nightly-report-prod

Four rules make it hold up over time:

Use team names, not people's names. People change teams and leave companies. A key called anna-test stops meaning anything the day Anna moves.

Don't put dates in key names. A key called q3-2026 is confusing by October.

Use lowercase and hyphens only. Some tools treat Payments and payments as two different things.

Use the same pattern in every gateway. If one gateway says payments and another says pay-team, you'll have two teams in your reports where you meant one.

Step 4: Add tags for more detail

Keys tell you who. Tags can tell you what for.

If your gateway supports tags or custom metadata on requests, use them for the things a key can't show, like which feature made the request, which customer it was for, or which experiment it belonged to. One key can then carry many different tags, so you don't need a new key for every small case.

Keep the tag names consistent too. The same rules apply: plain names, lowercase, one agreed spelling.

Step 5: Stop sharing keys

Once the new keys exist, retire the shared ones. A single shared key left running will keep putting spending into one big bucket that nobody can explain.

Check who still uses each old key before you switch it off. It's usually one forgotten script or scheduled job.

What each gateway lets you group by

Gateways record different information. This is what Glassity can read from each one:

Every row also carries the key id, key name, model and provider.

Notice that no field is shared by all of them. LiteLLM has a team id, Helicone has custom properties, OpenRouter has only the key. That's why the key naming pattern matters so much. It's the one thing that works the same way everywhere.

Common mistakes

One key for the whole company. The most common mistake, and it makes attribution impossible.

Keys named after people. They stop making sense when people move.

Test and production on the same key. Test spending then looks like production cost.

Different names in different gateways. One team shows up as two.

Starting after the spending. Keys and tags only count from the day you set them up. You can't go back and decide which team made a request last March.

Forgetting agents and scheduled jobs. They spend quietly and continuously, and they're often on an old shared key.

How Glassity uses this

Glassity reads your AI usage from the gateway or cloud AI service you already use. Every row carries the key id, key name, model and provider, plus the gateway's own fields from the table above. You can then group AI costs by any of them, and see them next to your cloud costs.

Because there's no team field shared across gateways, Glassity groups by whatever you've named consistently. If your keys follow a pattern like team-service-environment, you get one view of each team across every gateway. If they don't, you'll see exactly which keys need renaming.

For Amazon Bedrock and Microsoft Foundry, Glassity shows costs by account, region and model, since those services don't carry keys.

Further reading

• Why your Amazon Bedrock bill has token counts but no owner →
• What is AI token economics? →