TripleCloud Blog

AI tax on ordinary telemetry

Agentic apps emit mixed traces: heavy LLM spans interleaved with just as many ordinary ones - HTTP, DB, queues, infra. Most tools bill the whole stream at the premium AI rate, so your observability cost grows with the number of agents and tool calls - with your success, not with the value of the data. Here's the fix: price AI data as AI data, and everything else as plain telemetry.
An agentic app emits a stream of spans - LLM calls interleaved with just as many ordinary infrastructure spans - all flowing into one observability bill.

Anatomy of the AI tax

Two kinds of span live inside a single trace. An AI (LLM) span - any span carrying LLM-observability attributes, whether it's the model call, a tool call, a retrieval, or an eval - is the one that goes through AI-specific processing: parsing the prompt and completion, enrichment, scoring. That work is real, and it's what the premium pays for. An ordinary backend span - an HTTP call, a database query, a queue operation - carries none of that AI payload and needs none of that processing.

The billing mistake is charging the premium rate across every span in the trace, indiscriminately: the premium is fair on an LLM span, but you pay the same AI price for the ordinary HTTP span sitting right next to it.

And modern agentic apps don't emit one span per request. A single user task fans out into many spans - the planner call, every tool call, every sub-agent, every retrieval - LLM and ordinary alike. So the more widely an app unfolds a task into a trace, the more ordinary spans get charged at the AI rate. This isn't a problem of data volume - it's the premium AI rate applied to every span without distinction.

Flat AI billing
All 10 spans billed at the AI rate.
Typed billing
5 AI spans at the AI rate; the 5 non-AI spans drop to plain telemetry — ~45% cheaper on the same trace.
The same 10-span trace, costed two ways — bar length is cost, not span count. Illustrative rate (AI processing ≈ 10× plain telemetry), not the pricing-table methodology.

What the same workload actually costs

Say a trace of 10 spans has 5 LLM spans. The other 5 are ordinary spans - HTTP requests, database queries, queue operations.

Now scale that to 5M traces a month.

If every span is priced as an LLM span, your bill is computed against 50M premium LLM spans. But if the line is drawn correctly, only 25M spans need the special price. The remaining 25M are billed as plain telemetry.

On top of that, plenty of traces carry no LLM spans at all - and you still want them on hand the moment an incident starts. Priced the old way, those ordinary traces are either billed in full at the AI premium, or they push you onto a second observability platform that has no notion of AI spans in the first place.

In money, that's roughly the difference between €1,575 and €3,631 a month on the very same heavy workload (see the table below) - purely because of where the billing line is drawn.

The problem isn't that LLM spans are expensive. The problem is that you pay the same heavy premium for the ordinary spans sitting next to them.

Why LLM-observability pricing is the real problem

When you're charged by the number of spans you send, observability becomes a variable cost that grows with your success. Every new user, every more capable agent making more tool calls - all of it inflates the bill. One way out is to send less (sample traces, drop payloads, truncate prompts), but during an incident you often need all of the data.

This is made worse by where token prices are heading. As models get cheaper, teams lean on LLMs more heavily in their apps - industry spend on AI APIs has more than doubled in under a year, and most teams plan to grow it further. Cheaper tokens mean more telemetry, and pricing every span the same way quietly turns that growth into your cost problem.

When does this start to bite?

It's worth pausing as soon as your agents make several tool calls per task, monthly telemetry crosses ~100 GB, you keep full prompts and responses (for debugging, evals, or compliance), or sampling isn't an option because you need every trace.

The fix: stop paying an AI premium for plain telemetry

A simple change breaks that billing model.

Price AI data as AI data, and everything else as plain telemetry. Accepting and storing a span is cheap; the expensive part is the AI-specific work - parsing prompts and completions, enrichment, scoring. There's no reason to run that premium processing on the 5 of 10 spans that were never about the model. Pay the AI rate only for AI spans, and the premium stops scaling with the total number of spans.

How this looks with TripleCloud

This cost model is exactly what we built TripleCloud around:

  • Ordinary spans aren't priced as AI spans - no LLM-observability premium on infrastructure telemetry.
  • Your traces - ordinary and LLM alike - are stored in the open Parquet / Iceberg format, so retention is cheap too.
  • No need for a second observability platform - send your ordinary logs and traces too; TripleCloud handles regular observability signals, not just LLM ones.
  • Bring your own storage - prompts and responses can stay in infrastructure you control.
  • OpenTelemetry-compatible - point your existing OTel pipeline at TripleCloud and start by sending traces.

