Picovoice Porcupine: an on-device wake word engine you train yourself
On-device wake word detection powered by deep learning
At a glance
- What is it?
- Porcupine detects a small set of always-listening phrases locally, with no audio sent to a server. The pitch is accuracy and a small footprint; the trade-off is a paid access key and a self-service console for custom keywords.
- Who is it for?
- Porcupine fits products that need a fixed set of wake phrases running locally on constrained hardware: a Raspberry Pi, a phone, a browser tab, a Cortex-M board. It is the wrong tool when you need to understand free-form speech (the README points to Rhino for that) or when you cannot accept a Picovoice Console account and access key in the pipeline.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Porcupine actually detects, and who it is for
Porcupine is a wake word engine. The README draws the boundary explicitly: it is the right product "if you need to detect one or a few static (always-listening) voice commands." That is a narrower job than speech recognition. The engine listens continuously and fires when it hears a phrase it was configured for, such as "porcupine" or "computer". It does not transcribe, and it does not parse intent.
The intended audience is developers building always-listening voice activation into a product. The README lists Arm Cortex-M, STM32 and Arduino boards, Raspberry Pi Zero through 5, Android and iOS, the four major browsers, and desktop Linux, macOS and Windows. The repository layout matches that breadth: binding/ holds per-language bindings, demo/ holds platform demos from C to Flutter to tkinter, and resources/ holds model files.
If your requirement is closer to an assistant that handles naturally spoken commands inside a domain, the README redirects you to the Rhino Speech-to-Intent engine. If you want the full Alexa-style experience, it points to the Picovoice platform. Porcupine is the trigger, not the conversation.
How the engine runs: local models, an access key, and a per-keyword file
The architecture is local inference against a model file. Porcupine ships as a native library per platform plus a thin binding in your language of choice, and the wake word itself is a parameter you pass at initialization rather than something the library hardcodes. In the Python demo the keyword is simply the string porcupine; for a custom phrase you train a model in Picovoice Console and point the SDK at the resulting file.
Two consequences follow from that design. First, audio never has to leave the device for detection to work, which is the whole point of an on-device engine. Second, the set of phrases is fixed at configuration time. The README describes the engine as scalable in the sense that it can detect multiple always-listening commands with no added runtime footprint, which is a statement about concurrent keywords, not about accepting arbitrary speech.
The README also claims cross-language coverage for English, Chinese (Mandarin), French, German, Italian, Japanese, Korean, Portuguese and Spanish, with other languages handled case by case for commercial customers. Treat that last clause as a real constraint rather than a footnote: if your product ships in a language outside the list, availability depends on a commercial conversation, not on a download.
One operational detail is easy to miss. An access key is required to run the engine, and it appears in every demo invocation. That key is issued through Picovoice Console, so the build and distribution path for your application touches a Picovoice account even though inference itself is local.
Installing Porcupine and running your first detection
The fastest path is the prebuilt Python demo package, which the README installs with pip. The package name is pvporcupinedemo, distinct from the SDK package used for embedding.
sudo pip3 install pvporcupinedemoWith a microphone attached, the demo runs from the terminal. It takes an access key and one or more keywords, and the README's example uses porcupine as the keyword string.
porcupine_demo_mic --access_key ${ACCESS_KEY} --keywords porcupineAccording to the README, the engine then processes microphone input in real time and prints to the terminal when it detects an utterance of the keyword. If nothing prints while you speak the phrase, the first things to check are microphone permissions for the terminal process and whether the access key was accepted.
For the demo suite rather than the packaged demo, the repository is cloned with submodules, which matters because the platform bindings live in those submodules.
git clone --recurse-submodules https://github.com/Picovoice/porcupine.gitThe README gives an SSH variant of the same command. After cloning, per-platform demo instructions live under demo/, for example demo/python for the Python demos and demo/dotnet/PorcupineDemo for the .NET build, which is compiled with dotnet build -c MicDemo.Release and run with dotnet run -c MicDemo.Release.
Where Porcupine is the wrong choice
The clearest limitation is scope. Porcupine detects static phrases. If your product needs to understand a sentence, extract slots, or handle phrasing variation, this engine will not do it, and the README says so by pointing at Rhino instead. Reaching for Porcupine and then bolting a recognizer behind it means you are running two systems where the README suggests one.
The second limitation is the access key and the Console dependency for custom keywords. A self-hosted pipeline with no external account in the loop is not what this project offers. The key is part of every documented invocation, and custom wake words are trained through Picovoice Console rather than derived locally from your own audio recordings. If your deployment rules forbid third-party accounts in the build or runtime path, that alone rules Porcupine out, regardless of the Apache-2.0 licence on the repository.
The third is language coverage. Nine languages are listed, and everything else is described as a commercial, case-by-case arrangement. A team planning a product for a language outside that list cannot assume self-service availability.
Finally, the accuracy claim needs to be read carefully. The README cites a comparison against PocketSphinx and Snowboy hosted in a separate repository, Picovoice/wakeword-benchmark, and states Porcupine is 11.0 times more accurate and 6.5 times faster than the best of those two on a Raspberry Pi 3. That is a third-party benchmark hosted by the vendor, on hardware and audio you do not control. It is a reason to look, not a substitute for measuring false accepts on your own recordings.
Porcupine compared with PocketSphinx and Snowboy
The comparison the README itself makes is against PocketSphinx and Snowboy, so that is the honest reference point. PocketSphinx is a general-purpose speech recognition toolkit; wake word spotting is one thing you can build with it, and you supply the acoustic model and the detection logic. Porcupine is a single-purpose engine: you hand it a keyword, it returns a detection. The difference is not accuracy alone but the amount of system you have to assemble.
Snowboy was a dedicated hotword engine, which makes it the closer analogue. The README's benchmark places Porcupine ahead of both on accuracy and speed, measured on a Raspberry Pi 3, and the benchmark lives in a separate repository so you can read the methodology yourself rather than take the summary line.
The practical difference between the two categories shows up in maintenance. A general toolkit gives you control over the model and the pipeline, and you own the tuning. A packaged engine gives you a supported binding for a dozen platforms and a console for custom keywords, and you accept the vendor's access key, language list and release cadence. Porcupine's last push to the repository was on 2026-09-10, and v4.0 was released on 2025-12-11, after v3.0 on 2023-10-26. That cadence is worth noting if you are pinning a version for a long-lived product.
Licence, releases and what upgrading costs
The repository is Apache-2.0, which is the licence you would expect for the bindings, demos and native glue. What the repository licence does not settle is the service side: the access key and the Console-trained custom keywords are Picovoice products with their own terms, and nothing in the README describes them as covered by Apache-2.0. Read those terms before you assume the whole stack is free to embed. This is not legal advice, and the licence text plus the Picovoice terms are the sources that matter.
On upgrade cost, the version history is sparse rather than continuous: v2.2 in April 2023, v3.0 in October 2023, v4.0 in December 2025. Major-version jumps that far apart usually carry binding changes, and this project ships bindings for Python, .NET, Java, Flutter, React Native, Android, iOS, web, NodeJS, C and microcontrollers. A major bump therefore touches many packages at once, and the release notes are where you would confirm which bindings changed. The README does not document a rollback procedure, so plan your own pinning strategy rather than expecting guidance in the repository.
What the demo directories tell you before you read the docs
The repository layout is a useful signal in itself. The demo/ directory contains android, c, dotnet, dotnet-vui, flutter, ios, java, mcu, nodejs, python, react, react-native, tkinter and web. That spread tells you the project is maintained as a multi-platform engine with a shared core, not as a Python library with ports bolted on. The include/ and lib/ directories hold the native interface and prebuilt binaries; binding/ holds the language wrappers.
That structure has a practical cost. A bug or a behaviour difference in one binding is a bug in one of a dozen wrappers, and the Python demo you install with pvporcupinedemo is a packaged convenience rather than the embedding path. When you move from the demo to your own application, you switch packages and start managing the model file and the access key yourself.
The tkinter demo is a small but telling inclusion: it exists so that someone can see detections on a desktop without wiring up an audio pipeline first. If you are evaluating Porcupine for an embedded target, that is the fastest way to hear the engine work before you commit to a cross-compilation toolchain.
Editorial conclusion
Porcupine fits products that need a fixed set of wake phrases running locally on constrained hardware: a Raspberry Pi, a phone, a browser tab, a Cortex-M board. It is the wrong tool when you need to understand free-form speech (the README points to Rhino for that) or when you cannot accept a Picovoice Console account and access key in the pipeline. Before committing, verify three things: that your target platform appears in the supported list, that the custom keyword you want is trainable in the console for your language, and what your own false-accept rate looks like on your audio, since the README's accuracy numbers come from a separate benchmark repository rather than from your data.
Frequently asked questions
How do I use Picovoice Porcupine to detect a wake word from a microphone?
Install the demo package with sudo pip3 install pvporcupinedemo, then run porcupine_demo_mic with your access key and a keyword such as porcupine. The README states the engine processes microphone input in real time and prints to the terminal when it detects the keyword.
What is Picovoice Porcupine best known for?
It is an on-device wake word engine built on deep neural networks, used for always-listening voice activation. The README describes it as accurate and lightweight, with bindings across microcontrollers, Raspberry Pi, mobile, browsers and desktop.
Does Picovoice Porcupine run on Windows, macOS and Linux?
Yes. The README lists Linux on x86_64, macOS on x86_64 and arm64, and Windows on x86_64 and arm64, alongside Android, iOS, browsers, Raspberry Pi and microcontroller targets such as Arm Cortex-M, STM32 and Arduino.
Can I train a custom wake word for Picovoice Porcupine?
The README states developers can train custom wake word models using Picovoice Console. Custom keywords are therefore produced through that console rather than from local recordings.
Which languages does Picovoice Porcupine support?
The README lists English, Chinese (Mandarin), French, German, Italian, Japanese, Korean, Portuguese and Spanish. It adds that support for additional languages is available for commercial customers on a case-by-case basis.
Community notes