The voice assistant is "on" whenever its microphone pipeline is actively capturing audio, which happens in one of three states: always-listening for a wake word, push-to-talk after a button press, or engaged in an active session. A smart speaker is essentially always capturing locally in a low-power buffer, but it only transmits to the cloud after a wake-word match or a deliberate activation. The practical answer depends on which device you mean and which indicator you trust.
This distinction matters because "on" is ambiguous. It can mean the microphone circuit is powered, the wake-word detector is running, a cloud connection is open, or a human is reviewing a transcript. Those are four different states with four different privacy and battery consequences. The sections below separate them, quantify the timing, and show where the common assumptions break down.
Wake-word detection mechanism
A smart speaker or phone keeps a small, dedicated processor running continuously. That chip holds a compact acoustic model — a few hundred kilobytes to a few megabytes — trained to recognize one phrase. Audio flows into a ring buffer of roughly one to a few seconds. The model scores short frames of audio, typically 20–30 milliseconds each, against the target phrase.
Only when the score crosses a threshold does the device "wake." At that point it opens the network connection, streams audio to the cloud, and lights its indicator. The always-on part is the local detector, not the cloud. That is why a speaker responds in well under a second and why it can work (for the wake word) with the internet down.
The counterintuitive part is that false accepts and false rejects trade off against each other in that threshold. A device tuned to catch every whispered "Alexa" will also fire on television dialogue. A device tuned to never misfire will ignore you from across a noisy room. Manufacturers pick a middle setting and tune it per product, which is why two speakers in the same house can behave differently.
Push-to-talk bypasses the detector entirely. A button press, a remote control, or a steering-wheel control opens the microphone stream directly. This is why a phone's assistant can be "off" for wake-word purposes yet respond instantly to a long button hold.
Quantified context: latency, buffers, and session windows
The timing numbers are where thin explainers go vague. Here is what the architecture implies. Local wake-word detection adds roughly 100–500 milliseconds before the cloud request begins. Round-trip cloud processing for a simple query — weather, timer, unit conversion — typically returns a spoken answer within about 1–3 seconds on a good connection. Complex queries that hit multiple services take longer.
The session window is the interval after a response during which the device keeps listening without another wake word. That window is usually a few seconds and is what lets you say a follow-up like "and tomorrow?" without repeating the wake word. Once it closes, the device returns to wake-word-only mode.
Audio buffering is the privacy-relevant number. Devices generally keep a short pre-roll buffer so the beginning of your command is not clipped. That buffer is on the order of one to a few seconds. It is held in volatile memory and overwritten continuously. The buffer is why recordings can include a moment before you spoke the wake word.
| Activation path | Trigger | Typical latency to first response | Mic state before trigger |
|---|---|---|---|
| Wake word | Acoustic model match | ~1–3 s | Local buffer only |
| Push-to-talk | Button or remote press | ~1–3 s | Mic off until press |
| Active session follow-up | Open session window | Near-instant | Streaming to cloud |
| App-initiated | Tap in companion app | ~1–3 s | Phone mic |
| Routine or schedule | Time or device event | Variable | Configured by user |
The table's key column is the last one. "Mic state before trigger" is the honest measure of exposure, and it differs sharply across paths.
Edge cases that change the answer
Several situations move the device out of its normal pattern. Each is worth knowing because each changes what "on" means in practice.
Muted microphone: a hardware mute switch or software mute disables the wake-word detector. The device is not listening for the wake word even though it remains powered and networked. No network: the wake word still fires locally, but the device cannot complete the request. It typically signals an error rather than staying silent. Do Not Disturb and similar modes: these usually suppress notifications and responses, not the microphone itself. The detector keeps running. Low battery on a phone: some devices disable always-on wake-word listening to save power, leaving only button activation. Multiple devices in earshot: the cloud arbitration picks one responder, usually the closest or first to hear. The others heard you too. Account-linked review: some providers let you opt in or out of human review of voice samples. That is a separate consent layer from the microphone itself.
The professional caveat here is that mute indicators are not all equal. A true hardware switch physically disconnects the microphone. A software mute may only stop the detector while the microphone circuit stays powered. If the physical guarantee matters to you, check whether the device has a hardware switch, not just a mute command.
Misconceptions about "listening"
The most common misconception is that the assistant is streaming everything to the cloud all the time. It is not. Continuous upload of raw audio from every speaker would be enormous and expensive, and it is not how the architecture works. The always-on component is a small local classifier, not a live uplink.
A second misconception is that a lit indicator means a human is listening. The light means the device is in an active capture or response state. Human review, where it exists, is a separate and usually opt-in process applied to a subset of recordings.
A third is that deleting your voice history turns the microphone off. It does not. History deletion removes stored recordings and transcripts; the wake-word detector keeps running exactly as before. These are independent controls, and conflating them leads people to feel protected when they are only partly protected.
A fourth is that phones and speakers behave the same. A phone has battery pressure and motion context that a plugged-in speaker lacks, so its always-on behavior is more aggressively managed. The same vendor can ship different listening policies on different hardware.
Practical actions and thresholds
You can make the "is it on" question concrete with a few checks. None require special tools.
Confirm the physical state. Look for a hardware mute switch or a documented mic-off indicator, and verify in the device's own settings that it reports muted. Audit activation history. Most assistants keep a log of when they activated. Review it for unexpected wake events, which reveal false accepts from TV or conversation. Turn off human review if it is optional. This is a distinct setting from history deletion and from microphone mute. Set a deletion window if offered. Some platforms support automatic removal of voice recordings after a set period, often a few months. Test the boundary. With the mic muted, say the wake word and confirm the device does not respond. That single test separates a real mute from a cosmetic one. For phones, check battery-optimization settings, which can silently disable always-on listening.
The threshold that matters most is the hardware one. If a device has no physical microphone disconnect, treat the software mute as a strong but not absolute guarantee. For most households that is acceptable; for a bedroom or a sensitive workspace, the physical switch is the control that actually answers the question.
Limitations and what cannot be concluded
Public documentation does not disclose every buffer length, threshold, or retention period, and vendors change them. Any specific millisecond figure above is an architectural estimate, not a published specification. The honest position is that the mechanism is well understood while the exact parameters are proprietary and versioned.
Nor can this explainer tell you what a specific firmware build on a specific model does today. Behavior can change with an update without any visible sign. The reliable approach is to verify on your own device using the practical checks above rather than trusting a general claim. Where a vendor publishes a privacy whitepaper or settings page, that document outranks any third-party summary, including this one. The underlying science of wake-word detection is stable; the product-level details are not, and the difference is where most confident answers go wrong.