Sokuji: Two-Way Speech Translation for Meetings, On-Device or via Cloud Providers

The problem Sokuji targets: one conversation, two languages, no interpreter

A bilingual meeting has a structural problem that a normal translator app does not solve. Translation is not one-directional. If you set a tool to translate English into Japanese, the Japanese speaker's replies come back untranslated, so someone has to switch the direction manually, usually mid-sentence. Sokuji's README frames the product around exactly this: set Language A and Language B, capture system audio and microphone together, and the app auto-detects which language is being spoken and translates it into the other. The repository describes this as two-way translation for bilingual meetings, with live subtitles that can be shared by screen so the other side reads along.

The intended user is not a professional interpreter. It is a person who regularly sits in calls where the other participant speaks a different language and who wants to keep the call inside Zoom, Teams, Meet, Discord or any other app rather than move to a dedicated interpretation platform. The desktop build is described as working with any app that has microphone input, including games and OBS; the browser extension is scoped to web-based meeting platforms such as Google Meet, Teams, Zoom, Yandex Telemost, Discord, Slack, Gather.town, Whereby and Jitsi Meet. Same features, different reach, according to the install table.

Two delivery targets and one shared pipeline

The architecture visible in the README is a capture, transform, playback loop. Audio enters from two sources: the local microphone and system audio. It passes through speech recognition, then translation, then text-to-speech, and the translated voice is emitted back into the meeting. The Mermaid diagram in the README shows a single branch point after capture: either a cloud provider or on-device AI, and both converge on the same translated-voice output.

The cloud branch lists OpenAI, Google Gemini, Palabra.ai, Kizuna AI, Doubao AST 2.0, Soniox, Zoom AI and OpenAI-compatible endpoints, nine providers in total per the provider table. The local branch is described as ASR, then translate, then TTS, running fully offline with no GPU requirement. The README attributes the local path to WASM and WebGPU, and states that model downloads are cached in IndexedDB with a one-click download flow.

The two-way auto-detection feature carries an attribution worth reading carefully. The README states it is powered by Soniox two-way mode, with 60+ languages and 3,600+ language pairs. That is a provider-specific claim sitting inside a feature description that otherwise reads as a general capability of the app. If you intend to use auto-detect, the documentation as given points at Soniox as the mechanism, not at the local inference stack.

What the local inference path actually promises

The local mode is the part of Sokuji that is hardest to replicate with an off-the-shelf tool, so it deserves scrutiny. The README gives concrete counts: 44 ASR models made up of 23 offline, 10 streaming and 11 WebGPU models, naming Whisper, Cohere Transcribe, Voxtral and Granite Speech; 75 translation models, described as 69 Opus-MT language pairs plus 6 multilingual LLMs including Qwen 2.5, Qwen 3, Qwen 3.5, Hunyuan-MT 1.5 and TranslateGemma; and 137 TTS models across 53 languages spanning Piper, Piper-Plus, Coqui, Mimic3, Matcha, MMS, VITS and Supertonic engines. Language coverage is listed as 99+ for speech recognition, 55+ for translation and 53 for text-to-speech.

Those three coverage numbers do not match, and that is a real constraint rather than a footnote. A pipeline is limited by its narrowest stage. If your pair is supported for recognition and translation but not for TTS, the local path cannot produce translated speech for it, only text. The README does not publish a per-language support matrix, so the only way to know whether a specific pair survives all three stages is to check the model lists in the app. The claim that no expensive GPU is needed is also unquantified: WASM and WebGPU inference on integrated graphics is a different performance envelope from a discrete GPU, and the README gives no latency figures for either the local or cloud path.

Installing Sokuji and building it from source

For end users there is nothing to compile. The Releases page carries platform packages: `Sokuji-x.y.z.Setup.exe` for Windows, `Sokuji-x.y.z-arm64.pkg` and `Sokuji-x.y.z-x64.pkg` for Apple Silicon and Intel macOS respectively, and `sokuji_x.y.z_amd64.deb` plus `sokuji_x.y.z_arm64.deb` for Debian and Ubuntu. The browser extension is distributed through the Chrome Web Store and Microsoft Edge Add-ons, and the README also documents a Developer Mode route: download `sokuji-extension.zip` from Releases, extract it, open `chrome://extensions/`, enable Developer mode, click Load unpacked and select the extracted folder.

Building from source is a four-command sequence in the README. Clone the repository, `cd sokuji && npm install`, then `npm run electron:dev` for development or `npm run electron:build` for production. There is no mention of a separate configuration step, environment file or API key requirement before the app runs, which is consistent with the claim that local inference needs no key. Cloud providers would require their own credentials, but the README excerpt does not enumerate those config keys, so treat provider setup as something to confirm in the app rather than something documented here.

