Arize AI Pricing: Plans, Span Limits, and Retention Costs
Arize AI pricing packages observability around three visible capacity limits: trace spans, ingestion volume, and retention. The Free and Pro plan cards publish fixed monthly allowances, while Enterprise uses custom capacity and can be SaaS or self-hosted. A useful estimate counts the spans created by each application run, the payload volume attached to them, and the retention period required for production analysis.
Arize AI pricing starts with telemetry capacity rather than a model token. The Arize AX pricing page publishes plan limits for trace spans and ingestion volume. It also lists retention and Signal issues. That makes the first budgeting job architectural: count how many spans one application run emits, then estimate how much data those spans carry and how long the team needs to keep it.
A single user request can open an agent trace containing two retrieval steps and a tool call before one LLM operation. The invoice shape follows that tree more closely than it follows the number of chat messages in the product. I would refuse any Arize estimate built only from monthly active users. It looks tidy in a procurement sheet and collapses as soon as an agent starts calling tools.
TL;DR
- Arize AX meters published plan capacity through spans and ingestion volume. Retention and Signal issues also have published limits.
- One application request may create several spans, so request count alone understates telemetry use.
- Free and Pro publish fixed allowances; Enterprise uses custom limits and adds a self-hosted option.
- Model inference and evaluator calls remain separate cost lines. Instrumentation work and telemetry operations do too.
The published plan structure
The public page lists three AX plans. AX Free includes 25,000 trace spans per month and 1 GB of monthly ingestion. It also includes 15 days of retention and 10 Signal issues per month. AX Pro includes 50,000 spans and 10 GB of ingestion. It also includes 30 days of retention and 25 Signal issues. The plan card displays "$50 per month" but gives no currency code, so procurement should preserve the displayed symbol and confirm the billing currency in the order flow.
AX Enterprise replaces the fixed span and storage limits with custom terms. Retention and Signal limits are custom too. It also lists SaaS or self-hosted deployment, while Free and Pro list SaaS. Users and evaluations appear as unlimited across the three plan cards. That word needs careful budgeting: an unlimited feature can still call a billable model or consume storage elsewhere.
The published allowances create multiple ceilings. A team can remain below 50,000 spans and still consume 10 GB because it records full prompts and retrieved documents along with model outputs and tool results. Another team can generate many small spans and reach the span allowance first. Use the first binding limit for the plan decision rather than choosing a tier from span count alone.
Spans are the operational meter
Arize's tracing concepts documentation defines a trace as a tree of spans. Each span represents one operation and can contain its input and output. Timing and metadata can appear on the span too. The documented span kinds include LLM, Tool, Agent, and Retriever. Chain, Embedding, Reranker, and Evaluator are also documented kinds. OpenInference attributes can also hold message content and token counts, along with model names and cost data.
That structure gives finance a workable estimate. Sample production traces and record the median and high-percentile span count per completed run. Multiply those values by expected run volume, then examine average serialized span size. Keep failed runs and retries in the sample. Evaluation spans also create telemetry.
A customer-support exchange that appears as one row in a product analytics dashboard may fan out into seven rows in the trace tree. Each retry adds an LLM span. Running retrieval a second time adds another Retriever span. LLM observability depends on that detail, but the same detail drives capacity consumption.
Ingestion volume and retention change the plan fit
Payload choices determine ingestion volume. Recording a model name and duration produces a small span. Recording the full prompt and five retrieved passages produces a much larger one when the span also contains a tool response and the final answer. Redaction may reduce sensitive content exposure, but its storage effect depends on what replaces the removed data and which attributes remain.
Retention sets the available investigation window. The public plan cards list 15 days for Free and 30 days for Pro. A defect discovered after a monthly release cycle may have already aged out of the Free window. Enterprise retention is custom, so teams should write the required investigation period into the quote rather than treating "custom" as a capacity promise.
The concrete budgeting worksheet needs monthly runs and spans per run for each workload. It also needs average bytes per span and required retention days. Split production from staging. Track experiments and continuous evaluations separately because their payload profiles differ. The engineer staring at a trace waterfall on one monitor should be able to reconcile its child spans with the usage counter on the other.
Evaluation and model charges sit outside the plan card
The Arize AX product documentation describes a workflow built around tracing and Signal. Evaluations and experiments complete that workflow. The pricing page lists evaluations as unlimited, which describes access to the AX capability. It leaves the inference economics of any evaluator model as a separate question.
An LLM-as-a-judge evaluation can call a model for every sampled trace. The model provider may bill those input and output tokens. Human review creates staff time. Self-hosted Enterprise deployment adds infrastructure and upgrades, plus backups and on-call ownership. Auto-instrumentation reduces setup work, while schema design and redaction rules still belong in the operating budget alongside sampling and dashboard maintenance.
I separate total cost into five lines:
- AX plan or Enterprise contract.
- Evaluator-model inference charged by the chosen model provider.
- Storage and compute required by a self-hosted deployment.
- Engineering time for instrumentation and sampling, including sensitive-field controls.
- Incident and quality-review time spent reading traces and evaluation results.
This accounting also prevents an observability purchase from absorbing unrelated model spend. AI agent observability explains what the traces reveal; the provider invoice explains what the traced model calls cost.
Capacity questions for an Arize quote
A useful Enterprise quote pins down the measurement rules. Ask which span states count toward the allowance and how dropped or malformed spans appear. Ask which payload bytes contribute to ingestion volume and what happens when a limit is reached. Confirm the retention period by project and the treatment of data after a downgrade or contract end.
For self-hosting, ask which components the customer operates and what telemetry Arize receives. Confirm which upgrades require downtime. The answer changes the labor and infrastructure line even when the product capabilities remain the same. For SaaS, confirm the data region and the process for deleting prompt and response payloads.
Sampling deserves a written decision. Head sampling can reduce span volume before a trace completes, which may discard the failed run the team needed. Tail-based rules preserve selected outcomes but add collector design and buffering. The cheapest telemetry policy can be the most expensive incident-review policy if it removes the evidence behind a production failure.
Arize controls and request-layer policy are separate
Arize AX observes instrumented application behavior and evaluates recorded traces. Its OpenTelemetry and OpenInference model is useful for debugging retrieval and tool calls. It also exposes model responses and latency, along with token use and quality. That is the job described by the plan's span and ingestion meters.
Request authorization is a separate control. An application may attach user identity to a span, but the trace records what the instrumented code emitted. A security team that needs an independent permit or redact decision before a model call may also need to deny the request. That requires a control in the HTTP request path. The architectural distinction is covered in DeepInspect vs Arize Phoenix.
Keep the policy layer outside Arize's span allowance unless the implementation deliberately exports policy records as spans. Treat an Arize trace as observability data. Independent enforcement evidence ties the supplied identity and active policy to a request decision.
DeepInspect
DeepInspect sits between authenticated users or agents and LLM endpoints for traffic deliberately routed through its HTTP proxy. It evaluates the identity context supplied by the calling application, applies the active policy, and records the decision before the request proceeds. It leaves Arize's span allowances and ingestion volume unchanged. Retention, Signal limits, and evaluator usage also remain unchanged.
The two products can share context without sharing responsibility. A DeepInspect correlation ID can travel into an Arize span so an engineer can connect the policy decision with the application trace. Arize remains the place to inspect the agent tree and evaluation results. DeepInspect remains the request-layer enforcement point and source of the per-decision policy record.
Book a technical deep dive at deepinspect.ai.