That was a reasonable job for AI.

Then it got to Rosemount Museum.

Rosemount is not a giant modern museum with broad galleries and polished concrete floors. It is a historic mansion. An actual house. A beautiful, old, furniture-filled house with narrow rooms, delicate artifacts, antique flooring, and enough stairs to qualify as a cardio program.

The AI looked at all of this and apparently thought: Yes. We should formally investigate riding a full-size electric scooter through the parlor.

The request

The message it sent was magnificent in its seriousness.

It identified my NAVEE GT3 Pro, gave the width, weight, motor rating, maximum speed, and planned pedestrian-mode speed. It cited the federal mobility-device regulation. Then it asked about accessible entrances, indoor routes, room-by-room restrictions, preservation concerns, advance notice, acceptable assurances, and whom staff should contact if anyone questioned access.

It even acknowledged the mansion might contain narrow passages, stairs, and delicate original furnishings.

In other words, the AI had already assembled every fact needed to realize this was insane. It simply arranged those facts into a very professional email instead.

Here is part of the actual request it sent:

Because it is a stand-up consumer scooter, I’m asking that it be reviewed as an other power-driven mobility device under 28 C.F.R. § 36.311. It is about 23.2 inches wide, weighs about 48.5 pounds, and has a 400W rated motor. Although its maximum speed is about 20 mph, I will use pedestrian mode at approximately 3.7 mph, yield to others, and follow reasonable safety rules.

Would you please confirm whether I may use it on the grounds and during guided tours inside the mansion? I understand the historic building may have narrow passages, stairs, delicate original furnishings, and other location-specific limits.

It then asked for the accessible entrance and routes, every room where the scooter could not be accommodated, the specific safety or preservation reason for each restriction, operating conditions, advance-notice requirements, acceptable assurances, and the person staff should contact if access was questioned.

The reply

The museum director answered with more patience than any machine deserved.

She explained that they would love to accommodate the scooter, but the building creates real problems. The mansion has 184 stairs. Its elevator is original, carries one person at a time, and is too small for wheelchairs, walkers, and the scooter.

Turning around in many viewing areas would be difficult. Other guests and irreplaceable artifacts would be close by. The 136-year-old parquet flooring is delicate.

All completely predictable.

Then came the plot twist: they had already tried it.

About a year earlier, the museum allowed a similar scooter inside. It left major scuff marks on the old parquet floor, was difficult to maneuver, caused several near misses, and contributed to a tripping situation.

I had been laughing because AI proposed an obviously ridiculous experiment. The museum had to reply with the results of the previous experiment.

The actual reply somehow made it even funnier:

We would love to allow the NAVEE GT Pro Scooter inside the museum, however it actually does create a few issues. Let me explain. We did allow a similar scooter about a year ago and unfortunately, we did encounter several problems.

The scooter left major scuff marks on the 136 year old parquet flooring on the first floor and they were difficult to get rid of, due to cracks in the flooring. Turning around in many of the viewing areas was difficult and often not an option. It was also difficult to navigate around and with other guests on the tour. There were several near misses and one tripping situation.

There are 184 stairs in the mansion. We do have an elevator, however it is the original and fits one person at a time. Wheelchairs and walkers do not fit in the elevator, and the scooter was also too long to fit.

That is not a refusal. That is a field report.

Somehow, they were still incredibly nice

This is the part I do not want lost in the joke: Rosemount handled the request exceptionally well.

The director did not dismiss the disability need or send a one-line “no.” She explained the real safety and preservation problems, said the scooter would be fine outside and around the grounds, offered to inspect it in person, and described the museum’s alternative arrangements.

They keep wheelchairs on each floor because the original elevator cannot carry one. Staff can help push a chair and can carry it between floors when necessary. That is a thoughtful response to the limits of a building designed long before modern accessibility standards.

The director also wrote:

The scooter is totally fine on the property and anywhere outside. The museum does have wheelchairs available for anyone who would like to use one while on tour and we can provide someone to push the wheelchair as well. We have a wheelchair available on each floor (due to the elevator issue), or a staff member will carry the chair to the next floor for you.

