希望 OpenLess 可以考虑新增一个 Soniox ASR provider，优先支持最新的实时模型 stt-rt-v5。
我最近在中英文混合输入场景里实测了一下，stt-rt-v5 的识别效果明显比我之前用过的百炼/豆包相关模型更稳，尤其是中英文混说、专有名词、口语断句和噪声环境下的可用性，感觉很适合 OpenLess 这种语音输入工具。
Soniox 官方资料里几个对 OpenLess 比较有用的点：
stt-rt-v5 是 2026-06-16 发布的新实时 STT 模型，当前状态为 active。- 官方 changelog 写到它相对
stt-rt-v4 提升了 60+ 语言的实时转写准确率、噪声鲁棒性、多语言/口音识别、speaker separation、semantic endpointing、数字/日期/邮箱/ID/code/name/address 等结构化内容格式化。
- 它兼容现有 Soniox Real-Time API，升级方式只是把请求里的
model 换成 "stt-rt-v5"。
- Real-Time API 走 WebSocket，官方示例 endpoint 是
wss://stt-rt.soniox.com/transcribe-websocket。
- 原始 PCM 也支持，例如
audio_format: "pcm_s16le", sample_rate: 16000, num_channels: 1，这和语音输入类 app 的流式音频链路比较好对接。
- 支持
language_hints、language identification、endpoint detection、context / terms，可对应 OpenLess 现有的中英场景和词典/热词需求。
相关文档：
一个最小可用的适配形态可能是：
- Settings 里新增 Soniox ASR 选项。
- 凭据只需要
SONIOX_API_KEY / API Key。
- 默认模型填
stt-rt-v5，允许用户自定义 model string。
- 默认用
pcm_s16le + 16000Hz + mono 或沿用当前 recorder 输出格式做转换。
- 如果 OpenLess 现有词典/热词可以映射到 Soniox
context.terms，那会很加分；第一版不做也可以。
这个 provider 对中英文用户应该挺有价值，尤其是经常中英混说、说技术词、产品名、代码名的人。
希望 OpenLess 可以考虑新增一个 Soniox ASR provider，优先支持最新的实时模型
stt-rt-v5。我最近在中英文混合输入场景里实测了一下，
stt-rt-v5的识别效果明显比我之前用过的百炼/豆包相关模型更稳，尤其是中英文混说、专有名词、口语断句和噪声环境下的可用性，感觉很适合 OpenLess 这种语音输入工具。Soniox 官方资料里几个对 OpenLess 比较有用的点：
stt-rt-v5是 2026-06-16 发布的新实时 STT 模型，当前状态为 active。stt-rt-v4提升了 60+ 语言的实时转写准确率、噪声鲁棒性、多语言/口音识别、speaker separation、semantic endpointing、数字/日期/邮箱/ID/code/name/address 等结构化内容格式化。model换成"stt-rt-v5"。wss://stt-rt.soniox.com/transcribe-websocket。audio_format: "pcm_s16le",sample_rate: 16000,num_channels: 1，这和语音输入类 app 的流式音频链路比较好对接。language_hints、language identification、endpoint detection、context / terms，可对应 OpenLess 现有的中英场景和词典/热词需求。相关文档：
一个最小可用的适配形态可能是：
SONIOX_API_KEY/ API Key。stt-rt-v5，允许用户自定义 model string。pcm_s16le + 16000Hz + mono或沿用当前 recorder 输出格式做转换。context.terms，那会很加分；第一版不做也可以。这个 provider 对中英文用户应该挺有价值，尤其是经常中英混说、说技术词、产品名、代码名的人。