Comparing TripleCloud against other LLM-observability platforms:

Monthly volume TripleCloud Langfuse Core
Small - 10 GB · 50k traces €16 €65
Medium - 100 GB · 500k traces €158 €416
Large - 1,000 GB · 5M traces €1,575 €3,631

Public pricing, July 2026 (trace ingest + retention only; eval scores not modeled; €1 ≈ $1). Workload: 1 trace = 10 spans (5 AI + 5 ordinary), 20 KB per unit. Langfuse Core is priced on its published graduated per-unit tiers, billed on 11 units per trace (its 10 spans plus the trace itself). Competitors are shown at the retention each plan includes - Langfuse Core 90 days; TripleCloud at 90-day hot retention. Compared against managed plans.

TripleCloudLangfuse Core
Monthly cost (€) against monthly trace volume — the same three data points as the pricing table above. The gap widens with volume: per-event-priced tools scale their premium across every span.

That works out to up to ~2x cheaper than per-event-priced tools at scale on the Large profile - by the public list prices, with no sampling, because full-fidelity retention is no longer the thing that costs you. Your numbers will vary with span size and volume.

At TripleCloud we're not only trying to make observability cheaper. We want to change how you type the signals you ingest in the first place.

Run your own bill through our pricing calculator.

TripleCloud is rolling out with its first teams now; join the waitlist and we'll reach out to help solve your specific problem.

FAQ

How does TripleCloud's billing differ from Langfuse?

Same job - LLM tracing - but a different cost model: Langfuse prices per unit, so it bills every ordinary span as an LLM span. TripleCloud charges the AI rate only for AI spans and keeps traces in open Parquet / Iceberg - on the Large profile that's ~2x cheaper on retention.

Aren't self-hosted competitors cheaper?

Self-hosted Langfuse can be cheaper on licensing, but it moves the cost into your own infrastructure and ops. Instead of running ClickHouse yourself the way self-hosted Langfuse needs, TripleCloud gives you an open format (Parquet / Iceberg) and bring-your-own-storage - without the operational overhead of the observability layer itself.

Do I need a complex migration to move to TripleCloud?

No. TripleCloud is OpenTelemetry-compatible: point your existing OTLP pipeline at TripleCloud and send traces there in parallel with your current tool. Migrate the volume that hurts on cost first, and leave the rest in place until you're ready.

Will the request to retrieve traces be fast enough during an incident?

Yes. IceGate, our open-source query engine, skips most files by Iceberg metadata and Parquet statistics before reading anything, and metadata caching plus prefetching brought attribute-value lookups down from tens of seconds to about one second in our tests.

What if I need evals and prompt management?

Eval scoring is on our roadmap; prompt management isn't planned yet. TripleCloud solves the cost of tracing and storage - if a full prompt workflow is critical to you, keep your current tool and point the cost-heavy volume at TripleCloud.

How do you handle PII / secrets in prompts?

IceGate, the engine behind TripleCloud, is open-source and self-hostable (Docker / Kubernetes), and data is stored in open Iceberg / Parquet on your own S3. So prompts and responses stay in infrastructure you control - which also helps with data residency and compliance.

Trademarks and disclaimer

Trademarks. Apache®, Apache Iceberg™, Apache Parquet™, and Apache Arrow™ are trademarks of The Apache Software Foundation. Langfuse is a trademark of Langfuse GmbH. Amazon S3® is a trademark of Amazon Technologies, Inc. Kubernetes® is a trademark of The Linux Foundation; OpenTelemetry is a trademark of the Cloud Native Computing Foundation (CNCF) / The Linux Foundation. Docker® is a trademark of Docker, Inc. All other product names, logos, and brands are the property of their respective owners. Names are used solely for identification and comparison and do not imply affiliation, sponsorship, or endorsement by the trademark holders.

Disclaimer. IceGate and TripleCloud are not affiliated with or endorsed by Langfuse, The Apache Software Foundation, Amazon Web Services, the Cloud Native Computing Foundation (CNCF), Docker, or any of the other companies mentioned here. All pricing comparisons reflect our reading of publicly available price lists as of the publication date, model trace ingest and retention only, and may not account for the latest plans, discounts, or configurations. Your costs will vary with span size, trace volume, and retention. Corrections and clarifications are welcome - we'll fix any inaccuracies.

Sign in to save this post