I would be happy to look at the scooter upon your arrival, with the understanding that I do reserve the right to uphold our original answer.

The quoted portions are lightly trimmed for length. The director’s signature and personal contact details are omitted.

The museum was not the failure here. The AI was.

The actual bug

The automation treated every attraction as if it belonged to the same category.

attraction found
  -> ask about scooter
  -> include every legal and technical detail
  -> send

What it needed was one additional check:

is the attraction literally an antique house?
  -> yes
  -> maybe let a human look at this one first

AI did not misunderstand the task. It followed the task with terrifying competence and absolutely no instinct for the physical comedy of the result.

That is how a simple accessibility question became a formal proposal to pilot a 48-pound electric scooter around 136-year-old parquet floors—and how a museum director, with a completely straight face, delivered the incident report from the last person who tried it.

The AI had a plan. The mansion had already tested it.

Wispr stopped working on my Pixel 7 Pro again. I tried the recovery app I built around it. That did not fix it. I rebooted. That did not immediately fix it either. The phone then crashed, appeared to reinitialize parts of the system, and Wispr eventually worked again.

I am tired of this. I paid for Letterly as an alternative even though I still prefer Wispr’s results. Letterly does not work nearly as well for the way I dictate. This is not a claim that Letterly wins a controlled accuracy or reliability benchmark; it is where repeated interruptions have pushed me as a customer.

I want Wispr to work. Liking the output does not make losing my input method acceptable.

What we actually found on the phone

The investigation connected to the actual Pixel and examined retained Android crash records, process exits, permissions, services, recovery status, and alarm scheduling. Wispr was version 2.3.1, build 156, on Android 16. All times below are Mountain Daylight Time on September 5.

During the later working-state inspection, Wispr’s accessibility service was enabled and bound. Its effective overlay permission was allowed, its microphone permission was granted, and it was already exempt from device-idle optimization. Roughly 45 GB of storage was free. Simply saying “enable the permissions” does not explain this incident.

We did not prove that Wispr caused the Android crash. The system exception explicitly describes the lost network stack as a downstream effect. The initiating cause was not established by the surviving records. Nor did we capture the original, pre-reboot Wispr failure state this time. The invisible, non-touchable overlay documented below is an earlier verified incident, not a diagnosis we can automatically apply to every later failure.

My recovery app needs fixing too

The workaround is mine, and its shortcomings belong in this update:

• It could not reach its ADB control connection, so the actual repair never began on the recorded failed attempt.
• Its concurrency lock is acquired after ADB startup and discovery. Those operations therefore sit outside that protection. A socket collision is confirmed; the exact competing caller is not.
• The app reported termux_check_requested, while the worker’s separate result was control_unavailable. Requested is not checked, and checked is not repaired.
• Android delayed the nominal three-minute alarm by about 51 minutes under app standby during inspection. My original wording below overstated that schedule as an execution guarantee.

The next repair is specific: protect connection startup, rediscover the paired connection after reboot, report results independently of that connection, and verify actual scheduling under standby. Then test a successful dictation after recovery. No permanent fix was installed during this investigation, and there is no evidence that my helper was what eventually restored Wispr that night.

What I want from Wispr

Please make the Android input path recover reliably, expose a useful failure state, and provide diagnostics that distinguish overlay failure, accessibility disconnection, and transcription or insertion failure. Users should not need a second application to babysit the first.

Wispr’s bubble troubleshooting guide describes reconnection and repair indicators. Its release notes list Android 2.3.2, but the listed change is sign-in handoff—not a demonstrated fix for this incident.

I would rather keep using the dictation I like than build another app or keep paying for alternatives. But reliability has to be part of the product. The detailed findings above are why I am asking for a real fix, while being clear about the problems in my own workaround and the causes we have not established.

The original September 2 field note follows. Raw device logs and private identifiers are not published.

Original September 2 field note

Wispr Flow disappeared from my Pixel 7 Pro on September 2.

The obvious explanation was wrong.

The app was still installed and enabled. Its overlay permission was allowed. Its Accessibility Service was bound. The foreground service and process were alive. I had a normal text editor focused, the keyboard was open, and the microphone was not recording.

