Motivation
External dictation clients need incremental transcription without waiting for a complete recording. A model name containing “streaming” and a bundled mlx-audio dependency do not by themselves establish an externally supported realtime STT route.
At Nativ 70a3c4b7a5fed58de945ff7ce467178733c77f16, the Python overlay extends the mlx-vlm app. Before adding routing, we should agree how realtime STT belongs in that lifecycle and avoid assigning conflicting semantics to an existing realtime route.
Proposed boundary
After mlx-audio's Nemotron live-input capability is implemented and tested, adopt a proven compatible dependency and expose its STT contract through Nativ's existing server lifecycle. Reuse model residency and authentication ownership. Do not create a second unmanaged server or require a new fixed port.
Publish a deterministic model capability/readiness response. Clients should fail clearly for unsupported models rather than fall back to file transcription.
Required contract and proof
Agree the path and model selection; authentication and network binding; accepted PCM rate/channels; session update, append, commit and cancellation semantics; delta/final/error events; queue bounds; concurrent residency; teardown and timeout behavior. Prove actual server startup, a streamed utterance, incompatible-model rejection and coexistence with batch STT/TTS. Measure finalization latency for clients with a five-second final-event drain.
Non-goals
No Nativ UI redesign, OpenClaw implementation, local façade changes or claim that an endpoint is already supported. This issue is a route/lifecycle ownership proposal, dependent on the separate mlx-audio capability.
Maintainer question
Where should realtime STT be exposed in Nativ's existing server, and is adopting mlx-audio's session contract the preferred direction?
Motivation
External dictation clients need incremental transcription without waiting for a complete recording. A model name containing “streaming” and a bundled mlx-audio dependency do not by themselves establish an externally supported realtime STT route.
At Nativ
70a3c4b7a5fed58de945ff7ce467178733c77f16, the Python overlay extends the mlx-vlm app. Before adding routing, we should agree how realtime STT belongs in that lifecycle and avoid assigning conflicting semantics to an existing realtime route.Proposed boundary
After mlx-audio's Nemotron live-input capability is implemented and tested, adopt a proven compatible dependency and expose its STT contract through Nativ's existing server lifecycle. Reuse model residency and authentication ownership. Do not create a second unmanaged server or require a new fixed port.
Publish a deterministic model capability/readiness response. Clients should fail clearly for unsupported models rather than fall back to file transcription.
Required contract and proof
Agree the path and model selection; authentication and network binding; accepted PCM rate/channels; session update, append, commit and cancellation semantics; delta/final/error events; queue bounds; concurrent residency; teardown and timeout behavior. Prove actual server startup, a streamed utterance, incompatible-model rejection and coexistence with batch STT/TTS. Measure finalization latency for clients with a five-second final-event drain.
Non-goals
No Nativ UI redesign, OpenClaw implementation, local façade changes or claim that an endpoint is already supported. This issue is a route/lifecycle ownership proposal, dependent on the separate mlx-audio capability.
Maintainer question
Where should realtime STT be exposed in Nativ's existing server, and is adopting mlx-audio's session contract the preferred direction?