VRCT: VRChat Chatbox Translation and Speech Transcription

What VRCT Actually Solves for VRChat Players

VRChat has no built-in translation layer. If you are in an instance with someone who speaks Japanese and you speak English, you type into a chatbox or you speak and hope. VRCT sits between your microphone, your speakers, and VRChat's OSC interface. The README describes it as "software that supports VRChat conversations with translation and transcription" and lists four capabilities: sending chat to VRChat, translation, transcription of microphone audio, and transcription of speaker audio. The audience is narrow and specific: VRChat players who regularly share instances with people who do not speak their language. The README also notes that people use it for other purposes such as watching movies, but states that this is not supported. That distinction matters. The project is tuned for the VRChat OSC chatbox, not for general desktop captioning.

How the Python Backend and Tauri Frontend Fit Together

The repository layout shows a split application. src-python/ holds the backend, src-tauri/ holds the Rust shell, and src-ui/ holds the web frontend built with Vite. The package.json scripts confirm the Python side is compiled into a sidecar binary that the Tauri app launches. The speech path is visible in requirements.txt: faster-whisper 1.1.1 on top of ctranslate2 4.6.0 and torch 2.7.0, with PyAudioWPatch for capture and python-osc for talking to VRChat. Translation is not one provider. The dependency list includes deepl, langchain-openai, langchain-google-genai, google-genai, and langchain-ollama, so the app can route translation through DeepL, OpenAI, Google, or a local Ollama instance. Japanese text handling uses SudachiPy with SudachiDict-core and SudachiDict-full, which suggests tokenization is done locally before translation. Audio capture uses pycaw, a Windows Core Audio library, which ties the speaker transcription feature to Windows.

Installing VRCT and Running a First Translation

The README is explicit about installation: download from GitHub releases or BOOTH.pm and run the exe. There is no installer, no package manager entry, and no documented command-line setup. The documentation site at misyaguziya.github.io/VRCT-Docs is where initial setup is described, and the README links a YouTube walkthrough. For a first run, the flow is: launch the exe, open settings, choose a translation provider, then enable the microphone or speaker transcription toggle. The exact setting labels are not in the README, so check the docs site before assuming a layout. If you want to build from source instead, the package.json exposes the scripts. The development path installs Python dependencies first, then builds the sidecar and launches Vite and Tauri together:

npm run setup-python
npm run dev

The setup-python script calls bat\install.bat, and dev runs task-kill, clean, update-version, build-python, and dev-ui in sequence. A faster loop that skips the full Python rebuild uses a prebuilt virtual environment:

npm run dev-fast

That script sets VRCT_DEV_VENV to .venv and runs the sidecar and UI in parallel. For a CUDA build, the equivalent is npm run dev-cuda, which sets VRCT_DEV_VENV to .venv_cuda and installs from requirements_cuda.txt. The README does not document what the build produces or where the output lands, so treat the release exe as the supported path and the source build as a development workflow.

The Dependency Pins Are the Real Maintenance Risk

requirements.txt carries a comment that is unusually honest. It explains that setuptools 82.0.0 removed pkg_resources, that both openvr and ctranslate2 still import pkg_resources at import time, and that bumping past 81.x breaks the app outright. The file pins setuptools==80.8.0 and notes that 32 test files fail to even collect on a newer version. That is a real constraint, not a stylistic choice. It means the project cannot take a setuptools security update until two upstream packages change their import behaviour. The same file pins numpy==1.26.4, which is older than the 2.x line, and pillow==10.0.0. There is also a note that comments in requirements.txt must stay ASCII-only because pip-audit parses the file using the OS locale codepage rather than UTF-8. These are the kinds of details that make a Python desktop app hard to upgrade. Anyone forking VRCT should read that file before running pip install --upgrade on anything.

Telemetry, Windows Lock-In, and Where VRCT Is the Wrong Tool

VRCT collects anonymous telemetry through Aptabase. The README states the data includes app starts, session duration, and feature usage, and that no personally identifiable information is collected. It also states you can opt out in the app settings at any time. That is a reasonable default for a hobby project, but it is still network traffic leaving your machine, and the README does not describe what happens to the data after collection beyond linking the Aptabase privacy policy. The harder limitation is platform. pycaw is Windows-only, the build scripts are .bat files, and the install instructions say to run the exe. There is no documented Linux or macOS build. If you need a headless transcription service, a Linux deployment, or a pipeline you can run inside a container, VRCT is the wrong shape. It is a desktop app that assumes a Windows machine with a GPU or a CPU fast enough for faster-whisper, and it assumes VRChat is running on the same machine.

Kikitan-translator and the Alternative Approach

Kikitan-translator is the comparison people search for, and the difference is architectural. VRCT is a single desktop application that bundles capture, recognition, translation, and OSC output behind a Tauri UI. The alternative pattern is a set of smaller pieces: a speech-to-text engine such as faster-whisper or Whisper.cpp running as a separate process, a translation API called directly, and a small script that sends the result over OSC. That approach costs more setup time and gives you nothing out of the box, but each stage is replaceable. If faster-whisper is too slow on your hardware, you swap the recognizer. If DeepL changes its pricing, you swap the provider. VRCT already exposes multiple translation providers, which narrows the gap, but the speech engine and the OSC layer are baked into the sidecar binary. Choose VRCT when you want a working app today. Choose the assembled approach when you want to own each stage.

Licence, Releases, and What to Check Before You Install

VRCT is MIT licensed, which permits commercial use, modification, and redistribution as long as the copyright notice and permission notice are included. The repository has a LICENSE file at the top level. The project also has a BOOTH.pm store page and accepts support through GitHub Sponsors, PIXIV FANBOX, and Patreon. Those are funding channels, not a different licence. The releases listed are v3.5.1 from 2026-09-08, v3.5.1-beta.1 from 2026-09-02, and v3.5.0 from 2026-08-29. The last push to the repository was on 2026-09-14, so the codebase is being touched regularly. Note that package.json still declares version 3.5.1-beta.1 while the latest release is 3.5.1, so if you build from source you may not get the same version as the released exe. If you redistribute VRCT inside another product, the MIT terms apply to the code, but the VRChat trademark disclaimer in the README is worth reading: the project states it is not endorsed by VRChat.

Editorial conclusion

VRCT is worth adopting if you play VRChat with people who speak other languages and you want transcription and chatbox output in one app. It is the wrong tool if you need a headless service, a Linux build, or a speech pipeline you can audit without reading Python. Before installing, verify the release you download matches the version in the repository's package.json, confirm your GPU or CPU path against requirements.txt and requirements_cuda.txt, and check the telemetry opt-out in the app settings.

Frequently asked questions

Official sources

1. License: MIT
2. misyaguziya/VRCT on GitHub
3. Project website
4. README
5. Releases