Ollama Can Speak Now: Native Text-to-Speech with Phonon

Two commands now get you Ollama text to speech with nothing else installed:

ollama pull phonon
ollama run phonon "Hello from Ollama."

The second one plays out of your speakers. That is new as of 24 October 2026, when v0.40.11 landed with the line “Ollama can now generate speech on macOS” in its release notes. Every guide you will find by searching describes the old way — pipe Ollama’s text into Piper, or Kokoro, or XTTS, or pyttsx3, each of them a separate install with its own Python environment and its own opinions about audio devices. That pattern still works. It is no longer necessary.

What follows is the whole thing: getting it talking, which of the fourteen checkpoints to actually pull, the licence line that decides it for anyone building something they intend to sell, how to drive it from code, and the specific requests that come back as a 400 rather than being quietly ignored.

What actually shipped

The release notes are terse. ollama run now “plays text or a chat model’s reply aloud as the audio is generated”, and applications “can stream audio through the OpenAI-compatible /v1/audio/speech endpoint”. The model behind it is Phonon, which Ollama’s announcement describes as a family of small text-to-speech models from Gradium, covering English, French, German, Spanish and Portuguese.

The hardware requirement is the first thing to check, because it is firm: the Phonon model page states the packages require Apple Silicon and Ollama 0.40.9 or later. If you are on an Intel Mac, a Windows box or a Linux server, generation is not available to you locally today. There is a real workaround involving a remote Apple Silicon machine, covered further down, and the docs do list playback backends for Linux and Windows — but the generation itself is Apple Silicon.

Output is 24 kHz mono. Audio streams as it is produced, so playback starts before the full text has been processed, which is why piping a chat model into it feels conversational rather than batch.

The pattern this replaces

If you have set up local speech before, you know the shape. One process runs the language model. A second process runs the speech engine. A script in between collects the model’s output, decides when a sentence has ended, hands that sentence to the engine, and manages the audio device. Each piece is simple; the glue is where the evenings go, and the glue breaks whenever either side updates.

That whole middle layer is now a pipe. The speech model is an Ollama model, pulled like any other, served by the same daemon on the same port, and addressable from the same client libraries. If you set Ollama up following the complete guide to running local LLMs with Ollama, everything you already have is what this runs on — there is no second runtime.

Getting Ollama text to speech running

Upgrade Ollama first; 0.40.9 is the floor and 0.40.11 is where the CLI playback arrived. Then pull the model and say something:

ollama pull phonon
ollama run phonon "Hello from Ollama."

Pick a voice with a flag. Ollama’s speech documentation names Zoey, Easton and Freya as examples and tells you to run ollama show phonon for the full list; voice names are case-insensitive and work with or without accents:

ollama run phonon --voice Zoey "Hi, this is Zoey."

Piped text is spoken as it arrives, which is the part worth trying first because it is the one that changes how the thing feels:

ollama run gemma4 --hidethinking "Tell me a fun fact about owls." | ollama run phonon

Running ollama run phonon with no text opens a >>> prompt where each line is spoken when you press Enter. Ctrl+C stops speech mid-flow; /bye or Ctrl+D exits.

To get a file instead of sound, redirect — when output is redirected the CLI writes a WAV rather than playing:

ollama run phonon "Save this to a file." > speech.wav

And the remote case, which is how you use this from a machine that cannot generate: set OLLAMA_HOST to an Apple Silicon box running the daemon, and the audio plays wherever the command runs.

OLLAMA_HOST=my-server:11434 ollama run phonon "Hello from the server."

The docs list what each platform uses to play: afplay on macOS, the first available of paplay, pw-play, aplay or ffplay on Linux, and PowerShell on Windows. On a server with no speakers at all, redirect to a file.

Which checkpoint to pull, and the licence that decides it

There are fourteen tags and the differences matter more than the sizes suggest.

Plain phonon is the 31M English model at a 113MB download, and it loads into 121MB of memory on an M5 Max. The 40M checkpoints are per-language — phonon:40m-en at 132MB, 40m-fr and 40m-de at 126MB, 40m-es at 129MB, 40m-pt at 125MB — plus phonon:40m-multilingual at 148MB covering all five. Each 40M model loads into 141MB. Every tag has an 8K context and takes text in. These are, by the standards of anything else you run locally, nothing: the largest is smaller than a phone photo album and sits in a seventh of a gigabyte of RAM.

Now the part that is not on any other page about this feature. The 31M English checkpoint is released under Apache 2.0. Every 40M checkpoint — English, French, German, Spanish, Portuguese and multilingual — is CC BY-NC 4.0, which limits use to noncommercial purposes. If you are narrating your own reading list, this is irrelevant. If you are putting a voice in something you sell, or in client work, the only checkpoint you can use is the 31M English one, and that is also the one the model page records as shipping a single voice named default. The licence, not the size and not the quality, is what picks your model here — the same way a licence rather than a capability tends to decide whether a local model is the right answer for business data.

