# Explain LLM spend per customer

> Find which customers, models, and agent runs are driving cost and failures.

Canonical page: https://anectico.com/docs/investigate/llm-spend/


Anectico connects LLM calls to the customer and application journey that caused them. This lets you
investigate cost as part of production behavior instead of only as an organization-wide total.

## Start with the organization view

Open **Agents → Agent Runs**, or open **Signals → Traces** and select **LLM Costs**. Compare spend, token volume, error rate,
latency, model, and customer.

Look for:

- one customer with unusually high request or retry volume;
- a model change that increased cost or latency;
- failed calls that were retried repeatedly;
- agent runs with many tool or model steps; and
- calls without customer identity.

Token volume uses OpenTelemetry's inclusive total: input plus output. Reasoning tokens
are already a detail subset of output, so the organization, model, person, time-series,
and by-agent views never add them a second time.

## Move to the customer

Open the customer from the cost view. Their timeline shows LLM calls beside surrounding events,
errors, traces, and replay. This reveals whether the cost came from legitimate heavy use, a retry
loop, a broken workflow, or abuse.

Select **Why?** beside the customer's LLM spend to ask Customer Detective for a cited explanation.

## Inspect an agent run

Open the run and review its span waterfall. Compare model calls and tool calls, identify repeated
steps, and inspect any linked replay or error.

## Missing or incorrect cost

Cost requires a recognized model or an explicit cost value plus accurate token counts. Customer
attribution requires active identity before the LLM span begins. See [Record LLM calls](/docs/instrument/llm-calls) for instrumentation requirements.

Organization pricing overrides are applied when an ingestion worker processes a span, with
organization rates taking precedence over global and built-in rates. Persisted costs are stable and
are not recalculated after an override changes; a span that was already queued uses whichever rate
is active when it is processed. Override propagation is asynchronous across ingestion replicas, so
verify changes with a newly processed call after the refresh interval.