> ## Documentation Index > Fetch the complete documentation index at: https://docs.vantage.sh/llms.txt > Use this file to discover all available pages before exploring further. # Managed AI Tags > Vantage automatically normalizes supported AI provider billing and usage fields into a consistent vntg:ai: tag schema, so you can filter, group, and allocate AI spend by model, token type, user, and more. Managed AI Tags are a Vantage-managed tag schema that standardizes AI cost data across supported providers. As spend flows in from integrations such as Cursor, Anthropic, OpenAI Platform, AWS Bedrock, Azure OpenAI, and Google Cloud, Vantage maps each provider's billing and usage fields into a consistent set of `vntg:ai:` tags. The same keys, like `vntg:ai:model`, `vntg:ai:model_provider`, and `vntg:ai:token_type`, appear regardless of which supported provider the spend came from, so you can build [Cost Reports](/cost_reports), [Virtual Tags](/tagging), [Budgets](/budgets), and [Cost Alerts](/cost_alerts) on the same dimensions across your AI stack. Each AI provider exposes different fields: the model name may be the service on one integration and a tag on another, and user identity may be an email, a user ID, or an API key depending on the vendor. Managed AI Tags are metadata-only and included with Vantage at no additional cost for accounts with supported AI cost integrations. Vantage only normalizes fields your providers already report in cost and usage data; it does not collect prompt or completion content. ## How It Works Managed AI Tags are applied automatically during each provider's cost ingestion. Vantage reads the provider's billing and usage fields, maps them to the normalized schema, and writes the resulting tags, prefixed with `vntg:ai:` by default, onto the cost rows. No configuration is required: once you connect a supported AI integration, the tags appear on that provider's costs and become available anywhere tags are supported in Vantage. Not every provider supplies every field. Vantage only writes a tag when the source data provides a reliable value for that key, so the set of `vntg:ai:` tags you see depends on which providers you have connected and what each one reports. ## The Managed AI Tag Schema The following keys make up the canonical Managed AI Tag schema. Each key is shown with the `vntg:ai:` prefix. | Tag key | What it tells you | Example values | | - | - | - | | `vntg:ai:model` | The cleansed, normalized model name, so you can compare the same model across providers and release dates. | `gpt-4o`, `claude-sonnet-4` | | `vntg:ai:raw_model` | The exact model name from the provider, kept when it differs from the normalized `vntg:ai:model` value. | `gpt-4o-2024-08-06`, `claude-sonnet-4-20250514` | | `vntg:ai:model_provider` | Who built the model, even if another platform hosts or bills for it. Useful for standardizing models procured through cloud providers. | `Anthropic`, `OpenAI`, `Google`, `xAI` | | `vntg:ai:token_type` | What kind of tokens this charge is for. | `input`, `output`, `cache_read`, `cache_write` | | `vntg:ai:provider_region` | Where the request ran (region or geography). | `us-east-1`, `global` | | `vntg:ai:service_tier` | The pricing or speed tier for this usage. Values vary by provider. | `default`, `priority`, `batch`, `flex` | | `vntg:ai:api_key_id` | Which API key was used. | Provider key ID | | `vntg:ai:user_email` | Email of the person who triggered the usage. | `alice@company.com` | | `vntg:ai:user_name` | Display name of the person who triggered the usage. | `Alice Smith` | | `vntg:ai:user_id` | User ID from the provider. | Provider user ID | | `vntg:ai:principal_id` | A provider-specific caller identifier that is not tied to a specific user name or email (for example, the IAM principal on Amazon Bedrock). | `team-a/session` | | `vntg:ai:operation` | How the model was invoked, when the provider prices streaming and non-streaming calls separately. | `inference`, `streaming` | | `vntg:ai:inference_scope` | Whether the request used a global or regional inference profile. | `global`, `regional` | Not every provider supplies every field. Vantage only writes a tag when the source data provides a reliable value for that key. When [Custom LLM Enrichment](/custom_llm_enrichment) is enabled, Vantage also writes request metadata into the same schema, including `vntg:ai:endpoint` and, for AWS Bedrock, `vntg:ai:operation` (`inference` or `streaming`) and `vntg:ai:inference_scope` (`global` or `regional`). [AWS Bedrock LLM Enrichment](/aws_bedrock_enrichment) populates the same two Bedrock keys from your Model Invocation Logs. These keys come from per-request telemetry rather than native provider billing. See [Managed AI Tags vs. Custom LLM Enrichment](#managed-ai-tags-vs-custom-llm-enrichment). Anthropic also emits `vntg:ai:inference_speed` (its service speed tier) alongside the canonical keys. ## Supported Providers Managed AI Tags are emitted automatically for supported AI cost integrations. The keys each provider populates depend on the fields that provider reports. | Provider | Emitted `vntg:ai:` keys | | - | - | | [Cursor](/connecting_cursor) | `model`, `raw_model`, `model_provider`, `user_email` | | [Anthropic](/connecting_anthropic) (Claude API) | `model`, `model_provider`, `provider_region`, `service_tier`, `inference_speed`, `token_type` | | [Anthropic](/connecting_anthropic) (Claude.ai) | Adds `user_email`, `user_name`, `user_id` | | [OpenAI Platform](/connecting_openai) | `model`, `raw_model`, `model_provider`, `provider_region`, `service_tier`, `token_type`, `user_id`, `api_key_id` | | [AWS Bedrock](/connecting_aws) | `model`, `raw_model`, `model_provider`, `provider_region`, `service_tier`, `token_type`, `principal_id`. Adds `operation` and `inference_scope` with [AWS Bedrock LLM Enrichment](/aws_bedrock_enrichment). | | [Azure](/connecting_azure) (Azure OpenAI, Marketplace Anthropic) | `model`, `raw_model`, `model_provider`, `provider_region`, `service_tier`, `token_type` | | [Google Cloud](/connecting_gcp) (Vertex AI Gemini, Marketplace Claude) | `model`, `raw_model`, `model_provider`, `provider_region`, `token_type` | | [Anyscale](/connecting_anyscale) | `user_email`, `user_id` | | [ElevenLabs](/connecting_elevenlabs) | `model`, `model_provider` | | [Baseten](/connecting_baseten) | `model`, `model_provider`, `token_type` | | [Fireworks AI](/connecting_fireworks_ai) | `model`, `model_provider`, `token_type` | | [xAI](/connecting_spacexai) | `model`, `raw_model`, `model_provider`, `service_tier`, `token_type`, `api_key_id` | For the hyperscalers, Managed AI Tags apply only to the AI portion of spend: Amazon Bedrock cost rows on AWS, Azure OpenAI, Foundry, and Marketplace Anthropic cost rows on Azure, and Vertex AI Gemini and Marketplace Claude cost rows on Google Cloud. Non-AI costs on those providers are unaffected. OpenAI Codex costs currently use provider-specific `openai:` tags and do not receive Managed AI Tags. The OpenAI row above applies only to OpenAI Platform costs imported with an Admin API key. ## How Managed AI Tags Coexist with Provider Tags Managed AI Tags add a cross-provider layer on top of the provider-specific tags Vantage already creates. Provider-specific native tags, such as `cursor:user`, `openai:api_key_id`, or `anthropic:model`, continue to exist and capture fields unique to that integration, while the managed `vntg:ai:` keys give you a single, consistent dimension that works across providers. Managed AI Tags are also additive to your existing configuration: they do not modify your [Virtual Tags](/tagging), [Billing Rules](/sql_billing_rules), or reports. You can start using them in new reports and filters immediately alongside everything you already have. ## Renaming or Standardizing Managed AI Tags Vantage maintains the canonical Managed AI Tag definitions with the set `vntg:ai:` prefix so the schema stays consistent across every account. If you want to present these tags under different key names, use [Tag Key Collapsing](/tagging#tag-key-collapsing) to map one or more `vntg:ai:` keys into a [Virtual Tag](/tagging) with your preferred naming. ## Backfill and Data Freshness Managed AI Tags are applied as part of each provider's cost ingestion, so they follow that provider's refresh cadence. See the [provider data refresh documentation](/provider_data_refresh) for per-provider timing. Normalized `vntg:ai:` tags are available from August 2026 onward. Vantage does not backfill managed tags onto earlier historical data. ## Use Managed AI Tags in Cost Reports Once a supported AI integration is connected and its costs are processed, the `vntg:ai:` keys appear in the **Tag Key** dropdown wherever tags are supported. To analyze AI spend with them: * **To group:** open the **Group By** menu on a [Cost Report](/cost_reports), select **Tag**, and choose a key such as `vntg:ai:model` (values like `gpt-4o`) or `vntg:ai:model_provider`. * **To filter:** open the **Filters** menu, add a new rule, select **Tag**, choose the **Tag Key** (for example, `vntg:ai:user_email`), then pick an operator and one or more values. Because the same keys span every AI provider, you can drill into a single developer's spend across Cursor and Anthropic in one view, or compare model mix across your whole AI stack. Managed AI Tags also work anywhere else tags are supported, including [Virtual Tags](/tagging), [Budgets](/budgets), and [Cost Alerts](/cost_alerts). If you use a handful of keys often, mark them as [preferred tags](/tagging#preferred-tags) so they sort to the top of these menus. In the example below, a Cost Report groups by **Provider** and **Usage Unit** alongside `vntg:ai:model_provider` and `vntg:ai:model`. Because `vntg:ai:model_provider` reflects who built the model rather than who billed for it, the same Anthropic models roll up under one provider value whether they were purchased through Cursor, through Anthropic directly, or through AWS Bedrock, with normalized model names, token counts, and costs lined up side by side. ![A Vantage Cost Report grouping AI spend by model provider and model, showing Anthropic models billed through Cursor, Anthropic, and AWS with token usage and costs](https://assets.vantage.sh/docs/managed-ai-tags.png) ## Managed AI Tags vs. Custom LLM Enrichment Managed AI Tags and [Custom LLM Enrichment](/custom_llm_enrichment) are complementary features that share the `vntg:ai:` vocabulary but solve different problems. | | Managed AI Tags | [Custom LLM Enrichment](/custom_llm_enrichment) | | - | - | - | | What it does | Normalizes fields your providers **already report** into a consistent `vntg:ai:` schema. | Joins **your own** per-request token telemetry (delivered to S3) to provider costs to fill gaps the bill doesn't itemize. | | Setup | Automatic once a supported AI integration is connected. | You emit telemetry in the common schema and connect an S3 source. | | Typical dimensions | `model`, `model_provider`, `token_type`, `service_tier`, `provider_region`, and identity fields when the provider reports them. | Custom `tags` you define (for example, `team`, `feature`, `environment`) plus request metadata like `endpoint` and `service_tier`. | In short, Managed AI Tags standardize what providers already send, while Custom LLM Enrichment enriches what providers leave out. Use them together for the most complete view of AI spend. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.