Wiring it into something

The endpoint is /v1/audio/speech and it is OpenAI-compatible, which in practice means existing code works after changing a base URL to http://localhost:11434/v1.

curl http://localhost:11434/v1/audio/speech \
  -H "Content-Type: application/json" \
  -d '{"model": "phonon", "input": "Hello from Ollama.", "voice": "default"}' \
  --output speech.wav

Four parameters are supported. model is the tag. input is the text, capped at 4,096 characters per request — the CLI splits longer text at paragraph and sentence breaks, but if you are calling the API yourself, that splitting is your job. voice takes a name, and an unknown one returns a 400 that helpfully lists the valid ones. response_format is wav by default or pcm.

The two formats are both 16-bit mono at 24 kHz. WAV arrives with a header whose size fields hold maximum values, because the length is not known when streaming starts — worth knowing if you are feeding it to something strict that reads the header before playing. PCM is raw little-endian samples with no header at all, which is usually what you want if you are piping into an audio library rather than writing a file.

The response streams, so playback can start immediately rather than after the last word is generated. If you are building something that calls a chat model and speaks the answer, that streaming is what makes it feel responsive; it is the same architectural idea as the tool-calling loop in building a first AI agent with Ollama, where the useful behaviour comes from what you do with the output as it arrives.

Two things worth building first

The fastest way to find out whether this is useful to you rather than merely clever is to wire it into something you already do daily, and both of these are one line.

Read whatever I just copied. On macOS, pbpaste writes the clipboard to standard output, and piped text is spoken as it arrives:

pbpaste | ollama run phonon

Bind that to a keyboard shortcut and you have a proofreading tool. Hearing your own paragraph read back aloud is unreasonably good at exposing a sentence that does not work — far better than rereading it, because you cannot skim audio.

A briefing you listen to rather than read. Chain a chat model into the speech model and redirect the result to a file:

ollama run gemma4 --hidethinking "Summarise these notes in five sentences: $(cat notes.md)" \
  | ollama run phonon > briefing.wav

Drop that in a login item or a cron job and the file is waiting for you. The redirect is what turns playback into a WAV, so the same command without > briefing.wav simply speaks it instead.

Neither of these is a project. That is the point — the interesting consequence of a feature arriving inside a tool you already run is that the things worth building with it stop needing to be projects.

Where it bites

Unsupported options fail loudly. speed is not supported and returns a 400. So does instructions, and so do formats other than wav and pcm. This is a deliberate choice and a good one — a silently ignored parameter is worse — but it will break code written against OpenAI’s API that sets speed as a matter of habit.

Speech models only make audio. Send a chat, completion or embedding request to phonon and you get a 400. It is a model in the registry, but it is not interchangeable with one.

Give it prose, not markup. The docs say emoji, bullets and markdown markers are skipped during normalisation, while the model page warns that formatting such as markdown headings may be read aloud. Both can be true depending on the marker, and the practical reading is the same: feed it text meant to be spoken. If you are piping a chat model’s answer straight in, that model’s formatting habits become your audio.

Numbers and dates are not all handled alike. Prices, numbers, symbols, email addresses and URLs are expanded into spoken words. Times and numeric dates are read as written, so 10/26 will not come out as a date — spell it as “October 26” if you want it to sound right.

One voice on the free-to-sell checkpoint. Worth repeating because it is the most likely disappointment: the variety is on the models you cannot use commercially.

Is it any good?

Nobody independent has measured it yet, two days in. What exists is Ollama’s own benchmark, published in the announcement, and it should be read as exactly that: on a MacBook Pro with an M5 Max, generating 45 seconds of speech and taking the median of ten runs, Ollama reports being 35% faster than the next fastest engine, which was Gradium’s own runtime. The same post claims its implementation matches the word error rate of the Hugging Face Transformers reference implementation.

Both are vendor figures on vendor-chosen hardware, and a 35% margin over the model author’s own runtime is a narrower claim than it first sounds — it is a statement about Ollama’s implementation, not about Phonon being better than Piper or Kokoro at sounding human. On quality, the only test that matters is your ears and your text: pull the 31M model, run two paragraphs of your actual content through it, and listen. It costs a 113MB download.

What has changed here is not really the voice — that is Gradium’s work, and it existed before Ollama packaged it. It is that the second process is gone. A local assistant that talks used to be a weekend project with a brittle middle; it is now a pipe between two ollama run commands, with no glue in between to break when either side updates. If your assistant lives in a browser tab rather than a terminal, the same daemon is what Open WebUI talks to, and the speech models are already there waiting for the interface to catch up.