Auto Caption: live captions from system audio with pluggable engines

What the application does and how it is put together

Auto Caption is a cross-platform real-time caption display application. The README describes it in one line as software for generating captions from audio output or microphone input, and the current version is 1.2.0, with the changelog linked from the README header. Downloads come from the GitHub releases page, and the interface is available in Chinese, English and Japanese.@@P@@The architecture is the interesting part and it is described explicitly. The project is modular, split into the main program and the caption engine, with the main program calling the engine through a graphical interface. The core audio capture and speech recognition live in the engine, and the engine can be used on its own, detached from the main program. The engine is written in Python and packaged into an executable with PyInstaller, so the team had to pick a split that works both as an application and as a command line tool.@@P@@The front end is an Electron app built with Vue. The package manifest names the project auto-caption with the product name Auto Caption, and the runtime dependencies are the Vue stack: ant-design-vue for components, pinia for state, vue-router for routing and vue-i18n for the interface languages, plus pidusage for process measurement and the Electron toolkit packages. The build is driven by electron-vite, with separate type checking for the Node side and the web side using tsc and vue-tsc, and electron-builder producing the installers for Windows, macOS and Linux.@@P@@The desktop side installs its dependencies with the standard package manager command.

npm install

The repository is MIT licensed and was last pushed on 2026-10-14, with release v1.2.0 published the same day, following v1.1.1 in January 2026 and v1.1.0 earlier that month.

The engine menu: paying for accuracy or running it locally

Choosing an engine is the decision that shapes the whole application, and the README puts five options in a table with accuracy, real-time behaviour, deployment type, supported languages, translation support and a note for each.@@P@@The cloud options are accurate and fast but billed. The Alibaba Paraformer Realtime v2 engine supports eight languages including Cantonese and is listed at roughly 0.864 CNY per hour. The GLM-ASR model from Zhipu AI covers four languages, is described as poor in real-time terms, and is listed at about 0.72 CNY per hour. Qwen LiveTranslate sits at the top of the table with good accuracy and good real-time behaviour, auto-detects the source language and brings its own translation, which means you do not have to configure a separate translation service for it.@@P@@The local options cost nothing per hour and keep the audio on the machine, at the price of quality. Vosk runs on the CPU, supports more than thirty languages and is good in real time, but the README is blunt about the trade: the recognition effect is comparatively poor and the generated content has no punctuation. SOSV is a model bundle built on the Shepra-ONNX SenseVoice model with endpoint detection and punctuation restoration added, supporting English, Chinese, Japanese, Korean and Cantonese, with accuracy and real-time behaviour both described as average.@@P@@The fifth row is your own engine. The README says you can develop your own model following the engine documentation, using Python, and that the accuracy, real-time behaviour, deployment type, languages and translation are then entirely yours to define. That is what the standalone engine design is for.@@P@@Two of the built-in engines have detail worth knowing. The default is the Alibaba paraformer-realtime-v2 engine, used through the DashScope Recognition SDK with bidirectional streaming, uploading audio as 16kHz, 16-bit, mono PCM. It handles Chinese, English, Japanese, Korean, German, French, Russian and Cantonese, and and an auto option lets the model work without a language hint. The Qwen LiveTranslate engine uses a WebSocket session that streams both the original text and the translation in the same session, and it needs a business space identifier, a region of either Beijing or Singapore, and an Alibaba Cloud API key, which can also come from the DASHSCOPE_WORKSPACE_ID and DASHSCOPE_API_KEY environment variables.

Translation is a separate step and it is not real time

The README puts a warning above the translation settings that changes how you should think about the feature: translation is not real time, because the translation model is only called after a sentence has been recognised. Translation is therefore a post-processing step on completed sentences, not a simultaneous track.@@P@@Three translation providers are supported. A local Ollama model needs Ollama installed and the model already pulled, and the README advises keeping the parameter count below one billion, giving qwen2.5:0.5b and qwen3:0.6b as examples, because a larger model means more resource consumption and more delay. In the settings you pick the Ollama local model option and type the model name, and Ollama is reached at its default local service address.@@P@@The OpenAI compatible provider takes a model name, a base URL and an API key, and the README lists the base URLs of several providers, including OpenAI, DeepSeek and Alibaba Cloud's compatible-mode endpoint. The Google Translate API needs no configuration at all, only a network connection, with the caveat that it is unavailable in regions that cannot reach international networks.@@P@@The Vosk and SOSV engines need no translation configuration beyond selecting the provider, but they do need the model itself. For Vosk you download the model from the Vosk models page, unpack it locally and add the model folder path to the settings. The SOSV model is downloaded from a release tag in the project's own repository.

