How we engineered M1 for affordable, natural conversations

A voice has to hold up across an exchange: the opening question, a follow-up, a change of language, and a precise number read back. Hearing that sequence tells you more about the experience than a single polished sentence.

Talk to the Bakbak agent below. Ask what M1 costs, how quickly the first audio arrives, or switch to Hindi halfway through a question. Every reply is spoken by M1.

Prefer to listen first, or can't use a microphone right now? Switch to the recorded conversation and follow the transcript as it plays.

Before M1, we built and ran voice agents. Across nearly 20 million calls, we worked with commercial TTS APIs and open-source models, and none of them met everything a production voice agent needs at once. Those calls defined the four things M1 had to get right.

Saying a sentence well takes two separate jobs. The first is deciding how it should sound: where to pause, which words to stress, how quickly to speak, and how to move between languages. The second is producing the sound itself.

M1 gives each job its own component. The first reads the agent's reply and works out a compact plan for how to deliver it. The second turns that plan into speech.

Splitting the work keeps the model small. Each component only needs to be as large as its own job requires, so no capacity is spent where it isn't needed, and less work per reply means lower cost.

It also makes the voice easier to get right. Because the delivery plan exists before any audio is generated, the synthesis step already knows the intended phrasing and emphasis. It doesn't have to work them out while producing sound. That gives us one clear place to improve how natural M1 sounds and how faithfully it says the words.

Both components run inside the Bakbak inference runtime. A compact model only stays cheap if the path through it is efficient too, so we designed execution, memory handling, and streaming alongside the model.

Sounding natural isn't enough if the words come out wrong. A dropped time, a repeated phrase, or an odd pause can derail a simple exchange. M1 is designed to keep the intended words intact while phrasing them naturally, including in sentences that mix Indian languages with English.

Below are four failure patterns we watch for. Play the M1 response to hear how it handles each one.

These examples explain the issues. Broader evaluation tells us how often they happen. We score content errors separately from pronunciation and prosody, so we can see which part of a reply needs work.

The architecture sets the amount of work required to produce speech. The serving stack determines how efficiently that work runs on hardware.

We built Bakbak's inference runtime around short conversational replies, variable input lengths, and requests arriving throughout an active call. Our focus is useful throughput: serving more speech while keeping the time to first playable audio within a conversational latency budget.

A voice that works for one call also has to work when many calls run at once. As traffic grows, every caller still expects the reply to start quickly and play without gaps.

So we test M1 under load. As concurrent requests increase, we track how long the first playable audio takes, whether playback stays continuous, and how much speech the same hardware can produce. We watch the slowest replies, not just the average, because those are the ones callers notice.