Izwi runs the whole voice stack locally and speaks a familiar API

One runtime covering the whole voice stack, on your own machine

Izwi is a voice runtime that ships as four things at once: a desktop application, a web interface, a command line tool and a local inference server. It covers transcription, speaker diarization, forced alignment, speech synthesis, voice cloning and local chat, and it runs on the machine in front of you without an account or an API key.

The span is the unusual part. Voice work normally means assembling pieces, because transcription, diarization and synthesis are separate projects with separate interfaces and separate model formats. Putting them behind one runtime removes the integration work, which for most teams is the majority of the effort.

The audience is anyone who needs voice processing where the audio cannot leave the building, or where per-minute cloud billing does not survive the volume. Legal, clinical and interview work fall in the first group. Anything processing large archives falls in the second.

The OpenAI-compatible surface is the design decision that matters

Alongside its own product workflows, Izwi exposes routes matching a widely implemented API shape: models, chat completions, audio speech, audio transcriptions, and a preview of the newer responses interface.

That choice does more work than a feature line suggests. Any client library, tool or application already written against that interface can be pointed at this server by changing a base URL, with no code changes. It also sets the migration path in both directions: a team can prototype against a hosted service and move to local inference when volume justifies it, or run locally and fall back to a hosted provider under load.

Building a local runtime that speaks an existing protocol rather than inventing one is the pragmatic decision, and it is the thing that makes a local-first tool adoptable inside a codebase that was not written for it.

The privacy statement attached to this is specific rather than reassuring in the abstract. Inference data stays on the machine, optional desktop analytics are off unless a user turns them on, and the README enumerates what those analytics do not carry: prompts, transcripts, audio payloads, local paths and personal identifiers. Listing the exclusions individually is a more useful commitment than a general promise, because it can be checked.

Installing it, and running the first synthesis

Release builds are published per platform: a disk image for macOS, a Debian package for Linux, an installer for Windows. The Linux path is a single package install from the downloaded file.

Starting the runtime is one command, and the mode argument decides which of the four faces you get.

izwi serve --mode web

That brings up the local server together with the web interface, which is the quickest way to confirm the installation works. Omitting the mode runs the server alone, and a desktop mode is available for the native application.

Models are not bundled, so the first useful action is fetching one and exercising it.

izwi pull Qwen3-TTS-12Hz-0.6B-Base
izwi tts "Hello from Izwi." --output hello.wav

After that you should have an audio file in the working directory, produced entirely locally. A named model pulled explicitly rather than resolved implicitly is the right default for a tool where model choice determines both quality and memory footprint.

Container deployment is supported as well, with a compose profile selecting the accelerated path.

docker compose --profile cuda up -d

Server behaviour is configured through environment variables, with an example file naming the host, port, backend selection, batch size, thread count, concurrency ceiling, timeout, cross-origin settings and whether the interface is served at all. Those are the knobs you would want for running it as a service rather than an application.

The acceleration story is the thing to read before downloading

Runtime support differs by platform in a way that decides whether this is usable for you, and the project states it plainly rather than burying it.

On Apple Silicon, release builds use the platform's graphics acceleration on macOS 15 and later, falling back to the processor on macOS 12 through 14. On Linux and Windows, release builds are processor-only. NVIDIA acceleration exists but is reached through the container profile or by building from source with the appropriate feature enabled.

So a Linux workstation with a capable GPU gets no acceleration from the downloaded binary. That is a deliberate packaging decision rather than an oversight, and the release notes explain the reasoning by implication: native artifacts intentionally do not bundle the accelerator runtime libraries, and each release is checked for accidental inclusion of those payloads and for per-file size before publication.

Verifying that your binaries do not contain something is an unusual thing to automate, and it reflects a real problem: bundling vendor runtime libraries inflates downloads and carries licensing questions. Keeping them out of the native build and offering acceleration through a container is a defensible split.

It still means the fast path on the most common server platform is the container, and anyone planning to run this on a Linux box with a GPU should plan for that rather than discovering it after installing.

A Rust workspace, and what the crate layout reveals

The project is built as a Rust workspace with eight member crates, and their names describe the architecture without needing a diagram: a core, a server, a command line interface, a desktop application, a speech recognition toolkit, a voice activity detection component, an agent, and a hooks crate.

Splitting voice activity detection into its own crate is the detail worth noticing. That component decides where speech starts and stops, and it sits upstream of everything else, since transcription quality and cost both depend on not feeding silence to a model. Treating it as a first-class component rather than a utility buried in the recognition path suggests the architecture was planned around long audio.

The web interface is a separate application built with its own toolchain, assembled during the container build before the runtime is compiled, which is the conventional arrangement for a Rust binary that serves a front end.

Rust is a reasonable choice for this problem. A local runtime is a long-running process handling concurrent audio streams with tight memory behaviour, which is exactly where a garbage-collected runtime becomes awkward, and the asynchronous stack the workspace depends on is the standard one for that work.

Beta, and two versions that disagree

The version is 0.1.0 with a beta suffix, currently at the eighteenth such build in the workspace manifest while the most recent published release is the seventeenth, dated 2026-06-22. The last push was on 2026-09-13.

Read the version honestly. A zero-point-one beta covering transcription, diarization, alignment, synthesis, cloning and chat is a broad surface at an early stage, and breadth at that maturity usually means the capabilities are uneven. Nothing in the repository reports accuracy for any of them, so quality has to be established on your own audio.

The licensing is stated in two places and they disagree. The repository is identified as carrying permissive MIT terms, while the workspace manifest declares Apache-2.0. Both are permissive and they are not the same document, and the Apache text adds an express patent grant that the other lacks. Anyone bringing this into a company should read the licence file in the repository and treat the manifest as a claim rather than the source of truth. This is not legal advice.

The gap between the published release and the manifest version also means a source build and a downloaded build are not the same software, which matters when reporting a problem.

A hosted voice API is the alternative, and the protocol makes the swap cheap

Because Izwi implements a common API shape, the alternative is the hosted service implementing the same one, and the comparison is unusually clean: the same client code, pointed somewhere else.

The hosted route gives you models maintained by a vendor, no hardware to own, no model files to manage, and capacity that scales with a billing limit rather than a purchase. It also sends every second of audio to a third party, bills per minute, and makes your feature availability dependent on someone else's roadmap.

Izwi inverts that. Audio stays on the machine, cost after hardware is electricity, and the model set is whatever you pull. What you take on is the hardware, the acceleration question described above, and the quality of a beta runtime rather than a vendor's production service.

The decision is usually settled by one of two things rather than by preference. If the audio is confidential enough that transmitting it is a compliance event, local processing is the only option and the comparison ends. If volume is high and steady, the arithmetic favours owning hardware. For occasional transcription of unremarkable audio, a hosted API remains less work, and the fact that both speak the same protocol means choosing one now does not foreclose the other.

Editorial conclusion

Izwi fits work where audio cannot be transmitted or where steady volume makes per-minute billing untenable, and its OpenAI-compatible routes mean existing client code can point at it by changing a base URL. It is the wrong choice when you need a vendor's production accuracy today, since this is a 0.1.0 beta that publishes no accuracy figures for any of its capabilities. Check the acceleration matrix before downloading, because release builds for Linux and Windows are processor-only and NVIDIA support comes through the container profile or a source build, and read the licence file directly, since the repository is identified as MIT while the workspace manifest declares Apache-2.0.

Frequently asked questions

Official sources

1. izwi-ai/izwi on GitHub
2. License: MIT
3. Project website
4. README
5. Releases