Show HN: Oodle.ai – $10 per million agent traces(oodle.ai)
oodle.ai
Show HN: Oodle.ai – $10 per million agent traces
https://www.oodle.ai/product/agent-observability
16 comments
"Oodle" to me will always be the compression library first and foremost, just like "pi" will always make me think first of the Raspberry Pi rather than the coding agent.
Perhaps someone should vibecode a product that allows AI developers to generate project names that don't come with confusing collision baggage.
Perhaps someone should vibecode a product that allows AI developers to generate project names that don't come with confusing collision baggage.
Dang that’s expensive. We pay $0.75/M through a vendor
We price per GB of ingested trace - $0.3/GB, goes lower as you scale.
Traditional APM spans are ~2KB - this would come to ~$0.6/million spans.
How we arrived at $10 is that we assumed each agent span is ~35KB. Which means 1M spans is ~35GB - which comes to ~$10. Agent spans are larger because they have large prompts.
If your LLM spans are smaller, the cost would be lower. For our customers we see this vary between 20-30KB, and we took a conservative 35KB number.
Traditional APM spans are ~2KB - this would come to ~$0.6/million spans.
How we arrived at $10 is that we assumed each agent span is ~35KB. Which means 1M spans is ~35GB - which comes to ~$10. Agent spans are larger because they have large prompts.
If your LLM spans are smaller, the cost would be lower. For our customers we see this vary between 20-30KB, and we took a conservative 35KB number.
disclaimer: I work at Oodle, posting my own perspective here.
Vijay and Kiran have both replied here in good faith. I like the fact that my bosses are nice, kind, and decent people.
I disagree with them about being nice to trolls.
All the past submissions from OP are for content hosted on a specific domain, which now redirects to another one: Surprise surprise! They sell "Telemetry Pipeline for AI-Era Data Volumes". So, a somewhat-competitor!?
OP, thanks for validation. When competitors write drive-by, unsubstantiated, undisclosed comments, that's good news!
Vijay and Kiran have both replied here in good faith. I like the fact that my bosses are nice, kind, and decent people.
I disagree with them about being nice to trolls.
All the past submissions from OP are for content hosted on a specific domain, which now redirects to another one: Surprise surprise! They sell "Telemetry Pipeline for AI-Era Data Volumes". So, a somewhat-competitor!?
OP, thanks for validation. When competitors write drive-by, unsubstantiated, undisclosed comments, that's good news!
Good to know. Could you share your vendor and capabilities and pricing page please?
Hi HN, Vijay here
Adding support for agent traces turned out to be a great learning experience - it pushed us to rethink and replace parts of our storage engine https://blog.oodle.ai/how-we-achieved-10-million-agent-spans...
Adding support for agent traces turned out to be a great learning experience - it pushed us to rethink and replace parts of our storage engine https://blog.oodle.ai/how-we-achieved-10-million-agent-spans...
Congrats on the launch! Oodle has made our life very convenient and this is another step in that direction
The self-promotion spam will continue until the community improves.
Just checked it out, looks like a good one. Congratulations
Why a "parquet-like" format and not just parquet?
We store these files on S3 and directly read them in the query path using lambda functions. Parquet would work as a storage format for logs and traces, but not for metrics. At oodle we built the metrics engine first, so we designed a hybrid row/column format with a more S3 friendly indexing strategy - fewer lookups required to locate relevant chunks within the file. The hybrid row/column format was necessary to store multiple "samples" in the same row. This also allowed us to get compression ratios in the order of 600x.
When we extended the engine to logs and traces, we took the approach of tweaking the same file format so that we could re-use a majority of the engine we had already built.
When we extended the engine to logs and traces, we took the approach of tweaking the same file format so that we could re-use a majority of the engine we had already built.
love oodle’s speed and the best in class mcp. excited to try out agent tracing and evaluate the accumulated failure patterns
Thanks varun! let us know what you think about surfacing agent failures automatically, happy to help with onboarding if that helps.
Over the past two years, we have built a columnar storage engine for observability: logs, metrics, and traces. Today, it's exciting for us to show what we've built on top of that foundation: LLM Agent Observability.
Given how non-deterministic agents are, storing all traces without sampling was critical for us. But these traces tend to be in the MBs, sometimes GBs - we needed to store them inexpensively. We also needed the queries and analyses to be fast. To meet both these goals, we store them in S3 in our own parquet-like file format, and query them using AWS Lambda.
Since we process each span of every trace, instead of running LLM-based evals on each, we first analyze them using deterministic techniques. We detect tool failures, retries, loops, abnormal token usage, latency regressions, schema violations, sentiment, and other production signals. We've written more about the approach here: https://blog.oodle.ai/you-cant-sample-your-way-to-reliable-a...
The combination of our own engine, no sampling, and deterministic processing before LLM-for-evals allows us to price at $10 per million traces, provide sub-second p99 query latency, and have healthy margins. Before building this, we used Langfuse for our own agent observability, which was 6x more expensive.
Still super early, and rough around some edges, we would love your questions and feedback!