That's a great idea. I am doing only application-level tracking but I agree hardware-level telemetry would be super helpful. Would love to learn more about how you think about it. Here's my email : deborah [at] botanu dot ai
Stealth | Founding Engineer (Distributed Systems) | San Francisco | ONSITE
We are building cost attribution and observability for AI workflows. We correlate application traces, model usage, and infrastructure costs to compute cost-per-outcome for each customer for AI systems so that AI teams can do outcome-based pricng.
We're looking for a founding engineer to build the core data platform: ingestion pipelines, cost computation, and analytics infrastructure that scales from thousands to millions of workflow runs.
You should have experience building distributed systems and working with OpenTelemetry traces and data pipelines. Experience with AI evaluation systems is a plus.
Comp: $150k + 0.75% equity.
If interested, send a short note and GitHub to deborah [at] botanu dot ai
Hi HN, I’m the technical founder of botanu (www.botanu.ai)
I started building this after repeatedly hitting the same problem on AI teams: we could see total LLM spend, but couldn’t answer “what did one successful outcome actually cost?”. In real systems, a single business event often requires multiple runs ex-retries, fallbacks, escalations, async workers etc., before it reaches a final outcome. Most tooling tracks individual calls, or at best single runs. That hides the true cost. botanu treats cost per outcome as the sum of all runs and attempts for an event, including failures.
How it works
-An event represents business intent
-Each attempt is a run, with its own run_id
-All runs are linked via a shared event_id
-A single outcome (success / failure / partial) is emitted for the event
-Total cost = cost of all runs for that event
-Run context propagates across services using standard W3C Baggage (OpenTelemetry).
I’m building this as part of a broader effort around outcome-based pricing for AI systems and understanding true cost per outcome. If you’re thinking about similar problems, I’d love to chat and compare notes.
Happy to answer technical questions or get critical feedback. Email- [email protected]
In big orgs, 'agents can build it' rarely changes the buy vs build decision. The pragmatic moat I see isn’t the code, it’s turning AI work into something finance and security can trust. If you can’t measure and control failure-cost at the workflow level, you don’t have software.
I’m building an OTel-based SDK that wraps the billable edges (entrypoint, LLM/tool clients, async publish/consume) and emits both traces for debugging and a lightweight event ledger for run/attempt lifecycle and call boundaries. I define the workflow + possible outcomes up front, then attribute all runs and attempts to the final outcome event to get the cost per outcome