MimikaStudio: Local Voice Cloning and Audiobook Generation on Apple Silicon

The gap MimikaStudio fills on an Apple Silicon desktop

Most voice cloning tooling assumes a CUDA GPU or a remote API. MimikaStudio takes the opposite position: it is a macOS application for Apple Silicon that runs the models on-device through MLX, Apple's array framework, with Metal acceleration. The README describes it as local-first, and the four advertised capabilities (voice cloning, text-to-speech, document read-aloud, audiobook creation) all run in the same application rather than as a chain of scripts. The audience is therefore narrow and specific. It is for someone with an M-series Mac who wants to clone a voice from a short reference clip, feed it a PDF or EPUB, and get an audio file back without uploading the source text or the voice sample anywhere. The README gives the reference audio requirement as "as little as 3 seconds". That number matters because it sets the practical bar for what a usable reference clip looks like, and it is the kind of claim you should verify against your own recordings rather than take at face value. The project also positions itself as an agentic voice cloning server, exposing the same pipelines to MCP clients. That second audience, people wiring local agents to a speech backend, is the more interesting one, because most local TTS tools stop at a command line and never expose a tool interface.

Four engines, one queue: how the pieces connect

The README lists the supported models in a single table, and the split between them is the clearest statement of the architecture. Kokoro-82M handles fast English TTS with British RP and American voices. Supertonic-2 is a multilingual ONNX model covering English, Korean, Spanish, Portuguese and French. Qwen3-TTS appears in 0.6B and 1.7B sizes, in Base and CustomVoice variants, and in full-precision and 8-bit builds; the Base variants do voice cloning across 10 languages, while CustomVoice provides preset speakers in English, Chinese, Japanese and Korean. Chatterbox Multilingual covers voice cloning across 23 languages. So the application is not one model with a UI. It is a set of engines with different strengths, and the user picks per task: Kokoro when speed matters, Qwen3-TTS or Chatterbox when the voice has to be cloned, Supertonic when the language is one of its five. The unifying mechanism is the jobs queue. The README calls it a "state-of-the-art jobs queue" for TTS, cloning and audiobook pipelines, and there is a dedicated Jobs screen in the UI list. That is the part that makes audiobook generation tractable: a long document becomes many chapter-level jobs, each producing audio, and the queue tracks them. The README also mentions reusable voice presets and queueable chapter generation, which implies a preset is stored once and referenced by each job rather than re-uploaded. First-run model download management is handled by the application, so the models are not bundled in the binary. The README does not document the queue's persistence model, retry behaviour or concurrency limits, and that absence is worth noting if you plan to run long unattended batches.

Installing and running it: what the material actually shows

The README points to a website for getting started and to GitHub releases for downloads, and the v2026.04.1 release note says the project removed the pricing and buying paths from the website "in favor of direct GitHub release downloads". So the acquisition path is the releases page, and the binaries are macOS only. The README is explicit that the codebase is cross-platform but that only macOS binaries are provided, with Windows support described as planned for a future release and marked "coming soon". Beyond that, the material does not include install commands, a Homebrew formula, a build script, or a configuration reference. What it does document is the interface surface: a Settings > MCP screen, a Settings > About screen, a Voice Prompt Management screen, and per-engine screens for Kokoro, Supertonic, Qwen3 preset voices, Qwen3 voice clone and Chatterbox. The MCP settings screen is the only configuration area named in the README, and it is the one to look at first if your goal is agent integration rather than desktop use. Because the repository is a Flutter application with a Python backend (the Dart and Python topics, and the backend/ directory holding pregenerated audiobook files), a source build would mean a Flutter toolchain plus the Python side, but the README does not give the commands and I will not invent them. If you need to build from source rather than run a release binary, treat that as an open question to resolve from the repository itself.

The licence is not what the repository metadata says

GitHub lists the license as GPL-3.0. The README says something different: "Source code is licensed under Business Source License 1.1 (BSL-1.1), and binary distributions are licensed under the MimikaStudio Binary Distribution License." It points to LICENSE, BINARY-LICENSE.txt and a website licence page. That is a material discrepancy, and it is the single most important thing to check before you build anything on top of this project. BSL-1.1 is a source-available licence, not an open source licence in the OSI sense, and it typically carries use restrictions and a change date after which the licence converts. The Binary Distribution License is a separate instrument that governs the compiled application you download from releases. These two licences can apply to the same functionality depending on whether you run a binary or build from source, and the README does not reconcile them. I am not giving legal advice, and I cannot tell you from this material what the BSL parameters are, what the change date is, or whether commercial or hosted use is permitted. What I can say is that anyone planning to redistribute, embed in a product, or offer as a service needs to read both files rather than trusting the sidebar label. The v2026.04.1 note about disabling the old 7-day expiration and the Polar/LemonSqueezy purchase flow suggests the commercial model has changed recently, which is another reason the licence text, not the repository metadata, is the authoritative source.

