Vantage Launches the Token Cost Allocation Specification
A uniform, provider-agnostic standard for attributing every token to the team, customer, or feature that drove it, so you can report, budget, and control LLM spend across your entire AI stack.
Today, Vantage is launching the Token Cost Allocation Specification: a uniform standard for companies to allocate token costs across frontier model providers, hosted AI gateways, or internal gateways. Customers can now grant Vantage access to logs following this specification to allow teams to enrich their token costs with tags to report, forecast, budget, and ultimately control token costs by team, business unit, or service.
Organizations have rapidly adopted AI across their teams, both in enterprise applications and by the team members themselves. However, the attribution of this usage has been an afterthought. Organizations can see the total amount they are spending on OpenAI, Anthropic, and other frontier model companies, but lack request-level attribution, tagging, and categorization to get the visibility necessary to perform showback and chargeback accurately. We’ve been working in private preview since February 2026 on this problem and have developed the Token Cost Allocation Specification to help organizations manage these costs.
The goals with this were the following:
- One common schema across providers. Logs carry the provider alongside the model, so Vantage routes each one to the right provider's costs, and an allocation model survives a change of provider, gateway, or observability vendor.
- Continuous ingestion. Telemetry is read from a customer's own S3 bucket as it lands, so token spend is attributed as it is produced rather than whenever someone exports it.
- Token reconciliation. Gateways and providers can disagree on token counts, and usage can exist outside of gateway usage. Vantage considers both over-reported and under-reported token consumption for accurate cost allocation.
- AI Gateway Agnostic. The specification doesn’t require you to use a hosted AI Gateway (like Cloudflare AI Gateway or OpenRouter), but those providers can eventually map to this standard.
Today, Vantage is publishing this specification and it’s generally available to our entire customer base to gain the visibility necessary to allocate AI costs accurately. Customers can grant Vantage access to invocation logs, exposed via an S3 bucket, that include per-request usage metadata and tags. Vantage will then allocate cost to each request, rolling spend up to the tags each request carries, such as team, customer, or feature. Customers can grant Vantage access to a single, consolidated log stream that spans all of their LLM providers, such as OpenAI, Anthropic, AWS, Google Cloud, and Azure, and Vantage will route and allocate each record to the matching provider costs. While we plan to add native bindings to hosted AI Gateways (such as Cloudflare AI Gateway, LiteLLM, and OpenRouter) in the near future, you can provide invocation logs from them prior to our formal support. An example of a log line following the specification is below:
To integrate Token Cost Allocation logs, customers can use the “Custom LLM Enrichment” integration available under the new “LLM Enrichment” section of Integrations, which grants Vantage access to one or more S3 buckets where these logs are emitted to. Vantage grants read-only S3 access by attaching permissions to your existing AWS cross-account role, with no new role or credentials being created.
Once a Custom LLM Enrichment integration is made, Vantage will first validate a small sample of logs to ensure it follows the proper format and then will proceed with processing. Vantage splits a matching cost row into one row per tag combination in proportion to its share of tokens and appends each row with the tags the provider bill never contained. For example, a single $100 GPT 5.5 day when the Growth team drove 50% of tokens and the Research team drove 30% becomes a $50 row tagged team=growth, a $30 row tagged team=research, and a $20 leftover row for the usage not included in the telemetry stream. The split always sums back to the original cost to the cent, using costs billed from LLM providers as the cost source of truth. Any tags attached to requests, such as Team, Application, Customer, or Purpose, are added to the cost rows. They behave like any other tag in Vantage, with the ability to group or filter by request attributes, add them to Virtual Tags, create budgets and alerts, and more.
Enrichment of AI vendor costs using the Token Cost Allocation Specification is generally available today at no additional cost. To get started, add a Custom LLM Enrichment source on the Integrations page. See the Custom LLM Enrichment documentation for more detail on the schema, setup, and tagging guidance.
Frequently Asked Questions
1. What is being launched today?
Vantage is publishing the Token Cost Allocation Specification, a uniform standard for describing per-request LLM usage and the dimensions organizations use to allocate token costs. Vantage is also making its implementation of the specification generally available: customers can send Vantage specification-compliant logs, and Vantage will enrich costs from AI vendors with dimensions such as team, user, application, feature, environment, or customer, so they can group, filter, budget, and alert on LLM spend at a granular level.
2. Who is the specification for, and who can use it with Vantage?
The Token Cost Allocation Specification can be adopted by any company, model provider, AI gateway, or observability vendor that wants a consistent way to describe token usage and allocation dimensions across providers. Vantage's implementation is available to customers with an active cost integration for a supported provider; the current delivery requirements are described in Q17.
3. How much does this cost?
There is no additional charge to use Vantage's implementation of the Token Cost Allocation Specification. It is included for customers with a supported provider integration, and allocated costs do not count against a separate meter. The specification itself is not a paid product.
4. How does Vantage use specification-compliant telemetry?
Customers emit a single specification-compliant record per LLM request, including attributes such as provider, model, token counts, and allocation tags, and deliver those records to Vantage through an S3 bucket. Once you provide Vantage read-only access to that bucket, Vantage imports the log telemetry alongside that provider's costs, matches them to the provider's cost rows for the same day and model, and allocates each row across your tags in proportion to the tokens behind them. This provides customers with detailed cost reporting dimensions based on attributes such as service tier, batch request, API key, and tag key-value pairs that do not exist directly on cost data from providers.
5. What does the Token Cost Allocation Specification define?
The specification defines each record as a single JSON object describing one LLM request: an identifier for deduplication, a UTC timestamp, the provider and model, a usage block, and an optional tags object carrying the dimensions you want to allocate by.
Required fields: event_id, timestamp, provider, model, and usage.
modelshould be the identifier the provider reports, keeping any provider-specific prefixes such as Bedrock'santhropic.or Vertex'smodels/. This is the default join key against your cost data.providermust be one of the accepted values for your integration:openai;anthropic;awsorbedrock;gcp,gemini,google, orvertex;azure,azure_openai, orazure-openai.usageneeds at least one positive integer. Whenuncached_input_tokensis absent, Vantage derives it asmax(0, input_tokens - cache_read_input_tokens - cache_write_input_tokens).resource_account_idis recommended whenever one bucket carries logs for multiple integrations of the same provider, so each request matches the right costs.
Vantage prefers stable, low cardinality tag keys with a limited set of values, such as team, environment, and purpose. Keys appear exactly as you emit them and are not provider-namespaced, so one team key lines up across your whole AI stack. Tags are case-sensitive, and team and Team are two different keys. It is best practice to keep identifiers like request_id and provider_request_id out of tags, as they are high-cardinality and difficult to use as allocation dimensions. Avoid personally identifiable values, and never put API keys, credentials, or other secrets in any field or tag.
Records are skipped when a required field is missing or unparseable, the provider is unsupported, the model cannot be matched to your cost data, status is set to anything other than success, or no usage field is a positive integer.
6. How does Vantage allocate costs from specification-compliant logs?
For each day, Vantage deduplicates your records on event_id. When duplicates exist, the record with the highest total token count wins, and Vantage sums tokens for each unique combination of tag values. It then matches your provider's cost rows against those totals and replaces each matching row with one row per tag combination, allocating cost in proportion to each combination's share of tokens. Each split row keeps the provider's existing tags, adds a vntg:ai:model tag, and adds the tags from that slice; when a slice tag and an existing tag share the same key, the slice (enrichment) value wins.
A $500 day of Opus usage covering 500M input tokens, where your telemetry shows 350M tokens tagged customer=acme and 150M tagged customer=ecorp, becomes a $350 row and a $150 row.
In the event the telemetry contains fewer tokens than the provider reports, Vantage creates a leftover row for the uncovered tokens. In the same example, if your telemetry shows 250M tokens tagged customer=acme and 150M tagged customer=ecorp, it becomes a $250 row, a $150 row, and a $100 leftover row for the 100M tokens your telemetry did not cover. The leftover row keeps the provider's existing tags and the vntg:ai:model tag but carries no slice tags.
If the token amount present in logs exceeds the tokens in the cost data from the provider, Vantage allocates the cost by token proportion, with no leftover, untagged row.
Splits are additive, so the newly created rows always sum to the original cost from the provider, and provider-level reports show the same totals they always have. Enrichment re-attributes existing costs and never creates, drops, or re-prices them. Note that split rows retain the provider's existing tags (for example, Vantage's ai:* tags), plus the vntg:ai:model tag and their slice tags; enrichment tags take precedence only when a key collides.
7. How does Vantage handle costs with no or partial matching telemetry?
A cost row with no matching telemetry passes through without allocation splits. A row with partial coverage is still split, and the uncovered portion becomes a leftover row carrying only the vntg:ai:model tag, so the day's total reconciles against the bill either way.
If costs are not splitting when you expect them to, the usual causes are that no active source exists for the account yet, telemetry has not been ingested for that period, the model or token kind on the cost row has no logged request for that provider and date, or records were skipped at ingestion (see the validity rules in Q5).
8. Where do allocated costs appear in Vantage?
Enriched LLM costs show up everywhere tags are supported: Cost Reports, Virtual Tags, Segments, Budgets, and Cost Alerts. Enriched attributes, such as the vntg:ai:model tag Vantage adds automatically, or one of your own, such as team, appear in the Tag Key dropdown of Filters and Groupings once enriched costs exist.
9. Which provider costs can Vantage allocate using the specification?
At launch, Vantage supports the enrichment of costs from OpenAI, Anthropic, AWS (Bedrock), Google Cloud (Vertex AI Gemini and Marketplace Claude), and Azure OpenAI. Azure support covers direct Azure (Azure OpenAI) integrations; Azure CSP billing accounts are not supported.
10. Does the specification require prompt content, and does Vantage collect it?
No. The specification does not require prompt or completion content, and Vantage's implementation is metadata-only. The telemetry carries request identifiers, the provider and model, usage counts, and the allocation tags you choose to emit. Prompt and completion text are never collected or stored, and are never written to a Vantage-owned artifact.
11. Is my data used to train any models?
No. Specification-compliant telemetry processed by Vantage is not used to train any models.
12. What permissions are required to use the specification with Vantage?
In Vantage, you must have the Organization Owner or Integration Owner role to connect a telemetry source. See Role-Based Access Control documentation for more information. Viewing enriched costs requires no special role. The tags follow the same access rules as any other cost data.
13. What permissions does Vantage require to read logs?
In AWS, Vantage receives read-only access to each bucket you connect: s3:GetObject (generated policies also include s3:GetObjectAcl), s3:ListBucket, s3:GetBucketLocation, and kms:Decrypt if the bucket uses SSE-KMS. Your existing cross-account role already grants bucket listing and location, so the grant adds object read on that bucket. KMS access must be granted separately; the CloudFormation, CLI, and Terraform options cover S3 only.
14. Do I need an AI gateway to use the specification?
No. The specification is gateway-agnostic. Conforming records can be produced by your application, a hosted AI gateway, an internal gateway, an observability system, or a logging pipeline built around model-provider data.
If you procure your AI services directly from AI vendors such as OpenAI and Anthropic, you can utilize our open-sourced LLM Telemetry Cold Start modules for transforming your logs into the Token Cost Allocation specification.
15. How do I connect specification-compliant logs to Vantage?
On the Vantage Integrations page, add the integration for specification-compliant token invocation logs and select the bucket. Access can be provided in 3 ways: via CloudFormation, an AWS CLI command, or manually provisioning the additional_inline_policies argument on the Vantage Terraform module for teams that manage their integration as code. All three attach the permissions to your existing Vantage cross-account role. No new role and no new credentials are created. Once you deploy the read-only permissions in the account that owns the bucket, you can validate the connection by clicking Check Permissions.
16. How should I deliver specification-compliant logs to Vantage?
The record schema comes from the Token Cost Allocation Specification. For Vantage's current ingestion implementation, write those records as newline-delimited JSON, gzip them, and place them under a date-partitioned S3 path:
Use the request timestamp's UTC date for the partition, write one record per line rather than wrapping records in an array, and batch many records into larger objects instead of writing one object per request.
Note: Newly created buckets can take up to 24 hours to appear in Vantage's inventory.
17. Can Vantage ingest specification-compliant telemetry from storage other than Amazon S3?
Not at general availability. Vantage's current implementation reads specification-compliant telemetry from an S3 bucket you own through your existing AWS cross-account role. This is why an active AWS integration is required even when the costs being allocated come only from OpenAI, Anthropic, Google Cloud, or Azure.
Support for Azure and Google Cloud storage is coming, so teams whose logging pipelines already terminate there will not need to route through S3. If that is blocking you today, contact support@vantage.sh so we can factor your setup into the rollout.
18. How do AI gateways such as LiteLLM, OpenRouter, and Cloudflare work with the specification?
Customers can use data from these gateways today by emitting or transforming their logs into the Token Cost Allocation Specification and delivering them through Vantage's supported ingestion path. Native Vantage integrations that automate this mapping are separately in private preview and will soon be generally available to all Vantage customers.
19. How fresh are allocated costs in Vantage?
Allocation from specification-compliant logs runs as part of each provider's existing cost ingestion, so it follows that provider's refresh cadence. See provider data refresh for per-provider timing. Recent days are reprocessed on a rolling three-day window, so late-arriving logs are picked up automatically.
For older periods, Vantage re-enriches a day when the set of log objects for that day changes, meaning files are added or removed, or when a full rebuild is triggered. Replacing the contents of an existing object under the same key does not on its own re-trigger enrichment. Re-enrichment reads already-normalized cost data and does not require a full cost re-import.
20. How do I allocate AI vendors that aren't billed per token, such as ElevenLabs or Modal?
The Token Cost Allocation Specification's current allocation model requires per-request token telemetry that can be joined to a supported provider's costs. Providers billed in credits, minutes, or requests therefore fall outside this token-based allocation model. Allocation of these costs can be accomplished with Vantage's Virtual Tag allocation methods instead: Cost-Based splits a charge in proportion to each team's usage of the underlying service, Percent-Based applies a fixed or negotiated ratio, and Business Metric-Based splits in proportion to a metric you import, such as minutes generated or seats served. See Chargeback and Showback for choosing a method and Tagging Examples for worked configurations.
Sign up for a free trial.
Get started with tracking your cloud costs.
