MOSS-TTS's model table points at two other repositories and skips two of its own

The model table is the most useful page here, and it points off-site twice

The file opens with a table that answers the only question a newcomer has, which model to start with, and the answers do not all live here. Five rows, and they resolve in three different ways. Two point at anchors inside this repository, the long-form narration model and its local transformer variant, plus an anchor for the released models in general. Two point at a different GitHub repository entirely: the small model for CPU and browser use, and the dialogue model. Two point at subdirectories of this tree, the streaming model and the sound-effect model. So a reader who clones this repository following the table still needs two more clones. The table's value is that it is organised by task rather than by version, which is the right axis when the family has a model per task. What it does not do is mention two of the model directories that are sitting in the tree: a delay-architecture model and the audio tokenizer. The news entries name MossTTSDelay as an architecture that serving backends implement, used by MOSS-TTS (Delay), MOSS-TTSD, MOSS-VoiceGenerator and MOSS-SoundEffect.

Installing the root package gives you dependencies, not weights

The manifest describes its own package as dependencies and utilities, and the version field agrees with the modesty of the claim: zero point one point zero. There are no tagged releases at all. So the pip package is a bundle of libraries the pipelines need, and the thing you actually want to run is a checkpoint published on a model hub, linked from the news list as it is released. That split is normal for a research release and it is the first thing to internalise, because a reader who installs the package expecting a voice will get an import and no model. The manifest asks for Python 3.10 or newer, while the optional runtime group pins a much newer stack: a specific deep learning framework build with a CUDA suffix, a matching audio library, a codec library, and a transformer library at a major version that was itself recent. So the floor and the ceiling of what you can actually run are far apart, and the manifest's Python requirement describes the interpreter, not the working configuration.

Four of the eight optional groups are one backend with a different audio runtime

The optional dependency table is the most technical document in the repository and it is organised as a menu with a lot of repetition. There are eight groups. Two are for fine-tuning, one plain and one adding a distributed training library. One enables an attention kernel. One is the default framework runtime, pinned exactly, with a comment describing it as the stack for the original pipeline. The remaining four are the same inference backend in four spellings. Three of them share the same four entries and differ in the audio tokenizer runtime they add: the torch-free core, the core plus onnxruntime-gpu, and the core plus tensorrt and cuda-python. The fourth contains only torch, for torch-accelerated LM heads, and its comment calls it optional and auto-detected, so it is not really a fourth choice. The naming is inconsistent alongside that: two of the variants spell out what they add, and one abbreviates it to three letters.

The base install pulls in a web interface and a build tool, both unbounded

The runtime dependency list mixes the libraries the pipelines need with two that belong to other categories, and the pinning is uneven across the whole thing:

dependencies = [
  "safetensors==0.6.2",
  "numpy==2.1.0",
  "orjson==3.11.4",
  "tqdm==4.67.1",
  "PyYAML==6.0.3",
  "einops==0.8.1",
  "scipy==1.16.2",
  "librosa==0.11.0",
  "tiktoken==0.12.0",
  "psutil",
  "packaging",
  "ninja",
  "setuptools",
  "wheel",
  "gradio"
]

The first nine are pinned to exact patch versions, which is careful and correct for a research release where a transitive bump can change output. The last six are not pinned at all, and two of them are the interesting cases. A build tool for invoking native compilation appears in the runtime list rather than a build-requirements list, so it is installed on every machine that installs the package whether or not anything is compiled. A web interface framework is the last entry, with no version and no upper bound, which means an install today and an install next quarter can resolve to different majors of a fast-moving interface library. The build backend declared alongside this is the plain setuptools one, with no build isolation extras listed.

One console script, and three different names for the same code

The manifest declares exactly one entry point, and its three names do not line up. The command it installs is called for the inference backend. The optional group you would install to use it is named for the same backend. The code it points at lives inside a subdirectory belonging to a different model, under a folder named for that backend. So a user reads a backend name in the extras, types a command with that name, and ends up executing a pipeline nested inside the delay model's package. It works, and it is not a bug, but it means the only documented way to run something from this repository has a name that points at the wrong place. The tree also has a directory whose name suggests more than one command line interface, plural, and the manifest declares none of them. Combined with the model table pointing at two other repositories, the picture is of a family whose centre of gravity is the checkpoints and the backend integrations, with this repository acting as the shared library layer between them.

The manifest's own homepage points at an organisation that is not the one hosting it

Three places in this project state a home page and no two agree. The repository's recorded home page is a page on the project's commercial site, under a path for these models. The readme's logo link points at that same commercial site. The manifest's own project links section points somewhere else entirely: a GitHub URL under the OpenMOSS-Team organisation rather than the OpenMOSS account that hosts this repository. The two are not the same string and the difference is not cosmetic, because a link to a repository under an organisation you do not control either 404s or, worse, resolves to an account that happens to exist.

The public changelog stopped in June while the branch moved into September

The news list is the only record of what changed, because there are no releases. Its most recent two entries share a date in mid June 2026, one announcing that a third-party inference engine gained support for one of the architectures and the other announcing the checkpoint that support was for. Before those, entries in early June and late May, and before that a steady stream through the spring. Then nothing. The branch was last pushed in early September, so there are close to three months of commits that appear in no public record. The list also contains an item from late April announcing that version 2.0 is coming soon and linking a feedback form hosted on a workplace collaboration tool, which is six months old and still the last word on that subject. The list's own archival mechanism is worth noting: older entries are pushed inside a collapsed section, so the file grows by hiding rather than by trimming, and the visible window gets shorter with every update.

Distribution is four third-party engines, one of which is the project's own fork

How this family reaches users is not primarily through this repository. The news list is mostly a log of other projects adding support for its architectures, named as identifiers a backend implements: one for the local transformer, one for the delay architecture, one for the streaming model, one for the small model. Four serving paths appear. One inference engine is credited as the first to support the local architecture, with an endpoint that is compatible with a well-known speech API shape, streaming, and voice cloning. Another now covers the full series. A third, mlx-audio, gained support for both the speech model and the audio tokenizer. The fourth is different in kind: the project maintains its own fork of a widely used local inference engine, on a feature branch in a separate repository, with end-to-end documentation and a runnable pipeline including codec decoding. So the family is distributed through four engines, and the team had to fork one of them to get a first-class path.

Editorial conclusion

MOSS-TTS suits a developer who has already decided they want this family rather than a general text-to-speech system, because the value here is the set of architectures that third-party inference engines now support. Check six things first. Installing the root package gets you a dependency bundle, not a model, and the weights live on model hubs separately. Two of the five rows in the navigation table point at other repositories, so a family-level install is not one clone. Two model directories in the tree have no row at all. Four of the eight optional dependency groups are one backend with a different audio runtime, and one is optional within its own group. The base install pulls in a web interface framework and a build tool with no version bounds. And the public changelog stopped in June while the branch moved into September, with no tagged release to fall back on.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. OpenMOSS/MOSS-TTS on GitHub
4. Project website
5. README