A million agent spans is not a price

Oodle launched its agent-observability product on July 14 with a prominent offer: agent traces “from $10 per million spans.” The public calculator underneath that headline uses a different billing unit, charging $0.30 for each gigabyte ingested. That distinction matters because teams send bytes to an observability system, and a million spans can contain very different quantities of data.

A span is one timed record within a trace, such as a model call or tool call. Agent spans often carry prompts, model responses, tool inputs and outputs, identifiers, and session context, so their size changes with the application and its instrumentation. A team can replace assumptions with a useful comparison by exporting one representative day, measuring actual span sizes, and converting every candidate plan into dollars per gigabyte and dollars per million spans.

Agent spans grow with the context they carry

Traditional application performance monitoring spans usually describe an operation with names, timestamps, status, and relatively small attributes. In the Launch HN discussion, Oodle said traditional APM spans are about 2 KB. That is the vendor’s estimate, not a standard that every APM deployment follows.

Agent instrumentation can add much larger fields. Oodle’s engineering post lists user and system prompts, model responses, tool calls, user and session identifiers, and evaluation data among the information its customers want to inspect. Its product page likewise says prompts and tool calls create large metadata. A short classification call and a long research run may each produce one model span, yet the second can carry far more text and tool data.

The OpenTelemetry generative AI semantic conventions help teams use common names and structures for model and agent telemetry. That improves instrumentation portability and makes vendor changes less disruptive. The conventions do not fix the number of bytes in a span, decide whether prompts should be captured, set retention, or define the queries a team will run.

A million spans can mean 20 GB or 250 GB

Oodle explained the headline arithmetic in its Launch HN reply. The company prices ingestion at $0.30/GB, assumes about 35 KB for the “$10 per million” claim, and says customer agent spans commonly vary between 20 and 30 KB. At decimal units, one million spans averaging 35 KB contain 35 GB, which costs $10.50 at the published rate. “From $10” is therefore a rounded marketing expression based on an assumed payload size.

The table below is illustrative arithmetic using decimal KB and GB. Only the 20 to 30 KB customer range and the 35 KB headline assumption were attributed by Oodle; the 100 and 250 KB rows show how larger payloads change the bill and are not claims about Oodle’s observed distribution.

Scroll sideways to see all 3 columns.

Average span size	Data in 1 million spans	Ingestion at $0.30/GB
20 KB	20 GB	$6.00
30 KB	30 GB	$9.00
35 KB	35 GB	$10.50
100 KB	100 GB	$30.00
250 KB	250 GB	$75.00

This conversion is simple: with decimal units, one million spans averaging S KB contain S GB. Multiply S by the per-GB ingestion rate to get the ingestion cost per million spans. For any plan quoted per million spans, divide that price by S to get its effective price per ingested GB at your measured average.

Average size is necessary for the budget because billing follows total bytes, but it can hide expensive tails. A p95 of 250 KB shows that span sizes reach 250 KB near the top of the measured distribution, even if many small spans keep the average near 30 KB. Track both average and p95, then break bytes down by span type so one verbose tool or model call does not disappear inside the aggregate.

Retention and evaluation remain separate costs

Ingestion is only one line in an observability estimate. Oodle’s current calculator shows $0.30/GB for ingestion, $0.001/GB per month for retention, and $0 for unlimited queries. At its default example of 40 GB per day and 90-day retention, it displays 1,200 GB of monthly ingestion for $360, $2 for retention, and a $362 monthly total. Treat those figures as current vendor pricing and calculator behavior, not as a universal total-cost quote.

A comparison should put every plan into the same cost categories: ingestion, retained storage, queries, users, exports, support, and any minimum commitment. Ask each vendor which bytes it meters, whether compression changes billable volume, when retention charges start, and what happens to costs during traffic spikes. Those details can change the total even when two ingestion rates look similar.

Evaluation adds another meter. Deterministic checks can validate JSON, required fields, tool selection, latency, token limits, and known failure patterns with ordinary code. LLM judges add model input and output charges, orchestration work, and possibly storage for scores and explanations. Estimate those calls separately from trace ingestion because the same stored span may receive no judge, one judge, or several.

