Launched Drishti โ AI agent observability for Indian developers ๐ฎ๐ณ
I got tired of US tools showing my AI agent costs in dollars.
Every time I checked my bill, I was doing mental math: "$0.04 = โน3.3... wait, $0.12 = โน10?"
So I built Drishti (เคฆเฅเคทเฅเคเคฟ) โ India's first AI agent observability platform.
What it does:
โ Tracks every LLM call in โน (INR-native, no conversion)
โ Explains errors in Hinglish ("Yeh kya galti hai")
โ Alerts on WhatsApp when costs spike (email for now)
โ 2 lines of code to integrate
โ Open source core (MIT)
Free tier: 10,000 traces/month. No credit card.
I built this solo over 3 months. Would love feedback from anyone building with LLMs in India.
๐ https://drishtiai.dev
๐ฆ https://github.com/Harsh-0602/drishti-sdk
Update: just shipped the public dashboard demo โ you can see real traces,
โน costs, and the Hinglish error explanations in action here: https://www.youtube.com/watch?v=k8U_DwPs1Uk
The name Drishti is perfect for an observability tool โ monitoring what your AI agents are actually doing is half the battle. Curious how you're handling the cost/overhead of the tracing itself, since observability can sometimes become a bottleneck at scale.
Haha thanks! Drishti = "vision" in Sanskrit, so yeah โ pretty much born for observability ๐
Overhead โ SDK is fully async. Traces fire via a background thread, so zero blocking on your critical path. Ingest latency is <50ms typically, and if our servers hiccup or your network drops, your agent keeps running โ graceful failure by design.
That said, I won't throw a "it's 0.5% overhead" number at you because I genuinely haven't benchmarked it rigorously across different workloads yet. Early days, still measuring.
If you're curious, the SDK arch is pretty small and readable โ would love an honest roast: https://github.com/Harsh-0602/drishti-sdk
Nice launch. The localization layer is useful, but the thing I would test fastest is whether cost alerts catch repeat-tool loops before the bill shows up. For agent builders, a trace that says "same tool called 18 times with no new output, estimated โน cost so far" feels more actionable than a generic dashboard.
This is exactly the kind of feedback I needed. You're 100% right โ a generic dashboard that just says "you spent โน500 today" is useless. What I actually need to know is "your agent called the same tool 12 times with identical args and burned โน40."
Full transparency: loop detection isn't in the SDK yet. But it's been on my mind since day one. The Pro plan has a "model cost optimizer" but that's more about model selection right now, not runtime loop breaking.
What you described โ surfacing redundant tool calls in real-time with estimated โน burnt โ is literally the next thing I want to build. Probably a small middleware layer that tracks tool call signatures and breaks/flags loops before they drain the wallet.
I'm hacking on this solo, so might take a couple of weekends. Mind if I DM you when I have a rough version? Would love to test it against a real use case.
Yes, happy to take a look when you have it.
For a real-use test, Iโd try two fixtures:
The thing Iโd watch is not just total โน burned, but time-to-intervention. If the alert makes me stop the loop 90 seconds earlier, that is way more compelling than a prettier cost dashboard.
Iโm building adjacent usage visibility from the Mac side with TokenBar (https://tokenbar.site/), so this pain is very familiar. The strongest shared signal is probably: tell me before I feel stupid for checking the bill too late.
Hey John โ this is exactly the kind of real-use testing I need. Your two fixtures are now my north star.
Fixture 1: Loop detection middleware โ hashing tool call signatures (fn + args), flagging repeats >N with real-time โน burnt. Any edge cases I should watch for?
Fixture 2: Baseline tracking per model (cost + latency), flagging >2ฯ deviations. Also catching silent fallback to expensive models โ thoughts?
Time-to-intervention: Target is <30 sec. Current pipeline: email โ WhatsApp โ webhook. Auto-break vs alert-and-wait โ since you see this from the user side with TokenBar, what's your take?
Also โ "tell me before I feel stupid" is exactly the emotion I'm designing for. TokenBar nails it for users; I'm trying to do the same for devs before the bill hits production ๐
For me, currency conversion to INR has never been an issue.
The WhatsApp angle is a strategic move and is well-suited for India, given the countryโs high level of professional activity on the platform.
Hinglish is also a smart move, however, it is not a necessity.
It is worth considering the perspective of a customer. Would they be willing to pay for Hinglish conversations if they have no difficulty understanding English?
thanks for the detailed feedback!
Totally get your point โ many devs are comfortable with English. Hinglish is more about saving time and reducing friction during debugging (quick โyeh kya error haiโ vibe) rather than replacing English.
Appreciate the honest take โ helps a lot!
One thing I'd be careful with:
The interesting question may not be whether Indian developers prefer costs in โน.
It may be what problem they're actually hiring observability to solve in the first place.
Those can look aligned early on while leading to very different product decisions later.
thanks for the comment!
You're right, the real question is what problem Indian devs are actually trying to solve with observability.
Drishti is built for that โ INR-native costs, Hinglish error explanations, and WhatsApp alerts.
Would love to know what issues you've seen teams facing. Any patterns?
Makes sense.
Curious how you're planning to differentiate beyond localization once others start adding similar INR-first + chat-style UX layers.
valid points!
Localization is the entry point, but the real differentiation is deeper agent visibility โ every LLM call, tool step, memory lookup with exact โน cost + Hinglish explanations + instant WhatsApp alerts. These are all in 2 lines of code.
Long term focus is to make debugging and cost control dead simple for solo devs and small Indian teams.
What would make an observability tool actually sticky for you or teams you know?
That's actually where I stopped short earlier.
I don't think the interesting part is my answer to that question.
I think it's what answer ends up driving the product.
Happy to send over the fuller thought if useful โ just drop your email.