Voice AI at roughly the cost of text.
NavGurukul has built an open-source speech-to-speech layer that runs inside the browser on the laptops organisations already have. Voice synthesis happens entirely on the machine, and recognition can too. Any organisation can pick it up and build voice into what they already do.
The people you serve can already hold a conversation.
Until now, that was the expensive way in.
Over 400 million Indians can't comfortably read a screen. Farmers, ASHA workers, daily-wage earners, first-generation learners. Every service built for them still arrives as text on a form, and the workaround is always the same: put a human in the middle, or leave them out.
Voice was the obvious answer and the priced-out one. At commercial rates, an organisation running 7,500 voice sessions would spend roughly ₹36 lakh on speech processing alone. More than simply paying people to do the work by hand. So voice stayed a demo, and never became infrastructure.
We hit this wall building learning tools for our own students, and spent a year engineering around it rather than accepting it.
How it works
Almost everything happens on the user's device. That single decision is what collapses the cost, removes the connectivity requirement, and keeps voice data private by default.
Audio is captured locally
The browser or app takes the microphone input. Nothing is uploaded.
Speech becomes text
Chrome's built-in Web Speech API recognises it at no cost. On Chrome 139+ this can run fully on-device.
Your model handles the conversation
Only text goes to the cloud. Plug in whichever LLM you already use. No lock-in.
Text becomes speech on-device
Piper TTS runs in-browser via ONNX Runtime, in an Indian-accent voice we trained.
Turn-taking is smoothed out
Voice activity detection and buffering keep pauses feeling like a conversation.
Nothing routes through our servers at any point. Speech synthesis is always local, and with Chrome's on-device recognition the audio stays on the machine too. That is what keeps DPDP compliance tractable, and what lets this survive a connection with two bars of signal. The speech layer adds under a second to a turn; how long the whole exchange takes depends on how fast your model answers, which in practice is two to three seconds.
See it work
A sandbox you can talk to yourself, and the full API documentation behind it. Open the demo on a laptop in Chrome, Safari or Edge, and allow microphone access when asked.
One thing you'll hear: a word occasionally clips at a sentence boundary while the system works out that you've finished speaking. We're tuning it. That's the honest state of V1, and we'd rather you met it here than three weeks into a pilot.
Where it fits
We built the layer for education because that is where our students were. The layer itself doesn't know anything about education. Wherever people would rather speak than type, and there's already a computer they come to for help, it applies.
Running in production today
Education and employability, built by our own teamAI Interviewer
Job-description-specific voice interview practice with structured feedback. Unlimited attempts, no mentor required.
1,663 sessions · 83% completionSocratic Tutor
Guides learners through breaking a problem down, catching reasoning gaps as they go rather than handing over answers.
108 learners · 981 hoursAbracadraw
A game that teaches people how to instruct an AI, by having them write prompts that recreate a target image.
22 government schools · 24 min avgAdaptive assessment
Question difficulty adjusts in real time, with audio playback so reading ability isn't what's being tested.
2,300+ learners · 34% use audioReady to be built
Places with a shared computer and a queue of people who'd rather talk than readFarmer service points
At an FPO office or Krishi Vigyan Kendra, spoken guidance on pest management, sowing windows, and which subsidy someone actually qualifies for.
Natural farming resource centres
Composting, seed treatment and crop cycles explained out loud, so practice knowledge travels without a printed manual.
Health sub-centres
Protocol refreshers and nutrition guidance for ASHA and anganwadi workers, at the shared machine already in the centre.
Common Service Centres
Explain a government form out loud and file the application by voice, rather than the operator filling it in on the applicant's behalf.
Gram sabha records
Turn a council meeting into a spoken summary on the laptop already in the room, so every member has a record of what was decided.
Self-help group meetings
Read the group's ledger and loan terms aloud, so every member can check them and not only the one who can read.
Banking correspondent counters
Scheme eligibility and plain-language financial guidance, spoken at the counter instead of handed over as a pamphlet.
Dairy collection centres
Vaccination schedules and animal health advice for farmers who already walk in twice a day.
The common thread is a machine people travel to rather than carry. That's the honest shape of V1, and it covers more of rural India than it first sounds: service centres, panchayat offices, school labs and collection points are where most people already go when they need something done.
What's actually been shipped
We'd rather show a small number that's real than a large number that's projected. Everything below is deployed and measurable today.
-
Open sourceThe full speech-to-speech library is on GitHub and published to npm as speech-to-speech, under the GNU General Public Licence. Free to audit, fork, and deploy.
-
Indian-accent voiceOur students called American-accented English "alien", so we trained a text-to-speech model on IISc's SPICOR dataset — 24,058 audio files, 49 hours — and published it on Hugging Face. It's the voice our own deployments use. The library also ships with the standard Piper voice set, so point it at our model rather than the default if you want the Indian accent.
-
Low-connectivity testedDeployed across 22 government schools in Dantewada, Chhattisgarh, on the kind of hardware and bandwidth those schools actually have.
-
5,000 usersIn production across NavGurukul's residential campuses and the Zuvy learning platform, with performance holding steady as concurrency grew.
-
Nine years behind itNavGurukul has run residential tech campuses since 2016, placed 1,500+ alumni in jobs, and reached over a million school students through refurbished-device labs.
Where this is today
This is V1, described honestly. You'd find all of it in the first fortnight of a pilot anyway, and we'd rather you knew before you committed a team to it.
-
Available now
English, on laptops
English in an Indian accent is the primary production language, running in Chrome, Safari or Edge on a laptop. It's what the demo uses and what today's 5,000 users are on.
-
Built, slower
Hindi
A Hindi speech-to-speech build and a fine-tuned Hindi accent model both exist and work. Responses currently land in three to five seconds rather than English's two to three, so we'd call it usable but not yet as polished. Ask us for the Hindi demo if that's your use case.
-
3–4 weeks
Other languages, on request
We train and ship a new language or regional accent in three to four weeks from the point we agree on it. Bengali, Marathi, Telugu, Tamil, Gujarati and Punjabi are the ones on our development list. Name yours on the first call and it can be ready before your pilot opens.
-
In research
Phones
Mobile performance isn't good enough to launch and we won't pretend otherwise. Where it gets to depends on how local speech models develop over the coming months, so we're not putting a date on it. Plan your pilot around a shared computer.
-
Being tuned
Turn-taking
A word occasionally clips at a sentence boundary while the system works out that someone has stopped speaking. Knowing when a person has finished talking is a genuinely hard problem, and this is where our current engineering effort goes.
Integrating it, in seven steps
Realistically this is a few weeks of work with our team alongside you, not a weekend. Here's the shape of it so you know what you're agreeing to.
-
Tell us who your user is
One call. If voice isn't the right answer for your problem, we'll say so.
-
Pick one workflow
One task, one language, one group of users. Narrow scopes ship; broad ones stall.
-
Run the sandbox
Install the library, point it at your own model key, and hear it work in a test build.
-
Set up language and voice
Launch on English, or name the language you need and we ship it in three to four weeks.
-
Wire it into your product
Your team builds the interface. Ours joins the integration reviews and unblocks you.
-
Pilot with real users
100 to 300 people on the machines they'll really use. Measure completion, comprehension, latency.
-
Scale, and send fixes back
What you fix upstream makes the layer better for everyone else building on it.
What it runs on
Built for the laptop, which is the machine that sits in school labs, panchayat offices and field centres and gets shared by everyone who walks in. There are two ways to run it, and the difference is where speech recognition happens.
Standard setup
- Chrome 25 or later, latest version recommended; Safari and Edge also work
- A working microphone. A headset helps in a noisy room
- Any modern laptop. A Core i3 with 8 GB of RAM is enough
- Smoothest on Apple Silicon; runs well on mid-range Windows and Linux machines
- Recognition streams audio to Google's speech service; the voice you hear back is generated on the machine
- Nothing to install, no GPU, no server
Fully on-device setup
- Chrome 139 or later, or local WebAssembly models
- 64-bit CPU with 4+ physical cores, 8 preferred
- 8 GB of RAM minimum, 16 GB recommended
- A GPU with 4+ GB VRAM helps, but a CPU fallback works
- 300–800 MB of free disk for cached voice models
- Works with no internet connection at all
Most partners start on the standard setup because it runs on hardware they already have, then move to on-device once they know which workflow matters. The application code is identical either way. Performance scales with the machine: synthesis is smoothest on Apple Silicon, and it runs well on mid-range Windows and Linux laptops.
Before you start
- Chrome, Safari or Edge. On Windows, macOS or Linux. Firefox handles the voice output but not the recognition, so it isn't supported.
- HTTPS. Microphone access needs a secure origin, so your site or app has to be served over HTTPS.
- Two response headers. Speech-to-speech needs Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp on your app. Worth checking early: they restrict third-party embeds and scripts, so an existing product may need adjusting before it can turn them on.
- Microphone permission. Your users grant it once, in the browser, the same way any call app asks.
- A language model key. Whichever provider you already use. Or ask us to run that side for you.
- One technical owner. Someone on your team who can install an npm package and stays with the project.
- No servers, no GPUs, no audio storage. There is no speech infrastructure for you to run or pay for.
What it costs
Nothing to integrate. This was built with philanthropic funding to be public infrastructure, not a product line, so we don't charge for access, for setup, or for the support that gets you live. The only money that changes hands is for compute you actually consume.
Open source under the GNU General Public Licence. No licence fee, no per-seat cost, no minimum commitment, nothing to renew. The obligations are copyleft and attribution, not money.
Paid directly to your model provider at their rates, for the text conversation only. We never sit between you and that bill, and we take no margin on it.
If you'd rather not manage a key, we can host that side and invoice you for metered usage only. [Placeholder: confirm rate card, billing cycle and minimum, or remove this panel.]
Two things sit outside this. Training a voice for a language we don't yet support takes three to four weeks of our team's time, and we'll tell you honestly what's involved before anyone commits. And if you want us to build the application itself rather than support you building it, that becomes a separate conversation.
Licensing and terms of use
The code is free, and the conditions attached to it are about keeping it that way. Any organisation deploying the layer signs a short terms of service covering four things.
- Sign the terms of service. A short agreement before deployment, covering the points below. We send it once you've decided to build. [Placeholder: link the signed ToS document here.]
- Attribute us on your platform. A visible credit to NavGurukul wherever the voice layer is used, and in the public materials describing the product.
- Share your usage data with us. Periodic reporting on how the technology is being used, so we can evidence the impact and keep the layer funded. [Placeholder: confirm the exact fields and reporting frequency.]
- Obtain your users' consent. You are responsible for telling the people who use your product what is being stored and shared, and for getting their consent, in line with the DPDP Act.
- Honour the GPL. Modifications and derivative works carry the same licence and stay open, with the original copyright and licence notices intact.
- Keep it open for the next one. Fixes you make to the layer itself come back upstream, so the organisation after you starts further ahead than you did.
The GPL is a copyleft licence, which means software you build on this layer and distribute carries the same obligations. If that creates a problem for how your organisation ships software, raise it on the first call rather than at the end. It's a conversation worth having early.
Questions we get asked
What does it cost to use?
The layer is free and so is the help getting you live. We don't charge for integration, setup or support, because this was built with philanthropic funding to be shared infrastructure. Your only running cost is metered model usage, around $0.10–0.20 per hour of conversation, paid to your own provider. If you'd prefer we ran that side, we invoice at cost with no margin.
Do we have to credit NavGurukul?
Yes. Attribution is part of both the GPL and the terms of service: a visible credit wherever the voice layer is used, plus a mention when you write or present about the work. Attribution is how the next organisation finds this instead of paying $5 an hour for the same thing.
What data do you want back from us?
Usage data on how the technology is being used: sessions, minutes of conversation, languages, completion rates. Reporting it is part of the terms of service, because those numbers are what we take to funders to keep this free. You are responsible for telling your own users what is stored and shared and getting their consent before any of it is collected.
Which languages work today?
English in an Indian accent is the primary production language. Hindi is built and working, though responses take three to five seconds rather than two to three. Any other language or regional accent is trained on request and ships in three to four weeks, so it's rarely the thing that holds a pilot up. One note on setup: the library defaults to standard Piper voices, so you point it explicitly at our Indian-accent model to use it.
What hardware does it need?
A laptop running Chrome, Safari or Edge, and a working microphone. On the standard setup that's it, and a Core i3 with 8 GB of RAM is enough; it's smoothest on Apple Silicon and runs well on mid-range Windows and Linux machines. Running recognition fully on-device asks more: four or more CPU cores, 16 GB of RAM ideally, and a few hundred megabytes of disk for cached models. Phones aren't supported in V1.
Where does the voice data go?
Never to us. Text-to-speech always runs inside the browser, so the voice your users hear is generated on their own machine. Recognition depends on the mode: the standard setup uses Chrome's Web Speech API, which streams audio to Google's speech service, while Chrome's on-device recognition keeps it entirely local. Choose the on-device path when your users' audio must not leave the machine.
Are we locked into a particular AI model?
No. The layer handles voice in and voice out and is deliberately indifferent to what sits in between. Use whichever model you already have a relationship with, and swap it later without touching the voice layer.
How fast does it actually feel?
The speech layer itself adds under a second: recognition is effectively instant and voice synthesis takes a few hundred milliseconds once the model is cached. What a user waits for is mostly your language model, so a full turn typically runs two to three seconds in English. Keeping replies to two or three sentences makes the biggest difference to how responsive it feels.
Does it really work offline?
The speech layer does, completely. The conversation logic still needs to reach a model, so full offline operation means running a local model alongside it. We've built toward that with offline laptop deployments, and it's an active area of work.
Who owns what we build together?
You own your application and its content. The layer itself is GPL, so it stays open and anything derived from it inherits that licence. Improvements you make to the layer come back upstream. If the copyleft terms sit awkwardly with how your organisation distributes software, say so early and we'll talk it through.
Tell us what you're trying to build
A short form, and a real person reads it. If there's a fit we'll set up a call within a week. If there isn't, we'll tell you that too.
Thank you — that's with us.
A person reads every enquiry. If there's a fit we'll come back within a week to set up a call, and if there isn't we'll tell you that rather than leave you waiting.
Or write directly to abhishek@navgurukul.org. Abhishek Gupta, CEO, NavGurukul Foundation for Social Welfare.