Where MimikaStudio is the wrong tool

The platform constraint is the first limitation and it is not incidental. If your team is on Windows or Linux, there is no binary for you, and the README's "coming soon" is a statement of intent rather than a date. The second limitation is the interface. MimikaStudio is a desktop application with an MCP server attached. If what you want is a Python library you can call from a data pipeline, a REST service you can deploy in a container, or a CLI you can script in CI, the README does not describe any of those as first-class paths. MCP is an agent protocol, not a general RPC surface, and it assumes an MCP-capable client. The third limitation is the model matrix itself. The Qwen3-TTS 1.7B variants are large, and the README does not publish memory requirements or generation speed for any engine, so you cannot predict from the documentation whether a 1.7B clone on your specific Mac will be fast enough for interactive use or only for batch audiobook work. The 8-bit builds exist precisely because full precision is heavier, but the README does not quantify the quality difference. Fourth, the documentation is thin in exactly the places that matter for production: no queue semantics, no error handling, no API reference, no configuration keys beyond the MCP settings screen. And the README's own headline claim, cloning "in seconds", is a marketing phrase without a stated measurement condition. Treat it as a direction, not a specification.

How it differs from ebook2audiobook and from hosted TTS APIs

The README itself references ebook2audiobook when describing its inline demo blocks, and the comparison is useful because the two projects overlap on the audiobook use case but differ in almost everything else. ebook2audiobook is a Python project oriented around a command-line and Gradio workflow: you point it at a book, pick a model, and it produces audio. MimikaStudio instead wraps its engines in a Flutter desktop application with a jobs queue, a persistent voice preset store, a Read Aloud mode with sentence-level highlighting, and an MCP server. The difference is not the model list. It is that MimikaStudio treats audiobook generation as one job type inside a general queue that also serves TTS and cloning, and exposes that queue to agents. A script-based tool gives you reproducibility through your own code; MimikaStudio gives you a GUI and an MCP tool surface, and asks you to accept its queue as the orchestration layer. Against hosted TTS APIs the difference is simpler and more absolute: nothing leaves the machine. That is the whole proposition. It also means you own the model downloads, the disk usage, the thermal load on a laptop, and the upgrade path when a model changes. A hosted API pushes all of that to the vendor and charges per character. Neither is better in the abstract; they fail in different ways.

Release cadence, upgrade cost and what to verify first

The release history shows a fast cadence: v2026.03.10 on 22 March, v2026.03.11 on 24 March, and v2026.04.1 on 1 April, all within roughly ten days. The versioning is calendar-based (year.month.patch), which makes it easy to see how far behind you are but tells you nothing about breaking changes. The v2026.04.1 notes describe three changes: in-app PDF page preview for audiobook source documents, removal of the old 7-day expiration, and removal of the Polar/LemonSqueezy purchase flow in favour of direct GitHub downloads. That last item is a licensing and distribution change as much as a UI change, and it is the kind of thing that can invalidate assumptions you made a month earlier. Because the models are downloaded on first run rather than bundled, an upgrade can also mean re-downloading model weights, and the README does not describe a model cache location or a way to pin a model version. If you are deploying this on more than one machine, that is a real operational cost. The concrete things to verify before you commit: open LICENSE and BINARY-LICENSE.txt and read them against your intended use; check the Settings > MCP screen and confirm your MCP client can talk to the server; and test one audiobook chapter end to end on your own hardware before queueing a full book, because the README publishes no throughput figures for any engine and the 1.7B Qwen3-TTS variants are the ones most likely to surprise you.

Editorial conclusion

Adopt MimikaStudio if you are on an Apple Silicon Mac and want voice cloning, read-aloud and audiobook export to stay on the machine, with an MCP endpoint for local agents. Do not adopt it if you need Windows or Linux binaries today, if you require a standard open source licence for redistribution, or if you need a documented Python API rather than an MCP tool surface. Before committing, read LICENSE and BINARY-LICENSE.txt against your intended use, check whether the MCP server is documented well enough for your client, and confirm the model download sizes for the Qwen3-TTS 1.7B variants fit your disk and memory budget.

Official sources

1. BoltzmannEntropy/MimikaStudio on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases