Irene Voice Assistant: an offline Russian voice assistant built around plugins

What Irene solves, and who it is actually for

Most voice assistants assume a network connection and a vendor account. Irene takes the opposite position: the README describes it as a Russian voice assistant for offline work, and the default startup path confirms that. runva_vosk.py launches the Vosk recognizer for microphone input and pyttsx for speech output, so the basic loop of hearing and answering never leaves the machine. The project targets Russian speech specifically. The default model referenced in the Dockerfile is vosk-model-small-ru-0.22, and the example commands in the README are Russian phrases such as "ирина привет" and "ирина подбрось монетку".

The audience is narrower than "anyone who wants a voice assistant". It is people willing to run a Python program from a terminal, keep a microphone attached to a desktop, and extend behaviour by writing or installing plugins. The project ships a plugin catalog (plugins_catalog.json) and a separate installer script (runva_plugin_installer.py), which tells you the author expects users to assemble their own assistant rather than accept a fixed feature set. If you want an app you install once and never touch again, this is the wrong shape of project.

How the recognition, synthesis and plugin layers fit together

The repository layout separates concerns cleanly. vacore.py is the core that plugins talk to, jaa.py handles the assistant plumbing, and the runva_*.py files are alternative entry points: runva_vosk.py for local Vosk recognition, runva_vosk_sherpa.py for the newer streaming model, runva_webapi.py for a network-facing mode, runva_gigastt.py and runva_speechrecognition.py for other engines, and runva_cmdline.py for text input without a microphone. Plugins live in plugins/ for active ones and plugins_inactive/ for disabled ones, with a separate docker_plugins/ directory used by the container build.

Speech recognition is the part that changed most. Version 13.0 added an option to run with a vosk-stt-0.56 model, which the README says is from September 2025 and, citing a benchmark at alphacephei.com, scores better than Whisper on Russian while still running locally in streaming mode. The README quotes word error rates on the Sova devices benchmark: vosk-small-0.22 at 29.89, vosk-0.54 at 11.6, and Whisper Large V3 at 15.9. Those are the project's cited figures, not measurements made here. The practical trade-off is that the Sherpa path is described as beta: it works with only the first microphone on the local device, and the network variant is not supported.

On the output side, pyttsx3 is the default synthesizer, and the requirements file also pins elevenlabs, so a cloud TTS option exists for users who prefer it. The AI plugins, marked beta since version 12.0, take a different route entirely: instead of matching a fixed phrase, they send the utterance to a large language model through the tools API and let the model decide which plugin to call with which parameters. The core setting plugin_types controls this, accepting values like "classic", "ai", or "classic,ai", and the README states that classic plugins always take priority when both are enabled.

Installing Irene and getting the first command to work

The README gives the manual path first, and it is short. You need Python, described as roughly 3.7 to 3.11, and then the dependencies. The project offers two requirements files: requirements.txt for the current set and requirements_fixed.txt for pinned, tested versions that the README recommends when you want more stable behaviour.

pip install -r requirements_fixed.txt

On Linux and macOS the README notes you must install the system packages required by the audioplayer library before this step. Once dependencies are in place, the default entry point is runva_vosk.py in the repository root.

python runva_vosk.py

That command starts the offline Vosk recognizer on your microphone and pyttsx for speech output. The README says the options folder appears only after the first run, and that this folder is where settings are edited, so expect an empty configuration until you have launched the assistant once. To confirm it works, say the phrase the README suggests: "Ирина, привет!".

If you prefer not to assemble the environment yourself, the fastest Windows route is a separate repository, janvarev/Irene-VA-win-installer, where you download the code as a ZIP and follow its instructions. The README lists the commands available after that installation, including "ирина подбрось монетку" and "ирина таймер три минуты". For adjusting plugins afterwards, the installer provides start-settings-manager.bat. From version 9.0 there is also a web settings manager, started with runva_settings_manager.py, which uses gradio.

The AI plugin path needs an LLM, and that is a real dependency

The free-form command handling is the most interesting part of the project and also the part with the most strings attached. The AI plugins do not parse your sentence locally. They call a large language model that supports tool calling, and the model returns which plugin to invoke and with what arguments. The README points to the tools API documentation at vsegpt.ru, the author's own service, which offers OpenAI gpt-4o-mini and other models. Every call is billed, though the README estimates a few kopecks per call for the default model and mentions a small free demo credit for trying it.

You are not locked to that service. Any OpenAI-compatible endpoint that supports tools will work, and the README explicitly names LMStudio and Ollama as local options, with the caveat that they will probably be slower. Configuration goes in the core settings: openai_base_url for the endpoint, and plugin_types to declare which plugin categories are allowed.

"plugin_types": "classic,ai"

