Investigate
Explain LLM spend per customer
Find which customers, models, and agent runs are driving cost and failures.
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 Explore → Agent Runs, or open Explore → 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 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.