The Flow bubble was even still attached to Android’s window manager.

It was just invisible and impossible to touch.

The failure state

This happened with Wispr Flow 2.3.1 on Android 16. The important window-manager fields looked like this:

window type: APPLICATION_OVERLAY
requested size: 263 x 263
alpha: 0.0
shown alpha: 0.0
flag: NOT_TOUCHABLE

That is a nasty failure mode because almost every normal health check says the app is fine. Reinstalling, randomly toggling permissions, or blaming Android’s process killer would have missed the actual condition.

The reliable test was not “is the permission enabled?” It was:

Is the real overlay window attached, visible, nontransparent, on screen, and touchable while a harmless editor has an active input connection?

In this case the answer was no.

Wispr’s own Android documentation says the Flow bubble depends on both display-over-other-apps permission and its Accessibility Service. Those prerequisites were present here. The broken state was one layer deeper: the overlay lifecycle had produced an attached but inert window. The official Android setup guide and Flow overview explain the intended permission stack and bubble behavior.

What restored it

The recovery had to account for an Android 16 behavior that can make a careless fix destructive: force-stopping Flow removes Flow’s component from the enabled Accessibility Service list.

So the recovery order was:

1. Capture the complete enabled Accessibility Service list.
2. Refuse to proceed if the phone identity, editor state, overlay permission, microphone state, or non-Flow service baseline is unsafe.
3. Confirm the same fault twice, 20 seconds apart.
4. Force-stop only Wispr Flow.
5. Verify every non-Flow accessibility component survived, normalizing Android’s short and fully qualified component-name formats.
6. Reinsert only Flow’s accessibility component.
7. Launch Flow, return to the original editor, and inspect the actual bubble window again.

The repaired window read:

alpha: 0.8
shown alpha: 0.8
on screen: true
visible: true
touchable: true
requested size: 263 x 263

It held that state in a second check 20 seconds later. The microphone remained idle, and every other accessibility service remained enabled.

I added a watchdog because this was not a one-off

I have now seen the Flow affordance disappear on both a TCL phone and this Pixel. A manual repair is useful; a recurring input failure needs a guarded recovery loop.

The Pixel now has an isolated, device-bound watchdog modeled after the one I built for the TCL. It requests a safe check on a nominal three-minute schedule and after boot/unlock events. September 5 correction: Android can defer that alarm, and a requested check can fail before reaching Wispr; see the update above. It does not type, record audio, or touch arbitrary apps. It refuses to repair while the phone is locked, the microphone is active, a sensitive input type is focused, the overlay permission is missing, or the non-Flow accessibility baseline cannot be proven.

It also has:

• two-sample fault confirmation
• a 10-minute cooldown
• a maximum of six recoveries per day
• concurrent-run locking and stale-lock recovery
• rollback on accessibility-list mismatch
• device, model, and app-scoped identity binding
• a post-repair requirement that the original editor regain focus and the bubble become visible and touchable

The offline regression suite passed 19 scenarios, including healthy no-op, sleeping and locked devices, sensitive editors, an active microphone, revoked overlay permission, wrong-device refusal, a flapping fault, concurrent workers, stale locks, missing accessibility, a missing bubble, and an inert bubble.

Then I tested it against the real phone. The worker first reported a healthy no-op with all accessibility services unchanged. It later detected the inert bubble, performed one ordered restart, preserved the accessibility list, and logged a verified healthy bubble. When I deliberately injected another fault inside the 10-minute window, it correctly refused a second restart as cooldown instead of entering a repair loop.

That last distinction matters. “The automation ran” is not proof. A useful watchdog needs evidence that it repaired the intended condition, evidence that it preserved unrelated state, and evidence that it knows when not to act.

What Wispr should fix

The product-side fix is smaller than my workaround.

Wispr’s Android watchdog should treat an attached overlay as unhealthy when any of these are true in an active text-input context:

• effective alpha is zero
• shown alpha is zero
• the window is non-touchable
• the overlay is off screen or not visible

When that state survives a short debounce, Flow should rebuild the overlay without requiring the user to toggle permissions or restart the whole app.