That single setting is the line between an offline assistant and one that ships your transcribed speech to a model provider. The README says classic plugins take priority, so enabling both does not break existing phrase-based commands. But if your reason for choosing Irene was that nothing leaves the machine, the AI plugins are incompatible with that goal unless you point openai_base_url at a local Ollama or LMStudio instance.

Where Irene is the wrong choice

The Sherpa streaming path is explicitly labelled beta in the README, and the limitations are concrete: only the first microphone on the local device is used, and the network variant is not supported. If your setup has multiple audio inputs, or you want the recognizer to run on one machine and the assistant on another, that path will not do it without code changes the README invites others to write.

The language boundary is the harder limit. Everything documented is Russian: the example commands, the default models, the installer instructions. A team that needs English, Spanish or Mandarin recognition has no documented configuration for it here, and would be better served by a project whose default models cover those languages.

The licence is also worth reading before you build on top of it. The repository's licence field reports NOASSERTION, which means GitHub could not classify the file in LICENSE automatically. That is not a statement about what the licence permits; it means you have to open LICENSE and read it yourself, particularly if you plan to redistribute Irene inside a product. The README does not discuss licensing, and no section of the documentation addresses commercial use.

Finally, the release history is worth noting. The most recent tagged release listed is 8.1 from March 2023, while the README describes features in versions 12.0 and 13.0. The code has moved forward on the master branch, but the release artifacts have not kept pace, so anyone planning to download a packaged build should check what version it actually contains.

Irene compared with a cloud assistant stack

The obvious alternative is assembling the same thing from cloud services: a hosted speech-to-text API, a hosted LLM, and a hosted text-to-speech API. That approach wins on accuracy for many languages, requires no local model downloads, and scales to any number of users without per-machine setup. It loses on exactly the axis Irene is built around. Latency depends on the network, per-request costs accumulate, and every utterance is transmitted to a third party.

A second comparison is with the general-purpose voice assistant projects that appear in the same search results, such as Android-oriented assistants or Flutter-based front ends. Those typically target mobile devices and a graphical interface. Irene targets a desktop with a microphone and a Python runtime, and its extension model is a plugin directory plus a JSON catalog rather than an app store or a mobile SDK. If your deployment target is a phone, Irene is not the starting point; if it is a desktop that must work without connectivity, the plugin directory is a simpler thing to reason about than a mobile build pipeline.

The hybrid position is worth naming too. Irene with plugin_types set to "classic" is fully offline. Irene with AI plugins enabled and openai_base_url pointed at a local Ollama instance is still offline in terms of data, but pays a latency cost the README acknowledges. Irene with AI plugins pointed at a remote endpoint is a cloud assistant with a local front end. Those are three different products sharing one configuration key.

Maintenance cost and what upgrading involves

The last push to the repository was on 2026-07-26, so the project is not abandoned, but the tagged releases lag well behind the documented feature set: the newest release listed is 8.1 from 2023-03-27, while the README documents versions 9.0, 12.0 and 13.0. Upgrading therefore means pulling the master branch rather than downloading a release, and reading the README for what changed, since no changelog is described in the repository's top-level entries.

The dependency surface is the real maintenance burden. requirements.txt pins specific versions of vosk, vosk-tts, pyttsx3, gradio, termcolor, python-dateutil and elevenlabs, and pins fsspec to 2023.1.0 exactly. That last pin and the gradio version constraint are the kind of thing that breaks when a transitive dependency moves. The project offers requirements_fixed.txt precisely because the unpinned set drifts, which is a reasonable mitigation but also an admission that the default set is not reproducible.

Speech models add their own cost. The Sherpa path requires sherpa-onnx and sherpa-onnx-bin for CPU use, and the default model is the full vosk-model-streaming-ru from Hugging Face. The README points to an int8 quantized version as a way to cut memory use at some cost in accuracy, and to vosk-model-small-streaming-ru as a smaller alternative. Those are manual downloads, not managed by pip, so model management is a task the user owns. On the licence side, the repository reports NOASSERTION, so read LICENSE directly before redistributing anything; nothing here should be read as legal advice.

Editorial conclusion

Adopt Irene if you speak Russian, want recognition and synthesis to stay on your machine, and are comfortable editing Python plugins and JSON settings. Do not adopt it if you need a turnkey consumer product, a managed cloud service, or assistants in languages other than Russian: the documentation, the default Vosk model and the bundled skills are all Russian-first. Before committing, verify that runva_vosk.py starts and that vosk-model-small-ru-0.22 (or vosk-model-streaming-ru for the Sherpa path) downloads and loads on your hardware, then check whether the plugin you actually need exists in plugins_catalog.json or has to be written.

Frequently asked questions

Official sources

1. Issues
2. janvarev/Irene-Voice-Assistant on GitHub
3. README
4. Releases