Running the engine on its own from a terminal

Because the engine is a separate program, you can drive it without the interface, and the README gives the command line for that. The source route needs uv installed, the engine directory and a sync of its dependencies; the packaged route needs none of that, since the executable is already built.@@P@@The published invocation shows the shape of the options.@@P@@

uv run python main.py \
-e paraformer \
--dashscope_api_key sk-******************************** \
--translation_provider ollama \
--translation_model qwen2.5:0.5b \
-a 0 \
-d 1 \
-s en \
-t zh

@@P@@The flags map onto the features above: the engine to use, the API key for the Alibaba service, the translation provider and model, and the audio and display options with the source and target languages at the end. Running with -e paraformer and --translation_provider ollama with a small local model is the configuration the README's own example uses.@@P@@The same interface is what the build scripts use. The manifest defines an engine sync script, a test script that runs the Python unit tests in the engine directory through uv, and a build script that packages the engine with PyInstaller into a distribution directory using a spec file.@@P@@

uv sync --project engine

@@P@@That last detail is the one that makes the split work in practice. Packaging the engine separately means the Electron build can ship a prebuilt engine binary per platform, and the Python side can be iterated on without rebuilding the desktop application.

Platform support and the audio capture caveat

The README publishes the platforms that were actually tested, and the table has a column that most applications of this kind would not publish, which is whether the tool can capture system audio input and output.@@P@@Windows 11 24H2 on x64 works for both directions, and Ubuntu 24.04.2 on x64 works for both. macOS Sequoia 15.5 on arm64 is different: system audio input works, and system audio output works but requires extra configuration, which the README links to the user manual. The same caveat applies to Linux, and the README states plainly that macOS and Linux need extra setup for capturing system audio output.@@P@@That single distinction is the difference between this application working and not working for most people. Capturing what is playing on the machine is the main use case, and on two of the three platforms it is a configuration exercise rather than a given. Anyone evaluating this should read the user manual section for their platform before deciding.@@P@@The microphone route has no such caveat, since a microphone is a normal input device, and it is the case where the application behaves identically everywhere.

Where Auto Caption is the wrong tool

The first limitation is that this is a live caption tool, not a transcription service. Captions exist to be read while something is happening, and the engine choices reflect that bias: the models with the best accuracy are the ones billed per hour of audio, the local models trade punctuation and accuracy for latency, and translation waits for a sentence to finish. A project that needs an accurate transcript of a recording, with punctuation, speaker labels and search, is asking for something this application does not attempt.@@P@@The second limitation is the privacy trade-off, which is not hidden but does need stating plainly. With a cloud engine such as Paraformer, GLM-ASR or Qwen LiveTranslate, your audio is uploaded to the provider in 16kHz mono PCM. The local engines avoid that, but at the quality cost described above. Vosk, which supports the most languages, produces text without punctuation, which is the price of the widest language coverage in the table.@@P@@The third limitation is scope of output. Captions can be recorded and exported, in .srt and .json formats, and the styling is configurable down to font, size, weight, text colour and background colour. There is no editor, no speaker separation, no word-level timing metadata beyond what the engine returns, and no subtitle authoring. For hardcoded subtitles for a video file, a subtitle editor is the tool, and it is a different kind of tool entirely.

Editorial conclusion

Auto Caption suits people who need readable captions from a meeting, a lecture or a stream, on Windows, macOS or Linux, and who choose their engine according to whether the audio can leave the machine. It is the wrong tool for hardcoded subtitles, for offline archival transcription, or for legal verbatim transcription. Verify first that your platform can capture the audio output you need, since macOS and Linux require extra setup for that, and that the translation model you pick is small enough to keep the caption delay acceptable.

Frequently asked questions

Official sources

1. HiMeditator/auto-caption on GitHub
2. Issues
3. License: MIT
4. README
5. Releases