Oodle’s July 9 sampling post mentions roughly $1 per million “observations.” The source does not define a conversion between an observation and a span, so that figure does not belong in a span-pricing comparison. Keeping unlike units separate prevents an apparently precise estimate from combining different events.

Store broadly and spend evaluation budget selectively

Random sampling reduces both storage and evaluation volume, but it can discard the rare failures that make traces valuable. Oodle argues that unusual tool loops, frustrated conversations, latency outliers, and subtle failures are unlikely to appear reliably in a small random sample. That is a reasonable risk to test against your incident history, though it remains the vendor’s position.

Storage policy and evaluation policy can be set independently. A team may retain every trace for a short period while running inexpensive deterministic checks over the full stream. Sentiment or anomaly signals can then direct LLM judges toward a smaller subset, followed by longer retention for incidents, policy-sensitive runs, or traces selected for investigation.

Oodle proposes applying expensive LLM judges to a targeted 5 to 10 percent after cheaper filters. That range is a design claim, not a guaranteed optimum. Your useful rate depends on failure frequency, workflow risk, judge price, and the recall of the filters. Measure how many known failures the filtering sequence catches before adopting its percentage as a budget assumption.

One representative day turns pricing into comparable units

Choose a day that contains normal traffic, expected peaks, and the agent workflows that materially affect volume. Avoid a quiet weekend, a load test, or a launch incident unless that condition is what the budget must cover. Export telemetry in the serialized form sent to the observability backend, while confirming with each vendor whether its billable-byte definition matches what you can measure.

For every span, record its serialized byte size and type, then calculate the total count, total bytes, average bytes, and p95 bytes. Group the same measures by model calls, tool calls, retrieval, and orchestration spans. Inspect which fields dominate the payload, especially prompts, responses, tool results, retrieved documents, stack traces, repeated session context, and high-cardinality attributes.

The field review has a security purpose as well as a cost purpose. Prompts and tool payloads may contain customer records, credentials, internal documents, or regulated data. Identify fields that require redaction, hashing, omission, or shorter retention before calculating the final production volume. A cheaper telemetry plan does not justify collecting data the team should not store.

Scale the measured day into monthly ingestion with an explicit traffic assumption rather than multiplying blindly. If weekday and weekend traffic differ, weight them separately. Add growth and incident headroom as visible assumptions, and keep the measured baseline beside them so reviewers can see which part came from production data and which part came from planning.

The buying decision should use the same workload for every option

Send each vendor the same measured inputs: spans per day, gigabytes per day, average and p95 bytes per span, retention periods, expected query behavior, user count, export needs, and evaluation volume. Convert byte-priced plans into cost per million spans at your average size. Convert count-priced plans into effective cost per GB, then add retention, queries, seats, support, and evaluation.

Performance claims deserve a workload-specific trial too. Oodle advertises full-trace storage and less than one-second p99 queries. Its engineering post says a common seven-day customer query improved from 60 seconds to under two seconds after database changes. Both are vendor-reported results, so test your own common and worst-case queries against your payload distribution, retention window, and concurrency requirements.

Cost is one part of the build-or-buy decision. A managed product may reduce the engineering work required for ingestion, indexing, access controls, retention enforcement, query tooling, and incident support. An internal system may offer tighter data handling or fit an existing telemetry stack, while leaving your team responsible for operating and evolving it. Compare the full work required to meet your needs alongside the storage line.

Two related questions deserve their own treatment. Our guide to AI observability and output quality explains how infrastructure health and evaluation fit together, while our agent analytics article covers customer and workflow outcomes. Trace-storage economics still starts with byte measurement.

If you need help turning a production sample into an implementation decision, BaristaLabs can connect the analysis to process automation and run an agent-observability cost review. The work begins with your telemetry rather than a vendor headline.

Export one representative day. Calculate average and p95 bytes per span, identify sensitive fields, choose retention, estimate the cost of deterministic checks and LLM judges, and then compare building with buying on the same measured workload.