Rime’s Prism keeps a text checkpoint inside a spoken conversation

Rime launched Prism on 28 October with an unusual division of work: the model listens to audio, writes its intended response and keeps listening while speaking. Software can inspect or rewrite the text before it becomes sound.[1]

Rime says decisions are conditioned on the audio itself, retaining information such as hesitation or laughter. Software can therefore apply business rules without making a transcript the model’s only view of the caller. The text checkpoint also supports pronunciation control and tool management. Self-service reinforcement-learning and supervised fine-tuning APIs are still being developed with beta customers.[1]

What happens while a tool runs

The published Python SDK guide separates the conversation from the application’s work. Prism requests a named tool with structured arguments; the application validates them, executes the operation and returns its result. An order lookup, for example, still depends on the application’s connection to its records.[2]

Developers can specify a short spoken message while a tool runs, let Prism generate one from the tool description, or suppress that filler. Slow operations must run without blocking the event stream, so the application can continue receiving speech.[2]

Interruption also has a physical boundary. The conversation runner stops affected playback and reports how much audio was actually played. The documentation distinguishes that measurement from bytes merely received or queued: a response generated by the model may never have reached the caller’s ears.[2]

Report an error or suggest a correction