Vaani Developer Platform: Voice Agents, Pricing and What to Check

Vaani has launched a self-service developer platform for voice AI agents, giving teams a way to configure conversations rather than commission a bespoke deployment. The useful question is how much control developers get when a call stops following the script, and what they pay while finding out.

What Vaani launched

Vaani founder Nitesh Tripathi set October 29 as the Developer Platform launch date in a post shared by the company. His explanation focused on the difficult parts of voice agents: call flow, interruptions and edge cases. A polished voice alone does not solve those problems.

The official product site now links to the agents platform and describes a self-service studio with a visual graph builder, prompt management, call review and evaluations. Developers can also work programmatically with agents, voices, conversational graphs and call data.

This changes the starting point for a small product team. Instead of treating a voice agent as an integration project first, it can begin with a narrow conversation and test the branches that make it useful. That does not remove the integration work. It makes the conversation itself easier to inspect before committing to a wider deployment.

Vaani voice-agent pricing

Vaani advertises its developer stack at ₹5 per minute, described as all-in. It separately lists standalone text-to-speech at ₹2.5 per 1,000 characters. These are different products and billing units, not two interchangeable prices for the same call.

At the listed minute rate, 1,000 minutes would cost ₹5,000. That is arithmetic from the advertised rate, not a tested invoice or a promise about a particular account's final bill. Buyers should confirm taxes, telephone-number charges, destination coverage and any other applicable conditions before budgeting a production rollout.

The more useful comparison is cost per completed task. A cheaper minute can still produce an expensive workflow if callers repeat information, abandon the call or need a person to restart it. Track completion, escalation and repeated attempts alongside the duration.

What to test before connecting real customers

Start with a workflow whose successful outcome is easy to verify, such as collecting a preferred appointment time. Build a test set containing corrections, interruptions, silence and an answer that does not fit the expected options. Then check whether the system preserves the caller's latest intent through those changes.

The developer documentation is the entry point for implementation. For evaluation, save both the intended outcome and the actual result of each test. A fluent transcript can conceal a wrong action, so listening to the call is only one part of checking it.

One particularly useful test is a caller changing a number halfway through a sentence. If an agent captures the first number confidently and ignores the correction, better voice quality will not fix the business error.

A platform launch is not a complete model release

Vaani's site lists voice synthesis as active, while voice recognition and voice reasoning remain in development. The self-service launch should therefore not be read as the release of every component in its research roadmap. Likewise, vendor latency claims are not a substitute for testing the languages, network conditions and integrations a deployment will use.

For teams building voice products, the opportunity here is a shorter path from a conversation idea to an inspectable workflow. The next thing to watch is whether that control survives real callers, where the important improvement is often a correctly handled interruption rather than a more impressive demo.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn launches and complex product workflows into clear stories developers can understand and share.

Book a 30-minute call.