MOSS-Live accepts 16 kHz audio and does not pause the conversation to search

Most voice AIs still converse like walkie-talkies. First the person speaks; then the system recognizes the phrase, thinks, and responds. If it is interrupted midway, the answer often stops for good or starts over. In a live conversation, this quickly becomes frustrating: you cannot interject with “yes,” clarify a detail, or pause naturally while choosing a word.

MOSI Intelligence proposes a different approach. According to its developers, MOSS-Live keeps listening while it speaks, distinguishes a brief reaction from a command to stop, and can return to an unfinished sentence after an interruption. The API accepts 16 kHz audio as input and produces 48 kHz output. The connection runs over WebSocket, while images are transmitted as individual JPEG frames.

Not a queue of turns, but a shared stream

Imagine a voice assistant for an online store. It is explaining the return policy when the customer asks midway: “What if I already threw away the box?” A conventional agent will either keep talking over the person or forget its original answer. MOSS-Live is supposed to hear the clarification, answer it, and then return to where it stopped.

What matters is not the interruption effect itself, but management of the conversation state. The system must understand that “uh-huh” does not mean stop, that a pause within a sentence does not end a turn, and that a noisy conversation nearby is not directed at the agent at all. This is where voice products usually break down, even though speech synthesis and recognition already work reasonably well in isolation.

The developers also claim support for camera input, screen sharing, and ambient sounds. This makes it possible to build an assistant that not only hears the question but also sees the interface or object in front of the user. A technical-support agent, for example, could watch the screen and provide the next step by voice.

Two models instead of one pause

The architecture separates the fast conversational component from slower background work. The first continuously receives audio and images and maintains the dialogue. The second searches for data, invokes tools, or drafts a plan. Shared state connects them, so the conversation does not have to stop while a search is running.

A practical scenario might look like this: the user asks the system to find tickets, then discusses baggage restrictions while the background model checks the options. When the search finishes, the result is brought back into the conversation at the appropriate moment. For a product, this is more useful than a conventional loading indicator: the agent remains available, can accept a new constraint, and can adjust a task that has not yet been completed.

But this also introduces a difficult engineering problem. If the user changes the travel date while a background search is already running, the system must cancel the outdated task or mark its result as stale. Without state versioning, a polished continuous dialogue will confidently start returning answers to old requests.

What to check before integration

For now, MOSS-Live is available as a free beta. Pricing for future billing based on connection time has not been published. There are no model weights, and deployment is available only through the API. The documentation does not list every supported language; the demonstrations use English and Chinese, while Russian-language quality has not been stated.

There are also no public independent measurements of latency, interruption-detection accuracy, or noise robustness. It is therefore too early to compare the system with Gemini Live and GPT Realtime based only on demonstration videos. It is especially important to test false stops, recovery after a connection drop, the cost of a long session, and the behavior of background tasks when a request changes.

Developers would be wise to start with a narrow prototype: one scenario, several types of interruption, and a log of every state transition. A product should measure not only time to first audio, but also the share of interruptions handled correctly, the number of lost resumptions, and the time required to return a background result. If MOSS-Live passes that test, it could become the foundation for voice interfaces that feel less like a spoken chat and more like a real conversation partner.