voicevox_core: the synthesis core behind VOICEVOX, without the editor

Three projects, and this one is the synthesis core

VOICEVOX is an open source text to speech software for Japanese, and the repository you are looking at is one of three pieces of it. The README points at the editor VOICEVOX as the application you interact with, at VOICEVOX ENGINE as the engine, and at a separate architecture document for the overall composition of the system. voicevox_core is the core itself, described in the repository description as the free, medium quality text reading software that forms the core of VOICEVOX.

That split matters if you are choosing where to start. The editor is what a person types into. The engine sits on top of the core and adds the serving layer. The core is the part that turns text into audio, and it is the part you bind to when you want that audio inside something you are building, in a game, a chat client, a narration tool or a service.

The core is written in Rust. The repository layout is a Cargo workspace whose members are the crates under crates/, with a separate build_util/ directory, a model/ directory, a rust-toolchain file, and a CHANGELOG.md and CONTRIBUTING.md at the root. Nothing in the layout suggests an application entry point, and that is the point: this is a library project, and the way you use it is by calling into it.

The project is not archived and the last push was on 2026-10-14, with the most recent tagged release being 0.17.0 on 2026-08-13, preceded by 0.16.4 on 2026-02-19 and 0.16.3 on 2025-12-07.

The releases are the product: shared libraries and Python wheels

There is nothing to compile if you do not want to. The release page of the repository publishes prebuilt libraries, and the README names two forms. The first is the C API dynamic library, shipped as .so, .dll and .dylib files, which covers Linux, Windows and macOS. The second is the Python API wheel, shipped as a .whl file, which is what a Python project installs.

So the integration path is either one of two. A non-Python caller loads the shared library, calls the exported C functions, and reads audio out; the header that describes those functions is what a binding generator or a hand written FFI layer needs. A Python caller installs the wheel and calls the Python API directly. Both are shipped by the same project at the same version, which is convenient when a team has a mixed stack, because the behaviour underneath is the same core.

The README does not document a package manager name to install the wheel, and it does not give a command for either form, so the practical instruction is to go to the release page, pick the asset that matches your platform and your language, and follow the API documentation afterwards. The two things you will need beyond the binary are the C API documentation, which the README links as the API documentation site, and the user guide, which lives in the repository at docs/guide/user/usage.md.

The C API is the seam, and the samples show how to cross it

A C API is a deliberate choice for a core like this, and the repository shows the consequences in the sample set. The samples currently provided are Python using pip, C++ on Unix with CMake, and C++ on Windows with Visual Studio, and the README asks you to read the README inside each directory for how to run them.

The tree lists more than the README advertises. Alongside example/python, example/cpp and example/rust, there is an example/kotlin directory, which means a Kotlin sample exists in the repository even though the list in the README stops at three languages. The README also points at samples maintained outside the project for Go on Windows and for C#, and it invites contributors to say so when they write a sample of their own, which is how that list grows.

The community section shows how binding to this core becomes a project of its own. The listed wrappers include a Ruby FFI wrapper, a Node.js and C++ implementation of the engine, a C# implementation, an FFI wrapper for Scala on the JVM, a Flutter FFI wrapper, a Go FFI wrapper, a second C# wrapper and a Swift wrapper. Several people, several languages, one C API underneath. That is the strongest practical argument for the C interface: every one of those wrappers exists because a stable, language neutral seam is easier to bind to than a Rust crate with its own lifetimes and types.

The workspace is many crates, and the model is not in the source

The Cargo.toml at the root defines a workspace with resolver version 2 and members matching everything under crates/, and then a long shared dependency block. The entries in that list are worth reading as a description of what the core is built on.

For numerical work the list includes ndarray and ndarray-stats, which are array and statistics crates, and num-bigint and num-traits. For inference it includes ort, the ONNX Runtime binding, pinned to a specific commit of a git repository rather than to a tagged release, with a comment pointing at a specific issue number in that repository. For the C interface there are cbindgen and bindgen, the two crates that generate and consume native headers. There is android_logger and jni, and for dynamic loading of native code there is libloading.

Alongside those sit the tools a project of this kind accumulates: clap for command line parsing, color-eyre and anyhow for error handling, indicatif for progress bars, cbindgen, bindgen, and a long tail of async and serialization crates. Two entries in the list stand out for a different reason. There is a divan entry that is actually the codspeed-divan-compat package, and there is octocrab, a client for a code hosting API, along with async_zip pinned to an exact version, the two crates a release pipeline would reach for.

The model/ directory and the.gitmodules file at the root say something equally important. They indicate that some content is pulled in as a submodule instead of being tracked in the source, so a build from source is not a single step operation. The pyrightconfig.json file at the root is for the type checking of the Python side, and deny.toml is the configuration of a dependency licence and advisory checker, which is the kind of file a project publishes when it tracks what it pulls in.

MIT, except for the builds that are not

The licence section is short and mostly permissive. The source code and the build artefacts of voicevox_core are under the MIT licence, with the licence file at the root of the repository. For a project meant to be embedded in other people's software, that is the licence you want to see.

There is one line in that section that deserves attention. The prebuilt core libraries with a version below 0.16 that live on the release page are under a different licence, and the README asks you to be careful about that. The distinction is easy to miss because it applies to binaries rather than to the source, and because a user who installs an older wheel or downloads an older shared library is unlikely to be reading the licence section of the current README.

The practical consequence is a version floor for redistribution. If you ship a product that bundles the prebuilt core, take the library from the 0.16 line or later so that the MIT terms apply to the artefact you distribute, and check the licence file that ships with the release you picked. This is a licensing note about which terms apply, not advice about how to use the software.

The repository also publishes a CHANGELOG.md and a CONTRIBUTING.md, a deny.toml for dependency licence checks, a renovate.json5 for automated dependency updates and a _typos.toml, which together describe a project that tracks its dependencies and its contribution process as carefully as its code.

Where the core is the wrong thing to reach for

The first mistake is expecting an application. If you want a program that takes text and gives you a voice, the editor VOICEVOX is that program, and the engine VOICEVOX ENGINE is the layer that serves the core to other software. Installing the core gives you a library and a model, and the work of making it speak is yours.

The second mistake is underestimating the model. The voice model lives outside the source tree, in the model/ directory and the submodule reference, so a from source build is a multi step job with a large download, and the C API and the Python wheel are the paths that avoid it. A project that only needs to say a few fixed lines is far better served by a hosted speech service or by a pre-recorded asset than by embedding a synthesis core and its model.

The third is the version surface. The API documentation lives on its own site rather than in the repository, so the header you compile against, the wheel you install and the documentation you read can be from three different versions if you are careless. With releases at 0.16.3, 0.16.4 and 0.17.0 inside a single year, pinning a version and reading the documentation that matches it is not optional.

What the core does offer is the opposite of a hosted service: the synthesis runs on your own machine, under your own licence terms, with no request per utterance and no dependency on a remote endpoint being reachable.

Editorial conclusion

voicevox_core fits a developer who needs Japanese text to speech inside another product and is willing to bind to a C API or install a Python wheel, because the release page publishes both forms and the samples cover Python, C++ on Unix, C++ on Visual Studio and a Kotlin and Rust directory. It is the wrong dependency if you are looking for an application, since the editor, the engine and the core are three separate projects and this repository is only the synthesis layer. Before you build on it, check two things: whether the prebuilt library you download is version 0.16 or newer, because builds below 0.16 carry a different licence, and whether the C header and the C API documentation match the release you pinned, since the API documentation lives on a separate site and the last release was 0.17.0 on 2026-08-13.

Frequently asked questions

Official sources

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