> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.
# LLM observability
> Monitor your own AI workloads: model requests, token cost, latency and error rate, plus prompt analysis — and what it does not capture.
If your product calls a language model, that call is a dependency like any
other — except that it is slower, more expensive per request, and fails in ways
an HTTP status code does not describe.
LLM observability tracks those calls specifically.
**This is about *your* AI workloads.** For the AI features aiAxonIQ runs over
your telemetry — anomaly detection, forecasting, natural-language query — see
[AI features](/guides/ai/overview). The two are frequently confused.
## What is tracked
| | |
| :----------- | :------------------------------------------------------------- |
| **Requests** | Individual model calls, with model, latency and outcome |
| **Tokens** | Input and output token counts per request |
| **Cost** | Derived from tokens and model |
| **Latency** | Distribution, not just an average — the tail is the story here |
| **Errors** | Failures, refusals and timeouts |
The overview aggregates these; the request list is where you find an individual
call.
## Why it needs its own view
**A model call breaks the assumptions ordinary request monitoring makes.**
* **Cost varies per request** by one to two orders of magnitude, depending on
prompt and response length. Request count tells you nothing about spend.
* **Latency is measured in seconds**, and a p99 of 30 seconds may be normal
rather than an incident.
* **A `200` can be a failure.** A refusal, a truncation or an unusable answer
is a successful HTTP response.
Rate, errors and duration are still useful. They are just not sufficient.
## Retention
Individual request records are kept for **30 days**; rolled-up aggregates for
**90 days**. So per-request forensics has a one-month window, while cost and
volume trends go back a quarter.
## Prompt analysis
Prompts can be analysed for structure and quality. Useful when a change in
prompt template lines up with a change in cost or error rate — a connection
that is otherwise very hard to see, because the prompt is usually the thing
nobody versions.
## What it does not capture
**Answer quality is not measured.** Nothing here tells you whether a response
was correct, useful or hallucinated. Those need evaluation against your own
criteria, which is a different discipline from observability.
What this gives you is everything *around* the answer: how long, how much,
how often it failed, and which model.
**Be careful what ends up in a prompt record.** Prompts routinely contain
customer data — that is frequently the point of them. Telemetry is
append-only and retained for its full window, with no surgical delete.
Redact before it leaves your network if your prompts carry personal data.
See [Collector configuration](/send-data/otel/collector-config).
## A note on the eBPF agent
The zero-code agent natively decodes several GenAI APIs — OpenAI, Anthropic,
Gemini and Bedrock — at the network boundary. That is a second, code-free route
to seeing model calls, and it overlaps with this feature.
It is early access and not integrated with the views described here. See
[Zero-code instrumentation](/zero-code/overview).
## Availability
LLM observability is a plan feature. A request to it when it is not enabled
returns an explicit upgrade error rather than an empty view — see
[Plan limits](/concepts/limits#feature-entitlements).
## Next
The AI aiAxonIQ runs over your telemetry.
eBPF-observed AI-agent behaviour.
Alerting on cost and error rate.