Where Sokuji is the wrong tool

Three cases stand out. The first is latency-sensitive interpretation. Simultaneous interpretation in a legal, medical or diplomatic setting depends on bounded, predictable delay, and the README publishes no latency budget for any provider or for the local stack. The second is any use where a single provider dependency is unacceptable: the two-way auto-detect feature is documented as Soniox-powered, so an organisation that has standardised on a different vendor, or that needs to run fully offline with auto-detect, has no documented path to that combination.

The third case is licensing. Sokuji is AGPL-3.0. If you want to embed its translation pipeline in a proprietary product, or offer a modified version as a network service, the AGPL's source-availability obligations apply to that modified version. That is not a defect in the project, but it rules out a class of adopters that a permissively licensed library would not. Anyone evaluating Sokuji as a component rather than as an end-user application should read the licence text itself rather than rely on this summary.

A fourth, softer limitation: the README's own install table says desktop and extension have identical features, yet the extension is scoped to web meeting platforms while the desktop app reaches anything with mic input. The parity claim is about feature set, not about reach, and the reach difference is the one that decides which build you install.

How it differs from OBS plus a translation plugin

The closest thing to a free alternative for this problem is not another translation app. It is the assembly route: route meeting audio through a virtual audio device, run speech recognition in one tool, translation in another, and feed the result back as a microphone. OBS with a translation plugin, or a chain of separate STT and TTS utilities, can approximate parts of what Sokuji does.

The difference in approach is integration versus assembly. Sokuji ships the capture, recognition, translation and synthesis stages in one binary or one extension, with a provider selector in between and a shared model-download cache for the local path. The assembled route gives you more control over each stage and lets you swap any component, but you own the audio routing, the direction switching and the failure recovery yourself. Sokuji's auto-detect is precisely the part that assembly makes hardest, since a hand-built chain typically has to be told which direction to translate. That said, the assembled route does not carry AGPL-3.0 obligations, and it does not tie two-way mode to a single named provider. If those two constraints matter more than convenience, the assembly route is the honest comparison, not a competing app.

Maintenance cost and release cadence

The release history shows v0.40.3 on 2026-09-07, v0.40.2 on 2026-09-05 and v0.40.1 on 2026-09-05, with the last push to the default branch on 2026-09-10. Three patch releases inside three days, and the 0.40.x version number, indicate an actively changing codebase rather than a frozen one. For an end user that is mostly good: fixes arrive quickly. For anyone who builds from source and patches it, it means rebasing against a moving target, and the README's build instructions (`npm install`, then `npm run electron:dev` or `npm run electron:build`) give no guidance on pinning or on how the local model catalogue is versioned relative to the app.

The model catalogue is the other maintenance surface. With 44 ASR, 75 translation and 137 TTS models listed, the download and cache layer is a substantial part of the product, and the README states it uses IndexedDB caching with one-click downloads. Cache invalidation behaviour when models are updated is not described in the supplied material. On the licence side, AGPL-3.0 governs the source; running the released desktop binary or installing the store extension for your own meetings is a different situation from modifying and redistributing the code, and the two should not be conflated when deciding whether the licence is a blocker for you.

What to verify before you rely on it

Check the language pair end to end, not just the headline numbers. The README lists 99+ recognition languages, 55+ translation languages and 53 TTS languages, and a pair that clears the first two but not the third will not produce spoken output on the local path. Second, confirm which provider your two-way auto-detect session actually uses, since the README attributes that mode to Soniox two-way mode rather than to the local stack. Third, if you are building from source, run `npm run electron:dev` on the machine you intend to use and exercise the WebGPU models there, because the README's no-GPU-needed claim is not accompanied by hardware requirements or latency figures.

Sokuji is a reasonable fit for a team that holds regular bilingual calls, wants the option of keeping audio on-device, and is comfortable with a fast-moving 0.40.x codebase. It is a poor fit for anyone who needs permissive licensing, guaranteed low latency, or a fully offline auto-detect mode, because the documentation as supplied does not establish that any of those three are available.

Editorial conclusion

Adopt Sokuji if you run recurring bilingual meetings and either need the local WASM/WebGPU path for privacy or want one client that can switch between nine cloud providers without changing apps. Do not adopt it if you need a permissively licensed component to embed in a closed product, or if you cannot accept that the two-way auto-detect mode is documented as depending on Soniox. Before committing, verify three things yourself: that your machine's WebGPU support is sufficient for the local models you intend to use, that the provider you plan to rely on is the one the two-way mode actually requires, and that AGPL-3.0 is compatible with how you intend to distribute anything built on the source.

Official sources

1. kizuna-ai-lab/sokuji on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases