> For the complete documentation index, see [llms.txt](https://docs.finout.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.finout.io/user-guide/inform/virtual-tags/finout-virtual-tags/canonical-ai-taxonomy.md).
# Canonical AI Taxonomy
### Overview
Every LLM provider — AWS Bedrock, Azure Foundry, OpenAI, Anthropic, and others — structures its billing data differently, uses its own model identifiers, and embeds model information in usage description strings rather than exposing it as a dedicated field. The same model accessed through two different cost centers can appear under completely different identifiers in raw billing data, making cross-cost-center analysis difficult without manual mapping.
To address this, Finout provides a set of predefined [Virtual Tags](https://docs.finout.io/user-guide/inform/virtual-tags/finout-virtual-tags) that normalize this data into a consistent taxonomy. They parse model information from each cost center's billing data and surface it as filterable tags — so you can analyze LLM spend across all your cost centers.
These Virtual Tags are maintained and updated by Finout.
### **Where to find the tags:**
To use these Virtual Tags, navigate to **Global** and select the **Finout Virtual Tags** tab. The tags are available automatically — no configuration required.
### Supported Cost Centers
These Virtual Tags apply to the following CSPs and SaaS providers:
* AWS
* GCP
* Azure
* Anthropic
* OpenAI
* Cursor
LLM spend from cost centers not listed above will not be tagged.
### Virtual Tag Definitions
#### `Model Brand`
The product brand under which a model is marketed, independent of the cost center through which it is accessed.
A single brand can appear across multiple cost centers. Claude, for example, is available through Anthropic, Bedrock, and Bedrock Marketplace — Model Brand normalizes all of these under `Claude`, so you can see total brand-level spend regardless of procurement path.
**Example values:** `Claude` · `GPT` · `Gemini` · `Llama` · `Mistral` · `Cohere` · `Nova`
#### `Model Family`
Groups model variants under a shared generational line, regardless of version date or minor iteration.
Where `Model Name` identifies the specific version, `Model Family` identifies the line it belongs to. This makes it useful for tracking spend trends across a model generation and understanding how spend shifts between generations over time.
**Examples:**
| Model Name | Model Family |
| ------------------- | -------------- |
| `GPT-4o 2024-11-20` | `GPT-4o` |
| `Claude Haiku 4.5` | `Claude Haiku` |
| `Gemini 2.5 Pro` | `Gemini Pro` |
If a model doesn't include a distinct generational variant (e.g., GPT-5), then the `Model Family` will default to either the `Model Name` or the `Model Brand`.
#### `Model Name`
The normalized model identifier — a consistent, human-readable name for the specific model version being used.
**Why normalization is needed:** Many cost centers do not expose model name as a standalone field. Instead, it appears embedded in usage description strings, SKU names, or resource identifiers, formatted according to each cost center's own conventions. A single model can appear as `USE1-Llama3-8B-output-tokens` in one cost center and `Llama3-8B` in another. `Model Name` parses each cost center's billing data and produces a consistent identifier across all cost centers.
**What a canonical model name includes:**
* The model family name and variant (e.g. `GPT-4o`, `Claude Sonnet`)
* A version date or iteration where the provider includes it (e.g. `GPT-4o 2024-11-20`, `Claude Haiku 4.5`)
* Parameter count where it is part of the model's identity (e.g. `Llama 3.3 70B`)
**What it does not include:**
* Cost center specific prefixes or suffixes (e.g. region codes, token type labels, edition names)
* Modality identifiers — text, image, and speech variants of the same model are not distinguished
**Examples:**
| Raw billing string | Model Name |
| ------------------------------------------- | ------------------- |
| `gpt 4o 1120 Inp regnl Tokens` | `GPT-4o 2024-11-20` |
| `USE1-Llama3-8B-output-tokens` | `Llama 3 8B` |
| `Claude Haiku 4.5 (Amazon Bedrock Edition)` | `Claude Haiku 4.5` |
#### `Model Channel`
Identifies the billing path through which a model is accessed — the cost center or integration through which the spend is flowing.
A single model can be accessed through multiple cost centers, each with different pricing, contract terms, and billing structures. `Model Channel` makes this visible, so you can compare spend on the same model across procurement paths and understand where your LLM budget is actually going.
**Example values:** `Bedrock` · `Bedrock Marketplace` · `Anthropic` · `OpenAI` · `AI Foundry` · `Vertex AI` · `Gemini API`
#### `Model Lifecycle`
Indicates the current operational status of a model based on provider documentation.
**Lifecycle states:**
| State | Definition |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Current** | The most recently released model in a given family. Recommended for new and ongoing production workloads. |
| **Legacy** | A model that has been superseded by a newer version but has not yet been formally sunset by the provider. Still callable, still supported, but no longer the recommended option for new workloads. |
| **Deprecated** | The provider has issued a formal end-of-life or end-of-support announcement for the model. Still accessible until its EOL date, but at risk of pricing increases, feature lockouts (no new fine-tunes, no new Provisioned Throughput), until the eventual removal. |
| **Unknown** | All data from before December 31st, 2025 |
**How status is determined:** Finout monitors official provider documentation and deprecation notices to assign lifecycle status. `Current` reflects the most recently released model in a given family. `Deprecated` reflects a formal provider announcement of EOL or end-of-support. `Legacy` covers everything in between — models that have been superseded but have not yet been formally sunset.
`Model Lifecycle` is a point-in-time representation based on provider documentation at the time of last update.
**For Example:**
MegaBill grouped by `Model Lifecycle`, showing the split between Deprecated, Current, and Legacy model spend over time.
#### **Worked example table:**
A raw AWS Bedrock cost line — `Claude Opus 4.7 (Amazon Bedrock Edition)` — is automatically classified as:
| Tag | Value |
| ----------------- | ----------------- |
| `Model Name` | `Claude Opus 4.7` |
| `Model Family` | `Claude Opus` |
| `Model Brand` | `Claude` |
| `Model Channel` | `Bedrock` |
| `Model Lifecycle` | `Legacy` |
### Virtual Tag Use Cases
**Identifying deprecated spend by cost center:** Filter by `Model Lifecycle = Deprecated`, then group by `Model Channel`. This shows you not just how much you're spending on sunset models, but which procurement paths that spend is flowing through — so you know where to target migration effort.
**Total LLM spend by brand, across all cost centers:** Group by `Model Brand`. This gives you a cost center agnostic view of which AI brands are driving spend — useful for vendor consolidation decisions and negotiating volume agreements.
**Tracking spend distribution across model families:** Group by `Model Family` and view over a rolling period. This surfaces how spend is distributed across families within the same brand — for example, whether Claude spend is concentrated in Sonnet, split across Sonnet and Haiku, or still carrying Opus usage.
**Catching cross-channel pricing arbitrage**: Group by Model Name and by Model Channel. The same Claude Sonnet 4.5 model accessed via Bedrock, Anthropic, and Bedrock Marketplace will appear in three rows — letting you see whether you're paying different rates for the same model across procurement paths.
### FAQ
**Why is some of my LLM-related spend not tagged?** Not all LLM-related charges are model invocation costs. Only model invocation charges are tagged — supporting charges such as AWS Bedrock Guardrails, AI agent runtime, and tool-use fees are not.
**Can I see text, image, and speech costs separately?** No. Modality is not separated — text, image, speech, and embedding usage of the same model are not distinguished by these Virtual Tags. All invocation types roll up under the same Model Name, Family, Brand, and Lifecycle values.
**Why is spend from one of my cost centers not showing up?** These Virtual Tags only apply to the cost centers listed in [Supported Cost Centers](#supported-cost-centers). Any LLM spend flowing through a cost center not on that list will not be tagged.
**Why doesn't a model's lifecycle status reflect a recent deprecation announcement?** Lifecycle status is determined by official provider documentation. Lifecycle tags will be updated to reflect new provider deprecations within a time period of 2 weeks from the official announcement.
**What if I disagree with how a model is classified?** Lifecycle status is based on the provider's official documentation, not Finout's judgment. If you believe a model is misclassified, contact Finout support at with the model name and the provider documentation URL
**Can I customize or override these tags?** No. Predefined Virtual Tags are maintained centrally by Finout and cannot be edited on a per-account basis. To classify spend by your own logic, create a custom Virtual Tag that derives from these predefined ones.
**Why is some of my historical spend marked as "Unknown" under Model Lifecycle?**\
To maintain data integrity and taxonomy accuracy, all LLM spend data incurred prior to December 31st, 2025, is automatically classified with an `Unknown` lifecycle status.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.finout.io/user-guide/inform/virtual-tags/finout-virtual-tags/canonical-ai-taxonomy.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.