bug: continuous voice input consumes Flux on movie dialogue and keeps submitting after HTTP 402

Describe the bug

I left voice input enabled while I watched a movie. AIRI treated the movie dialogue as chat input and exhausted my Flux balance.

The chat received short, unrelated transcript fragments. AIRI replied to these fragments and repeatedly asked for clarification. Each turn triggered another paid LLM request.

After the balance ran out, voice input continued to trigger chat requests. The app displayed repeated error notifications:

Voice input failed to send to chat: Remote sent 402 response:
{"error":"PAYMENT_REQUIRED","message":"Insufficient flux"}

Steps to reproduce

1. Enable continuous voice input in the desktop app.
2. Play a movie with dialogue audible to the selected audio input.
3. Leave voice input enabled without addressing AIRI.
4. Observe the chat messages and Flux transaction history.

These steps describe the reported incident. A separate controlled reproduction is not complete.

Actual behavior and impact

• Background dialogue automatically becomes chat messages and triggers paid replies.
• The screenshot shows five llm_request charges of 80 Flux between 15:08:06 and 15:08:54 on September 24, 2026.
• Those five requests consumed 400 Flux in 48 seconds.
• Each visible request reports approximately 79,000 input tokens, with only tens to roughly 100 output tokens.
• After payment failures, automatic submissions continue and repeated notifications cover the desktop character.

The screenshots establish LLM charges. They do not establish separate ASR charges or explain the full input-token composition.

Expected behavior

Continuous voice input needs protection against unintended spending from background speech.

• Automatic paid replies need a clear user-controlled boundary, such as an explicit activation mode or a spending limit.
• A payment-required response must pause automatic voice submissions and discard pending automatic submissions.
• The app must show one clear paused-state notification and require an explicit user action to resume.

The activation policy needs a product decision. Speech detection alone cannot distinguish movie dialogue from speech addressed to AIRI.

Code investigation

Local source inspection at b38ae4a62f9034a2b2e67f0b3ded5991e0170f32 shows behavior consistent with the report:

• handleStreamingSentenceEnd sends each nonempty final sentence directly to chat after the assistant-speech suppression check.
• sendVoiceInputTextToChat reports send errors but does not pause voice input on HTTP 402.
• The recorder-backed path also sends buffered transcripts to chat.

The installed app version and production request payloads remain unverified. The source revision above identifies the inspected code, not the installed build.

System Info

• Platform: macOS desktop, based on the supplied screenshots.
• Incident date: September 24, 2026.
• App version, macOS version, ASR provider, and LLM model: not recorded.

Screenshots