Summary
A miniapp that is itself a voice assistant has no way to stop the host assistant from acting on the
same speech. Both hear the microphone, and both answer.
Observed on Mentra Live: our miniapp was told "stand down", stopped its playback and went quiet — and
MentraOS's own assistant then answered the question our miniapp had just been stopped mid-answer
on. The user had not addressed it and had just explicitly asked for silence.
Why there is no workaround
We read all 90 values of MiniappRequestType in @mentra/miniapp@3.1.0-dev.27. There is no
exclusive-microphone claim, no wake-word handoff, no assistant enable/disable, and no "this miniapp
owns voice" mode. The only occurrence of the string "assistant" anywhere in the SDK source is a
comment in modules/camera.ts.
Foreground state does not help either — UI_FOREGROUND exists, but the conflict happens while the
miniapp's background layer is running with the UI closed, which is the normal state for a voice
miniapp on a device with no display.
Impact
For a voice-first miniapp on displayless hardware this is not a rough edge, it is disqualifying: the
user cannot tell which assistant is speaking, cannot stop both with one command, and gets two answers
to one question. On Mentra Live specifically there is no screen to disambiguate them.
Request
Any one of these would resolve it:
- A request type to suppress the host assistant for the lifetime of a miniapp session — symmetric
with setVoiceActivityDetectionEnabled() and setLoudnessGateEnabled(), both of which are
documented as per-miniapp overrides restored on disconnect.
- A manifest declaration (e.g.
voiceExclusive: true) that the host honours while the miniapp runs.
- Failing either, a documented user-facing setting to disable the built-in assistant, so an app can
at least tell the user what to turn off.
Note on the alternative
We understand the Bluetooth SDK path avoids this by not involving the Mentra app at all, and that is
the direction we are now taking. It is worth flagging that "build a voice miniapp" and "build a voice
app" currently have very different ceilings for this reason, and it is not obvious from the docs
which one a voice-first product should choose. A sentence in the miniapp docs pointing voice
assistants at the Bluetooth SDK would have saved us a week.
Environment
@mentra/miniapp 3.1.0-dev.27- Device: Mentra Live, MentraOS app
staging.20260808.*
- Miniapp declares
MICROPHONE and runs a background layer with no UI open
Summary
A miniapp that is itself a voice assistant has no way to stop the host assistant from acting on the
same speech. Both hear the microphone, and both answer.
Observed on Mentra Live: our miniapp was told "stand down", stopped its playback and went quiet — and
MentraOS's own assistant then answered the question our miniapp had just been stopped mid-answer
on. The user had not addressed it and had just explicitly asked for silence.
Why there is no workaround
We read all 90 values of
MiniappRequestTypein@mentra/miniapp@3.1.0-dev.27. There is noexclusive-microphone claim, no wake-word handoff, no assistant enable/disable, and no "this miniapp
owns voice" mode. The only occurrence of the string "assistant" anywhere in the SDK source is a
comment in
modules/camera.ts.Foreground state does not help either —
UI_FOREGROUNDexists, but the conflict happens while theminiapp's background layer is running with the UI closed, which is the normal state for a voice
miniapp on a device with no display.
Impact
For a voice-first miniapp on displayless hardware this is not a rough edge, it is disqualifying: the
user cannot tell which assistant is speaking, cannot stop both with one command, and gets two answers
to one question. On Mentra Live specifically there is no screen to disambiguate them.
Request
Any one of these would resolve it:
with
setVoiceActivityDetectionEnabled()andsetLoudnessGateEnabled(), both of which aredocumented as per-miniapp overrides restored on disconnect.
voiceExclusive: true) that the host honours while the miniapp runs.at least tell the user what to turn off.
Note on the alternative
We understand the Bluetooth SDK path avoids this by not involving the Mentra app at all, and that is
the direction we are now taking. It is worth flagging that "build a voice miniapp" and "build a voice
app" currently have very different ceilings for this reason, and it is not obvious from the docs
which one a voice-first product should choose. A sentence in the miniapp docs pointing voice
assistants at the Bluetooth SDK would have saved us a week.
Environment
@mentra/miniapp3.1.0-dev.27staging.20260808.*MICROPHONEand runs a background layer with no UI open