The current health model appears to stop too early at “service alive” or “window attached.” An invisible, non-interactive microphone button is not healthy just because Android still has a window record for it.

The practical takeaway

If Flow vanishes on Android, check the actual overlay state before tearing apart the installation:

1. Confirm the app, Accessibility Service, and overlay permission are present.
2. Open a harmless text editor and show the keyboard.
3. Confirm Flow is not actively recording.
4. Inspect whether the overlay is attached but transparent or non-touchable.
5. Preserve the full accessibility list before any force-stop or rebind.
6. Verify the repaired bubble itself, not just the process.

Wispr Flow is still the dictation tool I keep using. That is exactly why this failure is so aggravating: when a tool becomes part of your input system, an invisible button is not a cosmetic bug. It is an outage.

I have tried enough voice-input tools to know the usual pattern. They are impressive for a day, awkward for a week, and forgotten by the end of the month.

Wispr Flow has been different. I installed it, linked it to my account, customized it, and kept using it. I put its push-to-talk shortcut on one of the four keys of a little USB controller at my desk. Ctrl+F8 now turns speech into text without making me stop what I am doing and hunt for a microphone button.

That physical key matters more than the demo-reel AI. It turns dictation from a separate activity into an input method.

Flow is now how I dump a rough thought into ChatGPT or Codex, write a note before it evaporates, and get through longer technical explanations without forcing every sentence through a keyboard. It is also an unusually good test of the gap between what an AI heard, what I meant, and what finally appeared on screen.

My verdict after using it across Windows and Android is simple:

Wispr Flow is an excellent intent-preserving editor. It is not a verbatim transcript, and it should not be treated like one.

That distinction explains nearly everything I like about it—and nearly every place where it can get me in trouble.

Why it actually stuck

Normal phone dictation makes me adapt to the machine. I have to speak in a neat little stream, avoid pauses, and hope the timeout does not decide I am finished while I am still assembling the thought.

That is not how I talk when I am thinking. I pause. I restart. I swear. I jump ahead, back up, and insert the piece I forgot. When I am frustrated or improvising, I get faster and more bursty. A tool that demands broadcast-ready speech before it will produce useful text has already lost.

Flow tolerates the rough input and returns something closer to what I would have typed after editing myself. It removes filler, adds punctuation, fixes capitalization, and often turns a spoken pile of parts into a clean paragraph. The official product description is unusually accurate on this point: Flow is built to format and polish speech as it becomes text, not merely to dump raw speech recognition output into a box.

That makes it especially good for:

• AI conversations, where getting the complete intent onto the screen matters more than preserving every false start
• technical notes, where I need to keep moving while the idea is hot
• replies and drafts that would otherwise die in the gap between “I should write that” and opening the right app
• accessibility, because voice can bypass some of the physical and cognitive friction of keyboard-first software

The four-button controller completed the loop. One key starts Flow from wherever I already am. I do not have to change windows or break concentration. Flow’s desktop shortcuts are customizable, and its documentation covers push-to-talk, hands-free dictation, and paste-last-transcript controls. The important part is not the particular key combination. It is making voice input physically immediate.

If I had to explain why Flow survived when other dictation apps did not, I would not start with transcription quality. I would start with activation cost. A good tool that is one button away gets used. A great tool buried behind six taps becomes shelfware.

The one-button note machine

The same lesson carried over to Android.

I wanted a capture path that did not punish pauses and did not require me to organize the thought before recording it. The workflow I ended up building was deliberately simple:

1. Hold a hardware button.
2. Open a blank, multiline Flow note.
3. Talk for as long as the thought takes.
4. Confirm it.
5. Append the result—with a timestamp—to my running quick-note file.

It does not overwrite the previous note. It does not make me choose a folder while I am still thinking. It just catches the thought and hands it to the place I already use for rough notes.

That is a better use of AI dictation than trying to make every voice memo into a pristine document. Capture first. Sort later. The tool’s job is to reduce the distance between a thought and a durable piece of text.

