Reports and Analytics
Overview
Apinizer shows LLM usage, cost, and performance in the AI view of three screens. The same screens show the API Gateway in their API view.
| Screen | Menu | What the AI view shows |
|---|---|---|
| Dashboard | Analytic → Dashboard | The Overview: KPI cards, daily usage, provider distribution, hourly tokens and active alerts |
| Traffic | Analytic → Traffic | The AI traffic log, see Traffic |
| Metrics | Reports → Metrics | Five tabs: Performance, Cost & Consumers, Usage Reports, Security & Guardrails and Provider Health |
An API | AI switch at the start of the top bar selects the view. The switch appears only when both gateways are licensed; when only one is licensed, that view is shown. The AI view needs the AI Gateway module of your licence. Reports → Metrics also needs the Advanced Analytics module; Dashboard and Traffic do not.
The filters sit in the top bar of Dashboard and Metrics and are shared by their AI tabs. Traffic has the filters of the Traffic screen:
| Filter | What it does |
|---|---|
| Project | Only in Administration mode. A multi-select with All projects as the default; pick one or several projects. In a project's own menu the active project is fixed and the selector is not shown. |
| Environment | The environments of the selected projects. When several projects are selected, each environment shows in how many projects it exists. |
| Date range | The same picker as Traffic: quick ranges or a custom range. The default is the last 24 hours. |
| Auto-refresh | Manual (default), 1 minute, 3 minutes or 5 minutes. |
| Refresh now | Reloads the open screen or tab. |
The AI analytics screens (AI dashboard, reports, guardrail hits, cache efficiency, shadow usage, the AI analytics tab of an API proxy and the AI view of Traffic) open on an environment in this order:
- The environment you last chose in this browser for the same project (or in the Administration view).
- If there is none, the first environment that has an Elasticsearch integration.
- If there is none, the first environment.
The browser keeps your last choice. If the browser blocks site data, the screens use the second and third rules.
To the right of the tab bar, the page tells you where the open tab reads its data from: the Overview on Dashboard and the Performance, Cost & Consumers and Usage Reports tabs of Metrics show the time of the Last sync and a Sync now button, and Security & Guardrails and Provider Health show a Live badge (see Data Freshness). Only the open tab loads its data, so switching tabs loads the new tab's data.
Every report is scoped by project and needs the AI Analytics view permission:
- In a project's own menu, the reports show that project's data.
- In Administration, the Project filter lets you look at one project, several projects, or all of them. The By Project, By Deployment Type and By Team breakdowns, which compare projects, appear only here, and By Hierarchy needs exactly one project.
Deep-link directly to a Metrics tab with the gateway and tab query parameters (e.g. .../metrics?gateway=ai&tab=usage). The first tab, Performance, is the default and does not appear in the URL; switching to another tab updates the address bar automatically. Old links to the former AI Gateway → Analytics screen and to the former standalone screens (Usage Reports, Guardrail Hits, Cache Efficiency, Provider Health) redirect to the matching screen and tab.
When an A2A proxy publishes an agent directly (agent publishing mode), the incoming request is answered by a language model call made on Apinizer. The token usage and cost of that call are included in the reports and alerts on this page, and in the token limits.
Counting applies only to the agent publishing mode; proxies that forward the request to an external agent do not call a model themselves and are therefore not counted. MCP proxies also do not call a model during routing, so they are out of scope.
Counting starts from this version — past A2A traffic is not added retroactively to reports or quota consumption.
Data Freshness
The Overview on Dashboard and the Performance, Cost & Consumers, and Usage Reports tabs of Metrics read from a daily usage rollup, not from live traffic. A scheduled job refreshes it every hour, at five minutes past the hour, and today's figures include everything up to its last run. A report opened right after midnight UTC can therefore look empty for a few minutes — this is expected, not a data-loss symptom. A panel marked Live is the exception: it reads real-time traffic directly instead of the rollup. The Security & Guardrails and Provider Health tabs read live data end to end and show a Live badge next to the tab bar. The AI view of Traffic reads the live traffic log.
The right side of the tab bar shows where the open tab reads from:
- On the Overview and the three rollup tabs of Metrics: the time of the Last sync and a Sync now button. Hover the info icon for the next scheduled run. If the scheduled job is not active, the tooltip says so and the data refreshes only when you sync it manually.
- Sync now re-reads the traffic logs of the selected date range, up to 31 days, for all environments and rebuilds the daily usage data. Use it to fill days the scheduled run missed. A confirmation dialog warns that on large installations the sync can take several minutes and adds load to Elasticsearch. While it runs the button shows Sync is running…, a second sync cannot start, and a short cooldown follows each sync; the panels reload when it ends.
- The rollup counts whole days in UTC, so the selected date range widens to the days it touches. Live panels use the exact range.
The panels marked Live on the rollup screens are: Hourly Token Usage, Cache & guardrail rates, and the TTFT avg and Cache hit rate cards on the Overview; the TTFT avg and TPOT avg cards, Where request time goes, and Cache hit rate on the Performance tab; and Semantic cache efficiency on the Cost & Consumers tab.
Overview
The AI view of Analytic → Dashboard shows the Overview. It summarizes the selected projects, environment and date range.
KPI Cards
Six cards open the tab. Each shows the figure for the period, a short second line, and — when the previous period of the same length has data — a change pill and a small trend line:
| Card | What it shows |
|---|---|
| Requests | Total requests; below it, the average per day |
| Total tokens | Total tokens; below it, input and output tokens |
| Error rate | The share of failed requests; below it, the number of failed requests |
| TTFT avg (Live) | Average time to first token; below it, the average time per output token (TPOT) |
| Total cost | Total cost in USD; below it, the average per day |
| Cache hit rate (Live) | The share of requests served from the semantic cache; below it, the cost it saved when that can be estimated |
Daily Usage
A bar chart with one bar per day for the selected date range. Switch the metric with Tokens, Cost, or Requests. In Tokens, each bar stacks the Input, Output and Cached token series, so you can see how much of your traffic is served from the semantic cache instead of billed as fresh output.
Provider Distribution
The share of total tokens per provider in the selected range, with tokens and cost per provider. When one provider carries most of the traffic, a note suggests routing a share to a secondary provider to reduce failover risk.
Hourly Token Usage
A sub-daily chart with its own filter: Last 6 hours, 12, 24 or 48 hours. Marked Live: it reads real-time traffic, so it includes today. Use it to spot a spike or a cache-hit-rate change within the current day, without waiting for the next rollup. It loads separately from the daily chart — changing one does not refetch the other.
Cache & Guardrail Rates
Three Live rates for the period: Cache Hit Rate, Guardrail Trigger Rate and PII Detection Rate.
Provider Health and Active Alerts
Provider health lists each LLM provider with its status (Operational, Down or Unknown) and last measured latency. The Provider Health tab of Reports → Metrics has the full view. Active alerts lists recent quota soft-cap and hard-cap alerts, provider failovers and provider-down events, grouped when they repeat; All alerts → opens the alert list.
When any model has no price defined, a note under the Overview says its cost is calculated as 0 and links to the Models screen. See AI Cost Settings.
Performance Tab
This is the first tab of the AI view of Reports → Metrics. Four cards open the tab: TTFT avg (time to first token, streaming) and TPOT avg (time per output token, with the equivalent tokens per second per stream) — both Live — plus Requests (with the daily average) and Error rate (with the failed-request count). Below them are the Daily requests & tokens chart, a Cache hit rate bar (Live; the cached share and the cached and total request counts) and the Model breakdown table with each model's Share, Tokens and Cost.
The Where request time goes panel (Live) shows the average latency split:
Time spent in PII masking, content filters, and prompt inspection policies.
Measured in milliseconds (ms). Zero if no guardrail policies are active.
Time to receive the response from the LLM provider.
For streaming: first-token-time (TTFT). For non-streaming: full inference duration.
System overhead: serialization, network routing, caching lookup, etc.
Calculated as: total time - guardrail time - inference time.
A note under the bar states how many milliseconds the gateway adds on top of model inference and what percentage of the end-to-end time that is.
Latency Example
Total request time: 1200 ms
Breakdown:
├─ Guardrail Time: 50 ms (PII mask + content filter)
├─ Inference Time: 1000 ms (LLM response)
└─ Overhead Time: 150 ms (routing, serialization, etc.)
Cost & Consumers Tab
Shows the This month's cost card (the cost so far this month, with the note "A project has no AI budget of its own. Limits are set per consumer, API client, application or organization on Limit Plans."), the Cumulative cost this month chart (it has no budget line), Cost by model (tokens, cost and share per model), and the Top consumers table (by application, with requests, cost and error rate). When a model has no price, a note says unpriced (self-hosted) traffic is costed at $0 and links to the pricing screen. The former standalone Cache Efficiency screen now lives at the bottom of this tab:
A Live panel. How often the semantic cache served a response instead of calling the model — the cache hit rate, the cached and total request counts and the estimated cost saving from those hits — with a hit-rate trend and a per-LLM-Gateway table. A low hit rate on a proxy with repetitive traffic is a sign the similarity threshold may need adjusting.
Usage Reports Tab
This tab is the former standalone Usage Reports screen. It offers multi-dimensional usage and cost breakdowns, group drilldown, and XLSX export. It uses the project and date range selected at the top of the page.
The token and request totals on this tab come from the daily usage rollup. The rollup has no environment dimension, so the Environment filter does not change these totals. The only part of the tab that follows the selected environment is the warning band for skipped requests; see Requests Skipped Because the VectorDB Was Unavailable.
Four cards open the tab:
| Card | What it shows |
|---|---|
| Total Tokens | Tokens consumed in the period |
| Active Users | Users with at least one request; below it, Avg/User/Month |
| Top Consumer | The name of the heaviest consumer and its cost |
| Cost (USD) | Cost of the open breakdown; below it, its request count |
Requests Skipped Because the VectorDB Was Unavailable
When the count is above zero, the tab shows the warning band Requests skipped due to unavailable VectorDB. It counts the requests that continued without the vector layer of RAG or the semantic cache because the VectorDB was unavailable (fail-open). Check the VectorDB connection on the worker.
- When the selected environment has a readable Elasticsearch, the count comes from the traffic log. The traffic log records every skipped request, also when AI trace is off.
- Without a readable Elasticsearch, the count comes from AI trace records only.
- A RAG request that Apinizer blocks is a failed request, not a skip. The RAG policy blocks the request when the vector database cannot be reached. The band does not count it.
- After an upgrade, the count restarts from the traffic log. Skips that only AI trace recorded before the upgrade are not counted while the environment has a readable Elasticsearch.
Usage Dimensions
Reports can be broken down by:
| Dimension | Scope | Description |
|---|---|---|
| Person | Individual | Usage per consumer |
| Group | Team / Department | Usage per organization group |
| Organization Unit (OU) | Hierarchy | Usage per org tree node |
| Application | API Proxy | Usage per gateway rule |
| Model | LLM Model | Usage per model (GPT-4o, Claude-3, etc.) |
| Hierarchy | Organization tree | Parent organization total with sub-organization and consumer breakdown, over a chosen date range |
| Project | Project | Usage per API management project (Administration only) |
| Team | Consumer Organization | Usage per consumer organization (Administration only) |
| Deployment Type | Infrastructure | Cloud vs. On-Premise vs. Other (Administration only) |
Select a breakdown from the tabs below (see Breakdown Tabs) to view the corresponding table and metrics.
Key Metrics
Each breakdown is one table with these columns:
- Name — the row (person, group, application, model…); group and OU rows also show a member count
- Input Tokens, Output Tokens, Cached Tokens — token counts by kind
- Requests and Failed — number of calls and how many failed; a high failure rate is shown in red
- Cost (USD) — total cost in US dollars
- Share of Tokens — the row's share of all tokens in the table
A Total row closes the table.
Breakdown Tabs
By Person
Individual usage per consumer.
By Group
Usage aggregated by organization group. Useful for department-level cost allocation. Click a row to open a Group Members window with the usage of the group's members. If no consumer used in the period is mapped to an organization, the table says so, and the usage still appears under By Person, By Application and By Model.
By OU
Organizational unit (org tree node) usage. Reflects your company structure. Click a row to open the Group Members window for that unit.
By Application
Usage per API Proxy (gateway rule). Identify which integrations are using the most LLM tokens.
By Model
Cost and usage breakdown by LLM model. Helps identify which models are most expensive or frequently used.
- GPT-4o — 5000 requests, $250
- Claude-3-Sonnet — 2000 requests, $80
- GPT-4-Turbo — 500 requests, $150
By Hierarchy
Answers the question the other tabs cannot: what did this organization spend in total, including everything beneath it?
The tab shows your consumer organizations as a tree. Every row carries the total of its whole subtree — its own consumers plus every sub-organization below it — so a parent's figure always equals the sum of the levels under it. Expand a row to see its sub-organizations and, underneath them, its consumers one by one with tokens, cost and the budget that governs them.
One project. The hierarchy belongs to one project. In Administration with several projects or All projects selected, the tab shows "Select a single project to see the organization hierarchy." instead of the tree.
Date range. This tab has its own start/end date picker and an Apply button, because the report is normally pulled for a billing period ("last month", "the third quarter"). When you open the tab it starts from the date range of the page. The range is inclusive on both ends and may span at most 366 days; a wider selection is refused ("Choose a range of at most 366 days.") rather than quietly trimmed.
Consumer list. Consumers load when you expand their organization, not up front, so an installation with thousands of consumers still opens instantly. Fifty are shown at a time with a Show more consumers row underneath, and the Filter consumers box narrows the list by consumer name. A consumer who spent nothing in the selected range is still listed, with zeros — the tab answers "who is in this group and what did they spend", so a silent member must not disappear from the headcount.
Budget (tokens/month) column. Each row shows the monthly token limit that applies to it and where it comes from: the AI Token Limit limit plan assigned to the consumer or organization, or that of the nearest organization above it (shown as Inherited from). This is the nearest explicit limit, not the full runtime ceiling — for the exact effective limit of a single consumer, open its Limits tab.
Usage column. Shown only when the selected range stays inside one calendar month, because limits are monthly: comparing a monthly limit against a 90-day window would show 300% for a consumer who never exceeded anything. Outside a single month, and for rows with no limit anywhere in the chain, the cell shows a dash.
Two rows can appear alongside your organizations:
- No organization — consumers that belong to no organization, plus usage whose consumer record no longer exists (a deleted consumer, for example). Their spend is real, so it is shown rather than dropped.
- Anonymous traffic — AI traffic with no consumer identity. It counts towards the totals but is not counted as a consumer.
Unclassifiable rows. When an organization's parent cannot be resolved, that row is shown at the top level of the tree with an Unclassifiable label next to it; hover the label to read the reason. There are three: the parent organization is not visible in this project (it belongs to another project, or it was deleted), the parent chain loops back on itself, or the chain is deeper than the product allows.
The figures on these rows are correct and counted exactly once; only their position in the tree is uncertain. The spend is not dropped, because an organization quietly disappearing from the report is far worse than one shown at the wrong indentation. When you see such a row, fix that organization's parent link on the Consumer Organizations screen; once the link is valid the row moves back into place and the label disappears.
A consumer's spend — including its past spend — is reported under the organization it belongs to today. If you move a consumer to another organization, its earlier usage moves with it, so this tab can disagree with the By Group tab for that consumer. This is deliberate: it is the only way a parent's total can always equal the sum of the levels below it.
The environment filter at the top of the page has no effect on this tab. Like the other consolidated tabs, it reads the daily usage rollup, which has no environment dimension.
This tab reads the same daily usage rollup as the other report tabs, which is refreshed every hour rather than live. The current day is therefore incomplete until the next consolidation runs — see Data Freshness.
By Project
Cross-project usage summary, available in Administration. Useful for comparing project costs and resource allocation. It covers the projects chosen in the Project filter.
By Team
Usage by consumer organization (the team that owns the consumers), available in Administration. Reflects organizational consumption patterns.
By Deployment Type
Usage split between Cloud (Managed) (managed providers), On-Premises (Self-Hosted) (self-hosted models) and Other (Custom) (custom providers, whose location Apinizer cannot know), available in Administration. Useful for infrastructure planning.
- Cloud: OpenAI, Anthropic, Azure → 8000 requests, $400
- On-Premise: vLLM, Ollama → 2000 requests, $0 (self-hosted)
Time Range
This tab uses the shared date range filter at the top of the page — see Overview for the available windows and the current default. The rollup counts whole days in UTC (see Data Freshness). By Hierarchy has its own range picker.
Export to Excel
Click Download XLSX next to the breakdown tabs to download the open breakdown as an Excel file. The button appears for system administrators and for users with the AI Analytics export permission or the Analytics view permission.
- Includes all rows of the selected breakdown, using the project and date range selected at the top. The environment filter does not apply, because the rollup has no environment dimension
- By Hierarchy exports its tree for the range chosen in its own picker
- By Project, By Team and By Deployment Type export the projects chosen in the Project filter
Drilldown
Click a row in By Group or By OU to open the Group Members window with the members of that group or unit and their usage. Close it with Close. The other breakdowns have no drilldown.
Refresh
The tab reads the daily usage rollup described in Data Freshness. Use the page's Refresh now button to reload it, and Sync now to rebuild the rollup for the selected range.
Cost Display
Costs show in US dollars, with four decimals (for example $0.0500). All token counts are absolute.
Security and Guardrails Tab
A Live tab. It opens with cards for Total Guardrail Triggers, PII Detections, Jailbreak / Injection, Safety Bypass / System Leak, External Guardrail Blocks and External Guardrail Errors. Below them are the Guardrail Triggers per Day chart, Violations by Type, Guard / Provider Breakdown, the Content Safety Categories (AILuminate) panel and the Recent Security Events table, which you can filter by event type, action and LLM Gateway and export to XLSX.
How many requests were flagged or blocked by your guardrail policies (PII masking, prompt-injection guard, DLP, loop guard, off-topic guard, oversized guard), broken down by guardrail type and the action taken. Use it to spot a guard that's blocking too often — or too rarely. When Prompt Protection or Off-Topic Protection uses an external provider, rows also break down by provider (the built-in check or the external judge) and by verdict (blocked, timed out, errored, or skipped due to misconfiguration) — safe verdicts aren't included. Configure the guards this report reflects in Advanced Guardrails.
Content Safety Category Breakdown
The Guardrail Hits report also includes a Content Safety Categories (AILuminate) panel, breaking hits down by the same 14 built-in hazard categories described in Content Safety Categories (AILuminate). The category axis is intentionally bounded to those 14 codes (plus a catch-all bucket for anything else) rather than left open-ended, so the panel stays readable and a single mistagged rule can't blow it up. A category flagged as touching a GDPR Article 9 special category of personal data carries a visible badge here.
The panel respects the same project, environment, and — when you narrow the report to one LLM Gateway — proxy filters as the rest of this tab. It populates as guardrail hits carry a matching content-safety category label; until then it shows no data for the selected period, the same empty state as any other widget on this screen, not an error.
Category labels follow the interface language: the Turkish UI shows the category catalog's Turkish label when one is defined, otherwise the canonical English name, otherwise the raw AILuminate code (the same fail-soft chain used by the sibling Content Safety Categories catalog screen). Label lookup is scoped to the active project — if another project has redefined the same category code with a different display name, that project's label never leaks into this report.
The same 14 categories (plus the catch-all bucket) are also tracked as a Prometheus counter, alongside the action (block/flag) and the evaluation engine (built-in, built-in + external, or external-only) that produced the hit — useful if you want to alert on content-safety trigger volume, or chart it outside this screen, without exporting from the report itself.
In addition to the usage/cost visibility on this page, see AI Asset Inventory (a separate, standalone screen) to check whether the AI assets in your installation use only the models and targets you registered.
Provider Health Tab
A Live tab. Each LLM provider connection reports a live status — Healthy, Down, or Unknown — with its last measured response latency. This is the same latency data that feeds least-latency routing, so you can see why a request went to one connection over another.
- The cards at the top count the Healthy, Down and Unknown providers and show the average latency of the healthy ones. A selector narrows the list to All, Down, Healthy or Unknown.
- A background job checks every provider every 5 minutes; the tab shows "Auto-check every 5 min" and the time of the last check. Users who can manage AI configuration also get a Check now button for an instant test.
- The table lists each provider with Status, Latency, Last check and Uptime 7d. Select a provider to see its endpoint, the models in use, the latency of the last 24 hours, the uptime of the last 7 days and the recent checks.
- A provider answers Unknown when it has not been checked yet or exposes no standard health endpoint.
AWS Bedrock and Google Vertex AI connections currently show as unhealthy here regardless of actual availability — the periodic check doesn't yet support their provider-native signing. This doesn't affect chat or embedding traffic through those connections; see LLM Providers and Models for details.
Traffic
The AI view of Analytic → Traffic shows the AI-aware raw traffic log. It uses the filters of the Traffic screen — environment, date range and an auto-refresh selector for short-interval reloads; see Traffic. To follow a single request end-to-end, see Tracing and Replay.
Each row presents one request through the gateway in AI-first columns:
- Status · Time — the HTTP status badge with the request timestamp
- Request — the HTTP method, the LLM Gateway name, and the proxy's relative path
- Model — the provider and the model that served the request; the upstream endpoint address is shown below, shortened to the host plus the last path segment (hover for the full address)
- Consumer — the consumer name and its IP address
- Tokens — input and output token counts, with the cached-token count below when the provider reused context
- Cost — the request cost calculated from AI Cost Settings
- TTFT · TPOT — time to first token and time per output token; a full semantic-cache hit shows
cacheinstead of a measurement - Latency — the total duration with a stage bar breaking it into guardrail, inference, and overhead time
- Flags — badges for detected PII, semantic-cache hits, requests blocked at the gateway, guardrail hits, and streamed responses
The address is deliberately recorded without its query string, so a value that could carry a credential — such as an API key passed as a query parameter — never ends up in a traffic record. This is also why Azure OpenAI's api-version query parameter, described in LLM Providers and Models, never appears in the recorded address even though it was part of the actual request.
Record Detail Drawer
Choosing Detailed View from a row's menu opens a detail drawer on the right side of the screen. Its header shows the merged status (for example 200 Success), the method, and the route; the summary card below shows the API Proxy, project and environment, relative path, endpoint, creation time, and correlation id. The content is organized into tabs:
- Overview — request, client-connection and server-connection details, routing information, routing diagnostics (including a phase-timing bar for upstream selection and time to first byte), canary state, data-transfer sizes, and a performance waterfall of the request pipeline, backend routing, and response pipeline stages. When policy execution timing is enabled in Log Settings, per-policy durations appear here as well.
- Request from Client / Request to Target API / Response from Target API / Response to Client — the headers, parameters, and body of each hop of the request, with Base64 decode and XML/JSON formatting actions on the body.
- LLM Insights — all AI-specific data in one place: route, provider, model, token counts, cost, cache hit, TTFT and TPOT, the stage-latency breakdown, a PII alert when personal data was detected in the request, and a raw usage/meta table.
Row details open only while Enable API Traffic Log Details is turned on in the general settings.
Outbound MCP Tool / A2A Skill Calls
The LLM Insights tab of the detail drawer also shows which MCP tools or A2A skills/agents the proxy called outbound during that request — this is recorded whether tracing is on or off (previously it was only visible while tracing was active).
- The MCP Details section shows Outbound Tools Called (tool names deduplicated in first-seen order, comma-separated, truncated at 256 characters — never mid-name) and Outbound Tool Call Count (the raw total call count, including repeats)
- The A2A Details section shows the equivalent Outbound Skills/Agents Called and Outbound Agent Call Count — if an A2A target has no skill name, the agent key is shown instead
The count accumulates every call made across all turns of the same request in an agentic loop. Calls rejected by a guard or a quota are included too — the point of this audit trail is to show which tool a call attempted to reach.
AI Analytics Tab of an API Proxy
The AI analytics tab of an LLM Gateway has its own Environment selector. All AI cards on the tab follow the selected environment, because Apinizer reads them from the traffic log of that environment.
- If the selected environment has no Elasticsearch integration, or Apinizer cannot read it, the tab shows a warning that the Elasticsearch integration is not configured. The cards are empty. Apinizer does not show the values of other environments.
- The warning band Requests skipped due to unavailable VectorDB does not show on this tab. It shows only on the Usage Reports tab of Reports → Metrics (AI view). See Requests Skipped Because the VectorDB Was Unavailable.
- The refresh button next to the Live badge reads all reports of the tab again. Click it to see requests that arrived after you opened the tab.
Troubleshooting
No Data in Reports
- Confirm that requests have been sent through the AI Gateway
- Check that you are in the AI view of the screen
- Check that the date range includes the time of your requests
- Verify that the Project and Environment filters include the traffic, and that you have the AI Analytics view permission. By Project, By Team and By Deployment Type appear only in Administration, and By Hierarchy needs a single project
- Today's figures on the rollup tabs include traffic up to the last hourly run; click Sync now to refresh them (see Data Freshness)
Cost Shows $0
- Confirm per-model pricing is configured in AI Cost Settings
- Prices are stored in USD; if all models have price = 0, cost is $0. Unpriced models are flagged by a note on the Overview and on the Cost & Consumers tab
- New pricing changes apply to requests after the change; historical logs are not recalculated
Latency Breakdown Shows All Zeros
- Confirm guardrails or inference policies are active
- First few requests may not have latency data; try again after 5-10 more requests
- Check that the LLM provider is responding in reasonable time
Export File Is Empty
- Confirm you have the permission to export (system administrators, or the AI Analytics export or Analytics view permission)
- Verify the date range contains data
- Click Sync now first to rebuild the daily usage data for the range
Next Steps
Set limits based on report insights
Configure pricing and currency display
Manage provider credentials
Follow an individual request end-to-end
Configure the guards behind the Guardrail Hits report
Configure the cache behind the semantic cache efficiency panel