Version 1.2.1 joins voice, vision, and a Live2D avatar
Open-LLM-VTuber 1.2.1 turns a language model into a spoken character with a Live2D face. Its web and desktop clients support microphone conversation, voice interruption, camera or screen input, expression mapping, chat-history persistence, and a transparent desktop-pet mode. The project runs on Windows, macOS, and Linux. It can keep the pipeline local, call hosted providers, or mix the two when one part is too heavy for the machine.
The checkout at commit 992309c contained 267 files, roughly 21,245 source lines, and 69.5 MB before installation. The backend is Python, while the frontend is included as a repository submodule. Configuration chooses a character plus the language model, automatic speech recognition, and text-to-speech components. This modularity is the attraction, but it also means a working chat screen does not prove that microphone capture, transcription, generation, synthesis, and animation all suit the same host.
A 9,180 MB environment supports many provider choices
The README names local and hosted choices across each layer. LLM options include Ollama, OpenAI-compatible APIs, Gemini, Claude, Mistral, DeepSeek, GGUF, LM Studio, and vLLM. Speech recognition ranges from sherpa-onnx and Faster-Whisper to Azure and Groq, while speech output can use pyttsx3, MeloTTS, Coqui TTS, GPT-SoVITS, Edge TTS, Fish Audio, Azure, and others. Support means adapters exist; it does not guarantee equal latency, model quality, or hardware cost.
That breadth helps explain why our installed environment reached 184 packages and 9,180 MB. A user must still choose one workable path through the matrix. Offline operation avoids sending conversations to a cloud provider, but local model files, compute, and audio configuration become the user's responsibility. Cloud services reduce local model demands and introduce API credentials, network dependency, usage terms, and possible cost. The project does not erase those tradeoffs; it puts them behind one character interface.
What happened when we ran it
Our fresh Python 3.12 sandbox installed 184 packages in 160 seconds and occupied 9,180 MB. The build then succeeded in 10 seconds. Pip-audit reported 77 known vulnerabilities in the installed environment. That is the clearest reason to avoid treating the supplied dependency set as ready for a sensitive host until someone maps each finding to its package, exposure, and available fix.
There was no test script or target, so the lab skipped tests rather than assigning a pass. The repository had 6 CI workflow files and a Dockerfile, but no tests directory. Its 267 files and roughly 21,245 source lines cover many provider adapters and interaction paths without a lab-visible regression suite. A successful 10-second build verifies packaging mechanics; it does not verify speech accuracy, interruption behavior, Live2D rendering, or provider compatibility.
Version 1.2.1 needs HTTPS for a remote microphone
The native route supports Python 3.10 through 3.12 and uses uv; the quick-start material also requires FFmpeg. The container installs FFmpeg, exposes port 12393, and refuses to start without a mounted conf.yaml. It can also mount model definitions, characters, Live2D models, avatars, and backgrounds. A local browser can use the microphone through localhost, while a phone or another computer needs an HTTPS reverse proxy because browser media capture requires a secure context.
Our 3-CPU, 8 GB sandbox completed dependency installation, but we did not measure conversation latency or model fit. Those outcomes depend on the chosen LLM, speech recognizer, voice engine, and accelerator. NVIDIA and non-NVIDIA setups are supported in different ways, and the README allows CPU or cloud services for demanding parts. Before committing, test one complete conversation loop on the intended machine and include interruption plus screen or camera input if those features matter.
Seventy-seven audit findings require package-level review
Pip-audit found 77 known vulnerabilities after the 160-second install. The supplied result does not break them down by severity or prove that every affected code path is reachable, so neither dismissal nor panic is justified. It does establish work: identify each package and advisory, update what the lockfile permits, rerun the audit, and decide whether remaining findings are exposed by the selected provider path. Internet-facing deployment raises the stakes beyond a localhost hobby setup.
The absence of a test target makes dependency upgrades harder to judge. Six CI workflows provide automation signals, including the README's CodeQL and Ruff badges, but our scan found no tests directory. The project also bundles sample Live2D assets under terms separate from its MIT code license. Medium or large businesses are specifically told to check commercial-use requirements or replace those models, another review item before packaging the desktop client for others.
One hundred fifty-two open items meet an early v2 rewrite
GitHub listed 13,547 stars and 152 combined issues and pull requests when fetched. The default branch was last pushed on May 15, 2026, while open pull-request activity continued through August 30. The latest tagged release is v1.2.1 from August 26, 2025. Those dates show a community still proposing work, but not a recent stable release or default-branch update. The combined open count includes proposed changes and should not be called 152 bugs.
The maintainers say v2 is in early discussion and planning, ask users not to open new v1 feature requests, and promise continued v1 bug fixes. Long-term memory is absent from the current product even though the README says it may return. With 9,180 MB of dependencies, 77 audit findings, and no test target, version 1.2.1 is best for a hands-on personal experiment. A team deployment needs a narrower provider selection, fresh audit work, HTTPS, model-license review, and its own end-to-end tests.