Flow has its own Android quick-note behavior and floating controls, but the value came from fitting it into my workflow rather than accepting the default app journey. A personal dictionary and snippets help for recurring names, acronyms, and phrases. Context helps it decide whether I probably meant a technical term or an ordinary word. The system gets better when I teach it the vocabulary of my actual day instead of expecting a generic model to know everything.

The Android bubble is the weak link

The desktop experience has been steady. Android has been more complicated.

On both my Pixel and a TCL phone, the Flow icon or floating bubble has vanished. Sometimes the keyboard still appears, but the Flow affordance does not. On the TCL, recovery worked and then the problem came back later. That recurrence matters: a one-time fix is not the same thing as a reliable system.

The reason is not mysterious. Flow on Android depends on a small stack of special permissions: the floating overlay, accessibility access, and the operating system’s willingness to keep the relevant service alive. Wispr’s own Android setup guide says the app needs “display over other apps” and Accessibility Service permissions, and that a warning symbol on the bubble can indicate revoked accessibility access. The company currently describes Android as a beta experience in its platform guide.

That beta label matches my experience.

I eventually built a conservative self-heal around the recurring TCL failure. It does not blindly poke the phone every time an icon disappears. It waits for the same fault to appear twice, rate-limits repairs, and preserves the other enabled accessibility services. That is overkill for a normal consumer—but it is also evidence that the bubble is not yet something I would trust as the only path into a critical workflow.

The practical Android recovery order is:

1. Check whether Flow still has Accessibility Service permission.
2. Check its permission to display over other apps.
3. Open Flow directly and confirm the floating control is enabled.
4. Reboot only after checking the permissions, because a reboot that leaves the cause untouched is not a repair.

If the bubble keeps disappearing, record the conditions instead of performing random rituals. Was battery optimization active? Did the accessibility permission revoke? Did it happen after an update or reboot? A repeatable failure with evidence is fixable. A collection of desperate taps is not.

Sometimes the transcription is fine and the app is the problem

I hit another failure in MobaXterm: Flow showed that it was recording, but the words did not reliably appear in the terminal. Copy and paste were acting strange too.

That looked like a speech-recognition problem. It was not.

Flow had captured the speech. The failure was at the last inch, where the finished text had to be inserted into an application with its own terminal keyboard and paste rules. Fixing the native MobaXterm key routing solved the useful part without breaking my Flow configuration or the four-key shortcut.

This is an important troubleshooting distinction:

microphone → recognition → cleanup → clipboard/keystrokes → target app

“It heard me but no text appeared” can fail at any arrow in that chain. Reinstalling the dictation app is a bad first move if the target program is swallowing the paste event. Before tearing up a working configuration, test the same phrase in a plain text editor. If it appears there, recognition is probably not the problem.

What Flow changes when it cleans me up

I ran a more deliberate speech test because “it seems good” is not enough for technical use.

The result was reassuring and cautionary at the same time.

In normal spontaneous speech—including filler, profanity, restarts, and technical discussion—Flow usually preserved my meaning. It handled terms such as DMARC, DKIM, and SPF correctly when I used them in context. A rambling Area 51 story came back cleaner but semantically intact. Carrier sentences helped it choose the intended word when isolated minimal pairs were ambiguous.

But Flow also proved that it is willing to edit.

Some isolated word pairs changed or disappeared. Phrases such as “beside” versus “inside,” or “plain towels” versus “clean towels,” could move in the wrong direction. Improvised singing and lyric-like material were rewritten substantially. The polished result often sounded more coherent than the raw speech, but it was not a court reporter’s record of what left my mouth.

That behavior is a feature until the exact wording is the data.

I trust Flow for:

• getting the intent of a long AI prompt onto the screen
• turning an unstructured thought into a readable note
• drafting a message I will review before sending
• explaining a technical problem where the surrounding context disambiguates the terms

I verify Flow carefully for:

• IP addresses, commands, ticket numbers, prices, dates, and medication names
• quotations or anything represented as somebody’s exact words
• names and unfamiliar proper nouns
• short phrases where one changed word reverses the meaning

And I do not use the polished output as the only record for a consequential conversation.

The doctor-visit gap

The missing feature I keep circling is meeting capture.

