deborahjacob

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

Yes, we are building both

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

What’s your approach to end-to-end AI cost attribution (model + infra + data) for agents in production?

Location: NYC, New York, USA

Remote: Yes. Open to hybrid and in-person

Willing to relocate: Yes

Technologies:

Languages: Python, C++, Java, HTML/CSS, JavaScript, SQL, NOSQL

ML Tool: Numpy, Pandas, Scikit-learn, Matplotlib, OpenCV, NLTK, PyTorch, Hugging Face, LangChain

Technologies/Frameworks: Angular, Typescript, Flask, Spring Boot

Developer Tools: AWS, GCP, Docker, Git, Bash, Jenkins, Kubernetes, Kafka, Linux

Résumé/CV: https://www.linkedin.com/in/deborah-shekinah-jacob-003606a3/

Email: [email protected]

Count–Min Sketch requires each input to pass through multiple independent hash functions, which is computationally expensive. The workaround is to use a single hash function but use part of its output to split values into one of many buckets hence, simulating a situation in which we had m different hash functions. This costs nothing in terms of accuracy but saves computing many independent hash functions. This procedure is called stochastic averaging and has a predictable bias towards larger estimates. Durand-Flajolet corrected this bias using an algorithm called LogLog. HLL uses a different type of averaging. Instead of the geometric mean used in LogLog, Flajolet et al. proposed using the harmonic mean. https://engineering.fb.com/2018/12/13/data-infrastructure/hy...

I am interested. I worked as a Software Engineer/ ML Engineer for 5+ years and I recently graduated with a MS CS from NYU Courant.

Location: New York, US

Remote: Yes

Willing to relocate: Yes

Techonolgies: Python, C++, PyTorch, Typescript, AWS, DOcker , Kubernetes, ML

Resume: https://www.dropbox.com/scl/fi/koghbqojfjj7zravh6tto/AI_Debo...

Email:[email protected]

I am a recent MS in Computer Science graduate from NYU Courant with 5+ years of experience in software development and machine learning.