Tags are key-value pairs attached to a usage event.
Tags hold context the caller controls: the project, the ticket, the environment, or any other dimension useful for cost allocation.
The gateway captures tags from request headers.
You can set a tag by sending a header named ai-cost- followed by the tag key.
For example, to set the project tag to atlas, send the header ai-cost-project: atlas.
The ai-cost- headers follow these rules:
- Key: Lowercase ASCII letters, digits,
., _, and -, between 1 and 128 characters.
- Value: Between 1 and 256 characters, no control characters, case-sensitive.
- Header names arrive in lowercase, so
ai-cost-Project and ai-cost-project are the same header.
- Each
ai-cost- header must appear once per request.
The gateway drops the tag when a header is duplicated, even when both values are equal.
- The gateway drops tags with empty values.
- A single event holds at most 64 tags.
When a request exceeds this limit, the gateway drops all of its tags.
- Don’t put PII in a tag, for example a name, email, or username.
User identity comes from the auth strategy on the model.
Some tools send native headers that the gateway maps to standard tag keys automatically, so you don’t need ai-cost- headers.
See Attribution integrations for the supported tools and the tags each one sends.
The following standard tag keys define a shared vocabulary for common dimensions.
A tag can use any valid key.
These conventional names help tags from different tools and teams align.
|
Tag key
|
Category
|
Meaning
|
project
|
Project context
|
The project this request belongs to.
|
ticket
|
Project context
|
The issue or ticket this request relates to.
|
environment
|
Project context
|
The deployment environment, for example production or staging.
|
use-case
|
Project context
|
The intended use case.
|
feature
|
Project context
|
The product feature driving the request.
|
customer-account
|
Project context
|
The customer account associated with the request.
|
experiment
|
Project context
|
The experiment this request is part of.
|
experiment-variant
|
Project context
|
The variant within the experiment.
|
deployment
|
Project context
|
The deployment identifier.
|
agent-session
|
Agent
|
A session identifier for the AI agent.
|
agent-id
|
Agent
|
The agent’s unique identifier.
|
agent-parent
|
Agent
|
The identifier of the parent agent in a multi-agent setup.
|
agent-request-kind
|
Agent
|
The kind of request the agent is making.
|
agent-type
|
Agent
|
The type of agent.
|
agent-name
|
Agent
|
The agent’s display name.
|
agent-surface
|
Agent
|
The surface the agent is running on.
|
scm-provider
|
Source control
|
The source control provider, for example github or gitlab.
|
scm-repository
|
Source control
|
The repository name.
|
scm-branch
|
Source control
|
The branch name.
|
scm-commit
|
Source control
|
The commit SHA.
|
scm-pull-request
|
Source control
|
The pull or merge request identifier.
|
scm-issue
|
Source control
|
The source control issue identifier.
|
ci-provider
|
CI
|
The CI provider, for example github-actions or gitlab-ci.
|
ci-pipeline
|
CI
|
The pipeline name or identifier.
|
ci-run
|
CI
|
The run identifier.
|
chat-provider
|
Chat
|
The chat platform, for example slack.
|
chat-organization
|
Chat
|
The chat organization or enterprise.
|
chat-workspace
|
Chat
|
The workspace within the chat platform.
|
chat-channel
|
Chat
|
The channel name.
|
chat-channel-id
|
Chat
|
The channel’s unique identifier.
|
chat-channel-type
|
Chat
|
The channel type, for example dm or public.
|
chat-trigger
|
Chat
|
The event that triggered the request, for example slash-command.
|
chat-command
|
Chat
|
The specific command or action invoked.
|
workflow-name
|
Workflow
|
The workflow or pipeline name.
|
workflow-run
|
Workflow
|
The workflow run identifier.
|
You can define custom keys for any dimension the standard keys don’t cover.
A custom key follows the same rules as any other tag key.
To avoid conflicts with future standard keys, prefix custom keys with a namespace, for example acme-cost-center- or internal-team-.