Dynatrace generative and agentic AI capabilities are metered with AI Units. A single AI Unit is a normalized quantity of AI work performed when a prompt or request runs large-language-model (LLM) inference on your behalf. As the complexity and value of a task grows, so does its AI Unit consumption.
This page explains how consumption is calculated for AI Units, how to estimate usage for different use cases, and how to track your actual usage.
AI-driven actions can also generate Standard Function Calls and query consumption; for an overview of how all three relate, see Agentic AppEngine overview (DPS).
AI Units meter AI/LLM work: Inference performed by the driver LLM (the operator) for agentic reasoning, and any LLM-based tool that the driver LLM invokes. Available tools are listed in the MCP server documentation. Examples include create-dql (nl2dql) and explain-query (dql2nl).
AI Units are metered:
Non-LLM-based tools invoked by the driver LLM are billed separately as Standard Function Calls, and any resulting DQL queries as query consumption. See Agentic AppEngine overview (DPS) for how these relate.
The normalized unit of measure for AI/LLM work. One AI Unit represents a base amount of inference work, adjusted by a variable weight factor that reflects the complexity of the task.
The large language model that performs agentic reasoning, orchestrates tool calls, and generates responses on your behalf.
The following examples show, step by step, how AI Units are calculated. Each step is calculated according to the activity that's called, triggered, or executed. You can review each step with your own usage data using the queries in Query billing usage events with DQL.
In general, here are common AI-invocation scenarios. (This list isn't exhaustive and might change over time.)
If you ask, for example, "Show me logs with errors":
create-dql). This is billed as AI Units.execute-dql). This is billed as a Standard Function Call and query consumption.If you ask Dynatrace to only generate the query without executing it, only step 1 is billed.
If you ask, for example, "How do I set up alerts?", Dynatrace answers the question by looking up documentation and other sources (ask-dynatrace-docs). This is billed as AI Units.
This is a single-step generative request, the lightest billing sequence.
If you ask an agent to investigate a problem and summarize the root cause:
operator). This is billed as AI Units.get-problem-by-id). This is billed as a Standard Function Call.execute-dql). This is billed as a Standard Function Call and query consumption.A single AI invocation can drive several AI Function Standard Calls, which might generate billable query consumption, depending on the related query executions. A deeper investigation reasons more, and therefore bills more.
For examples where agentic AI generates an AI Function Standard Call without any AI Units, see Understand and manage Standard Function Calls consumption (DPS).
Dynatrace provides various options to help you understand and analyze your organization's AI Units costs.
License managers can view usage and costs in Account Management.
Go to Account Management > Subscription > Overview > Cost and usage details > Usage summary.
Select the AI Units capability.
From this screen, you can also drill down into usage detail on the capability and environment level.
For more information, see Overview (Dynatrace Platform Subscription).
Billing usage events (billing_usage_event) are system events emitted by Dynatrace that capture already-calculated, billable usage for DPS capabilities. They are the most reliable source for building cost dashboards and allocation reports.
AI Units are recorded as their own event type, sharing a common set of fields with other AI-related events so you can break consumption down by tool, user, workflow, or conversation. This lets you reconstruct the sequence of an AI request.
For the complete field reference, see AI Units billing usage in the Semantic Dictionary.
| Field | Description |
|---|---|
|
|
| AI Units billed for this call. It is calculated as a base amount adjusted by a variable weight factor that reflects the complexity of the work. Sum this field for consumption. |
| The unit label. |
|
|
| The AI capability or tool invoked, for example |
|
|
| Caller origin: |
| The app or context that fired the call, for example |
| The backing service, for example |
| The invoking user, used for per-user attribution. |
| Groups the turns of one multi-turn conversation. |
| The MCP session identifier, which groups every call made in one session. An example MCP session includes:
Join on this field to reconstruct a tool sequence. Events that result from direct API tool calls, which don't require an MCP session, don't have a |
| Set when a Workflow triggered the call. Includes the workflow definition and the specific run. |
| Unique event ID. Use this with |
| When the call occurred. Use this for ordering and timeseries. |
For the AI-triggered Standard Function Call event type, see Understand and manage Standard Function Calls consumption (DPS).
You can use these DQL examples to query billing usage events.
fetch dt.system.events, scanLimitGBytes: -1| filter event.kind == "BILLING_USAGE_EVENT"| filter event.type == "AI Units"| summarize ai_units = sum(usage.quantity.billable), by:{tool, caller.type}
The following DQL query provides a grouped and sorted list of all AI-related billing events (AI Units, AI Function Standard Calls, and AI-generated query events) within the last 24 hours.
fetch dt.system.events, scanLimitGBytes: -1, from: -24h| filter event.kind == "BILLING_USAGE_EVENT"| filter in(event.type, array("AI Units", "AI Function Standard Call"))or (in(event.type, array("Log Management & Analytics - Query", "Events - Query", "Traces - Query", "Digital Experience Monitoring - Query")) and ai_generated == true)| sort session_id, conversation_id, timestamp asc
session_id result from direct API tool calls, which don't require an MCP session.execute-dql, generate multiple billing usage events: an AI Function Standard Call and a query event (ai_generated == true, representing the data scanned). These events are linked by the same session_id and conversation_id.The following DQL query shows the AI calls that make up one conversation, sorted in order.
fetch dt.system.events, scanLimitGBytes: -1| filter event.kind == "BILLING_USAGE_EVENT"| filter event.type == "AI Units"| filter isNotNull(conversation_id)| dedup event.id| sort timestamp asc| summarize turns = count(), aiUnits = sum(usage.quantity.billable), skills = collectArray(tool), by:{conversation_id}| sort turns desc
The following DQL query shows the ordered AI Units and AI Function Standard Calls belonging to one specific workflow execution.
fetch dt.system.events, scanLimitGBytes: -1| filter event.kind == "BILLING_USAGE_EVENT"| filter in(event.type, array("AI Units", "AI Function Standard Call"))| filter isNotNull(workflow.execution.id)| dedup event.id| sort timestamp asc| summarize steps = count(), sequence = collectArray(tool), by:{workflow.id, workflow.execution.id}| sort steps desc
You can query insights via the Environment API - Grail Query. Example DQL queries are provided in Query billing usage events with DQL.
No, only tools that invoke LLM reasoning are charged by AI Units.
It depends on the tool. If an external agent calls a non-LLM-based tool (for example, execute-dql) through the MCP server without the driver LLM performing any reasoning, no AI Units are consumed. Only a Standard Function Call and, where applicable, query consumption are billed.
No. If you ask Dynatrace to only generate a query without executing it, only the AI Units for the generation step are billed. No Standard Function Call or query consumption is incurred.