I do not need another corporate meeting bot hovering in every call. The real use case for me is a doctor visit: preserve the discussion, recover the action items, and give me something I can analyze later when I am not trying to listen, remember, and ask the next question at the same time.

Wispr now advertises a Notetaker and voice memos, but its current pricing and feature page lists those features as Mac-only. That does not solve my Windows-and-Android version of the problem.

Could I record a visit and analyze it later? Technically, yes—with the consent and recording rules that apply where the conversation happens. But the right source would be the original audio plus a transcript, not a cleaned Flow paragraph. For medical instructions, the distinction between “what was said” and “what an AI inferred I meant” is too important to collapse.

This is where Flow and a product such as Letterly stop being simple substitutes. Flow wins my daily use because it lives at the point of typing. A voice-note or meeting product can be better when the recording itself is the artifact. I do not need to replace Flow to cover that gap; I need the right second tool and a clear boundary between the jobs.

The privacy switches deserve real attention

Voice input feels lightweight because it disappears into text. Underneath, it can involve audio, application context, screen content, cloud processing, and stored transcripts. That deserves more than clicking through the onboarding screens.

Wispr documents two relevant modes. Cloud Sync can store transcript data in the account; Privacy Mode keeps more data local and limits some context features. The company says users can control whether their data is used for model improvement, and it describes zero-data-retention arrangements with some third-party processors. Its privacy-mode documentation is the place to read the tradeoffs rather than guessing from the setting name.

Context Awareness is useful precisely because it can look beyond the audio. Depending on platform and settings, Wispr says that context may include the active app, nearby text, screen content, selected files, screenshots, or conversation history. Password fields are excluded, but the company notes that a custom web form may not always be identified as a password field. Read the Context Awareness documentation and choose the setting deliberately.

There is also a current documentation inconsistency worth knowing before a business or healthcare deployment. Wispr’s public privacy page advertises SOC 2 Type II and ISO 27001. Its more detailed security and compliance FAQ says the current status is SOC 2 Type I, with a Type II observation period and ISO 27001 certification work underway after an earlier auditor issue invalidated previous reports. That does not prove the product is unsafe. It does mean a buyer should request the current report and verify the attestation instead of relying on a badge or a marketing sentence.

My personal operating rule is straightforward: do not dictate passwords or secrets, review the model-improvement and sync settings, use Privacy Mode when the context is sensitive, and verify the current compliance evidence before putting regulated work through it.

What I would improve next

Flow already clears the hardest hurdle: I want to use it. The improvements I care about now are less glamorous than model benchmarks.

1. Make the Android bubble boringly reliable. An input method cannot randomly disappear.
2. Bring recording and meeting capture to Windows and Android. The doctor-visit use case should not require a Mac.
3. Expose the boundary between transcript and rewrite. Let me compare the recognized wording with the polished wording when exact language matters.
4. Make insertion failures diagnosable. If Flow captured the text but the destination rejected it, tell me where the chain broke.
5. Keep expanding personal controls. Dictionary entries, snippets, app-specific style, and hardware shortcuts do more for daily usefulness than another generic “AI writes faster” claim.

The verdict

Wispr Flow is the first dictation app I have integrated deeply enough to annoy me when it disappears.

That is praise.

It has earned a dedicated hardware key on my desk. It catches thoughts that would otherwise be lost. It lets me speak in the messy, stop-and-start way I actually think and produces text that is usually ready to use. It works in the apps where I already write instead of demanding that I live in its editor.

But I use it as an intelligent writing layer, not as ground truth.

When the goal is communicate what I mean, Flow is excellent. When the goal is preserve exactly what was said, I want the recording, a faithful transcript, and human review. When no text appears, I check the entire input chain before blaming recognition. On Android, I treat the floating bubble as beta infrastructure, because that is what it has behaved like. And when the content is sensitive, I configure the privacy and context settings instead of assuming the defaults match my risk.

The best tools do not merely perform well in isolation. They fit the person using them. For me, the winning combination was Flow’s cleanup, one physical button, a personal vocabulary, and a few carefully engineered escape hatches for the places where software still gets weird.

That is much more useful than perfect dictation in a demo.