Prerequisites

What has to be true

Requirement	Detail
API Management in front of your models	The check reads APIM gateway diagnostics. Traffic that bypasses the gateway is invisible to it.
Diagnostics sent to Log Analytics	Both categories below, pointed at a workspace.
Log Analytics Reader	On that workspace. Read access is sufficient throughout.

The two diagnostic categories

Table	Category	Default
ApiManagementGatewayLogs	Gateway logs	Commonly already on
ApiManagementGatewayLlmLog	LLM logs	Off

The LLM category is the one that is usually missing. It is enabled separately from gateway logging, and without it there is no token data, so there are no economics to establish.

Turning on LLM logging

In the Azure portal: your API Management instance → Monitoring → Diagnostic settings → Add (or edit) a setting → select the LLM logs category → send to your Log Analytics workspace → Save.

Then wait. Diagnostic data is not retroactive: the check can only see traffic from the moment the category was switched on. If you enable it today, run the preflight tomorrow and give it a few days before drawing conclusions about weekly shape.

Why the check reports this instead of assuming it

A workspace that has never received a category does not contain an empty table. It contains no table at all — so a query against it fails to resolve and returns an error rather than zero rows.

That error looks like a broken vendor kit. It is a configuration fact, it is knowable before anything else runs, and reporting it is the preflight query's entire job.

What it costs

Running the queries costs nothing. Log Analytics does not charge for queries on the Analytics plan — you are billed for what you ingest and retain, not for reading it.

Enabling the LLM logs category adds ingestion, billed at Azure's published Log Analytics rates like any other diagnostic data. These are metadata rows — model, deployment and token counts — and they stay small because capture of prompt and completion content is a separate setting the kit tells you to leave off.

This page will not quote you a monthly figure. It would be wrong for your commitment tier, your region and your retention, and a number we cannot stand behind is what this kit exists not to produce. Measure it against your own workspace:

Usage
| where TimeGenerated > ago(30d)
| where IsBillable
| where DataType in ("ApiManagementGatewayLogs", "ApiManagementGatewayLlmLog")
| summarize IngestedGB = sum(Quantity) / 1024 by DataType, bin(TimeGenerated, 1d)
| order by TimeGenerated asc

Multiply the daily figure by your workspace's rate in the Azure pricing calculator.

If your estate is very large

Preflight reports how many requests each table holds in the selected window. On a high-volume estate, narrow the window before running the heavier queries. A query that reaches the Log Analytics result limit returns a truncation error, and that error reads as a broken kit rather than as an estate too big for a thirty-day pass.

Start at seven days, confirm the shape, then widen. Nothing in the check depends on a particular window length: every query declares its own at the top, and the workbook takes it from the time range you pick.

Removing it afterwards

Delete the imported workbook. If you enabled a diagnostic setting only for this check, revert it. Nothing else was changed.