Salesforce introduced SOV-Transcribe-1 on November 12, 2026. It is an open-weight model for non-streaming speech recognition: recorded audio goes in and transcript text comes out. Optional instructions control writing style, while context can provide names and specialist vocabulary. The company publishes the model under Apache 2.0.
Control over transcription, with explicit boundaries
The central idea is to adapt transcription to a particular task. A verbatim record and cleaned-up reading text serve different purposes. Salesforce supports instructions for that choice and for formatting. This does not turn the result into a conversation summary or guarantee correct recognition of every name and number.
The company reports first place among open-weight models on Artificial Analysis for non-streaming transcription, and seventh overall, as of November 12. This is a dated publisher claim, not an independent SIExpo measurement or a guarantee for every language, microphone and conversation type.
What the technical card clarifies
The announcement rounds the model size to 26 billion total parameters and four billion active parameters. The card gives more precise figures: 26.6 billion total and 4.6 billion active, including the audio encoder. The active count does not mean the entire system needs only the memory of a small dense model with that parameter count.
The documented input is 16 kHz mono audio, with recordings tested up to 30 minutes. Listed languages are English, French, German, Spanish, Italian, Portuguese and Dutch. Bulgarian is absent. A multilingual architecture alone is not evidence of dependable Bulgarian transcription.
The card describes Transformers and vLLM support, with some integration still being upstreamed. A separate DFlash model supports speculative decoding. It is an auxiliary execution component, not another independent confirmation of accuracy. Open weights also do not amount to a managed service that requires no infrastructure work.
How to assess practical value
Hugging Face's task documentation describes ASR as conversion of speech into text and explains word error rate as an evaluation measure. Aggregate word errors are useful, but an application can depend on a single digit. Our editorial recommendation is therefore to evaluate important fields separately, rather than judging only whether a paragraph reads smoothly.
For technical dictation, a reasonable test set would contain similar-sounding terminology, punctuation and numbers. The same recordings should be compared under verbatim and cleaned-up instructions. Removing hesitations should not silently change factual content. This is a suggested evaluation plan; we have not executed the model or measured such an outcome.
A deployment decision should also distinguish output format from recognition quality. A correctly structured transcript may still contain an incorrect entity. Retaining the relevant audio segment for review can make failures easier to diagnose, provided the application's own data handling permits it.
The release broadens the options for teams that want to operate their own transcription process. Its usefulness ultimately depends on the actual language, acceptable errors, available resources and output checks, rather than one overall leaderboard position.
The cover is an AI illustration.
Editorial verification: 2026-11-14T07:32:28.965785+00:00.
