I asked Leo to go through every log and put together a month in review. Orion drew the art.

👉 Open the full interactive recap

It’s one long scroll that works well on a phone. The highlights:

• 2,197 AI work sessions and 136,476 tool actions: shell commands, file edits, web searches.
• 32.9 million tokens written by Claude, roughly 24.6 million words, or about 274 novels.
• Orion worked all 31 days. It ran 1,996 sessions on just 96 human messages. Most of that was scheduled jobs and robots handing work to other robots.
• 101,348 shell commands from Orion alone, about one every 26 seconds for a month.
• 36% of Claude’s work happened between 10 PM and 6 AM.
• 952 images drawn by ChatGPT’s image tool.
• 65 projects shipped. They include a camera system that finds wildlife and lightning on its own, a boom detector that triangulates explosions across cameras and microphones, a phone voice recorder with a searchable memory, and several new sections here on ErrorZap.

The recap also has a blooper reel. My favorite is the explosion detector that heard a real boom, correctly flagged it as a threat, and then suppressed the alert because the sound also matched fireworks.

Show-off cards

Each card pairs one picture with one stat.

There are 14 cards in all at the bottom of the recap page.

Client names and private details have been left out or made generic. All the numbers come from the Claude Code and Codex logs on my PC.

That’s backwards. The AI is the one that knows the fix. It should be doing the tapping.

So we set it up so it can. Claude can now reach any of my phones from anywhere, over my private network, after every reboot, and change them for me. It fixes settings, silences noisy notification channels, installs new app builds and takes screenshots. This is how we built it, including the parts that fought back.

The scripts are on GitHub: pueblokc/android-remote-adb-tailscale.

The idea in one paragraph

Android already ships a remote-control protocol: ADB, the Android Debug Bridge. With a cable, adb shell gets you a command line on the phone and adb install pushes apps. Android 11 and newer can also do it over Wi-Fi (“Wireless debugging”). Put the phone on Tailscale, a private mesh VPN, and “over Wi-Fi” becomes “from anywhere, and only for my own devices.” Then the AI on my PC runs adb connect <phone>:5555 and gets to work.

That’s the whole plan. Android had several objections.

Problem 1: the door keeps moving, and it locks behind you

Wireless debugging has two habits that make it useless for remote work:

1. It listens on a random port, a new one each time it turns on. You can’t adb connect to a port you don’t know.
2. It turns itself off at every reboot. A phone update, a crash, or a dead battery, and your remote access is gone until someone walks over and flips the switch.

The classic workaround is adb tcpip 5555. That tells the phone’s ADB daemon to listen on fixed port 5555 on every network interface, Tailscale included. It works right up until the next reboot, then it’s gone too.

So the job is really: at every boot, put all of this back without a human.

The fix: a three-part relay that runs every boot

No single app could do the whole job, so the work is split three ways:

Step 2 is the fun part. The phone runs its own ADB client inside Termux, uses it to talk to its own Wireless-debugging port, and uses that connection to open 5555. The boot script finds the random port through mDNS (adb mdns services). If that comes up empty, it falls back to an nmap scan of ports 30000–49999 on localhost. It retries for about seven minutes, then logs to /sdcard/Download/kc-adb-boot.log so you can see what happened.

Why Tasker and not just Termux?

This is the first trap we hit. Termux can be granted WRITE_SECURE_SETTINGS, and it still can’t flip the Wireless-debugging switch. settings put global adb_wifi_enabled 1 from Termux dies with “Failed transaction”. Tasker’s Custom Setting action does the same write and it works. So Tasker turns the switch on, and Termux does everything else. (The boot script still tries it; you’ll see that “Failed transaction” line in the log, and it’s harmless.)

Why a Tailscale keeper?

The second trap was on the TCL. Its vendor memory manager kills Tailscale in the background, and Android’s Always-on VPN doesn’t bring it back. kc-tailscale-keeper.sh pings Tailscale’s MagicDNS address (100.100.100.100) every 60 seconds. If there’s no answer, it sends Tailscale’s own CONNECT_VPN broadcast. That’s cheap, and it works.

The one thing we deliberately didn’t automate

Android runs none of this until the phone has been unlocked once after a reboot. Before that first unlock, app storage is still encrypted and Termux can’t even start. That’s Android’s security model doing its job, and I’m not going to fight it. After a reboot, someone unlocks the phone once. About a minute later, it’s back on the network.

Setting it up (the short version)

You need USB debugging on once, plus Tailscale, Termux and Termux:Boot (from the same source, F-Droid or GitHub, because they must share a signing key) and Tasker. The README has every command. The outline:

1. Grant permissions from the PC (reversible). Run host/01-grant-permissions.sh <serial>. It grants Termux and Tasker WRITE_SECURE_SETTINGS, whitelists Termux, Termux:Boot, Tailscale and Tasker from battery optimization, and turns off Android’s “phantom process” killer, which otherwise murders long-running Termux jobs.

2. Push the scripts and open port 5555. host/02-push-scripts.sh <serial>.

3. In Termux, run three scripts in order:

bash /sdcard/Download/kc-upg.sh            # full pkg upgrade, ends in UPGDONE
bash /sdcard/Download/kc-adb-setup.sh      # adb + nmap, installs boot script; tap "Always allow"
bash /sdcard/Download/kc-keeper-install.sh # starts the Tailscale keeper

Don’t skip kc-upg.sh. One phone had an older Termux with a half-upgraded package set, and adb refused to run with CANNOT LINK EXECUTABLE ... __hash_memory. A full pkg upgrade fixed it.

4. Build the Tasker profile: Profiles → + → Event → System → Device Boot. New task, add a Custom Setting action: Type Global, Name adb_wifi_enabled, Value 1. Press ▶ to test it, then ✓ to apply. Accepting Tasker’s terms is a human tap. The AI filled in everything else through the UI.

5. Prove it. host/03-reboot-test.sh <serial> <tailscale-ip> turns Wireless debugging off, reboots, and times how long until 5555 answers. On the family Pixel 6 it was back about 60 seconds after unlock, and mDNS found the port on the first try.

Teaching the AI to have gentle hands

Getting in was half the work. The other half was learning what not to do once we were in.

• Don’t use uiautomator dump to read the screen. It’s the standard way to get a phone’s UI as XML, and it quietly shuts down every accessibility service while it runs. My dictation app (Wispr Flow) lives on accessibility. After a few dumps in a row its bubble went invisible and untouchable until the app was force-stopped. That whole saga is here. We replaced it with a small helper that asks Android not to suppress accessibility services (FLAG_DONT_SUPPRESS_ACCESSIBILITY_SERVICES) and returns the same XML. It made zero disconnects in five-dump bursts. Plain ADB (shell, dumpsys, screencap, input) was never the problem.
• Don’t launch apps with monkey. It’s the lazy one-liner for “open this app,” and when it exits it turns auto-rotate back on. Use am start -n with the activity from cmd package resolve-activity instead.
• adb shell input text goes through the phone’s shell. A |, ; or > in the text runs on the phone instead of getting typed. Push a script file and type bash /sdcard/Download/x.sh instead.
• On Windows Git Bash, /sdcard/... gets rewritten to C:/Program Files/Git/sdcard/.... Set MSYS_NO_PATHCONV=1. This one cost us two wait loops that sat there until they timed out.
• The AI never types passwords, PINs or one-time codes. It fills in the username and hands me the phone. Terms-of-service checkboxes are a human tap too.
• If someone is using the phone, wait. Check what’s on screen (dumpsys window | grep mCurrentFocus) before taking over. That matters most on a phone that isn’t yours.

What it’s actually good for

This is where it pays off. Some things Claude has done on the phones since:

• Hunted down a “random” sound. A family phone kept playing a “You’ve got mail!” sound at odd times. The AI dumped every notification channel (dumpsys notification --noredact) and matched the custom sound file’s media ID. The culprit was one chat group’s channel, which is why it seemed random: it only played when that group got a message. It swapped the sound, then set nine mail channels and a few chatty apps to silent. It kept a before-and-after record so every change can be undone.
• Pushes app updates. When I build a new version of one of my own apps, the new build goes onto both phones over ADB in the same step, and it gets checked on both.
• Keeps my two phones identical. Any setting changed on one gets made on the other, then read back on both. Auto-rotate off, screen timeout, notification rules.
• Upgrades the plumbing. Termux package upgrades run through the same pushed-script trick, with logs I can read later.
• Sees what I see. adb exec-out screencap -p gives it a screenshot any time, and that’s always safe.

Security, because this is full control of a phone

ADB is root-adjacent power over the device, so:

• Never port-forward 5555 on your router. Tailscale is the only way in. The port is reachable only inside my private tailnet.
• Lock it down with Tailscale ACLs so only the admin PC can reach the phones on 5555.
• ADB still checks keys. Even on 5555, only computers whose ADB key the phone has approved can connect. Keep ~/.android/adbkey private.
• Keep secrets human. The AI can do anything I can on the phone, so the things that prove I’m me (passwords, PINs, 2FA codes) stay with me.

The takeaway

The hard part wasn’t “give the AI access.” It was making access boring: it survives reboots, it doesn’t break other apps, and it doesn’t need me to walk over and toggle a switch. Once it’s boring, the AI stops being a phone-support hotline that reads me instructions and starts closing tickets on its own.

Now when something on a phone annoys me, I describe it, and Claude fixes it.

Scripts and full setup: github.com/pueblokc/android-remote-adb-tailscale

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.

My life now consists of talking to Wispr on my phone and telling AI to do things.

A customer emails me because something isn’t working. I pull up ChatGPT, use Wispr to dictate what’s going on, and ask it to figure it out. With the connections we’ve set up, it can investigate and tell me what it finds. We work through the problem, draft a reply, and get back to the customer.

A surprising amount of the time, that takes care of it.

Then I sit there thinking: Did I actually just do my job? Because that barely felt like doing anything.

It’s really fucking weird. I love it.

Apparently, this counts as work.

For years, working in IT has involved a familiar collection of activities: opening interfaces, finding the right screen, checking settings, digging through logs, looking something up, trying a fix, and explaining the whole thing to someone who understandably just wants their stuff to work.

I know that routine. I run KC Computer Services in Pueblo. Networks, phones, cameras, and the other things businesses depend on are my world.

Now, more of that routine begins with me saying what I need into a phone.

There’s something ridiculous about spending years learning how to communicate with computers on their terms, then discovering that an increasingly useful approach is: “Here’s what the customer said. Go see what’s wrong.”

And it does enough useful work that I keep doing it.

Wispr is a bigger part of this than I would have expected.

Voice input removes a little barrier that turns out to matter a lot. I can explain the situation as it occurs to me. Include the background. Mention what we changed recently. Get the thought out without thumb-typing a technical explanation into a tiny rectangle.

Wispr gets my words into the conversation. AI helps turn the conversation into investigation and action.

That combination makes reaching for help feel almost automatic. An email arrives, I talk through it, and we’re working on it.

Our department has been reassigned.

I haven’t suddenly stopped knowing anything about IT. I still know the customer, their setup, and what a sensible answer should look like. I can recognize when an explanation doesn’t fit. I’m still responsible for what happens.

But a lot of the mechanical effort between noticing the problem and getting somewhere useful has shrunk.

Apparently, my brain has trouble accepting that.

There’s an old association between work and visible effort. If I spent an hour digging through something, I definitely worked. If I spoke into my phone and reviewed the result, some part of me thinks I’ve gotten away with something.

Meanwhile, the customer’s problem doesn’t care how much typing I did.

They wanted something working. We got it working. They needed an understandable response. We put one together.

The outcome is real, even when the process feels absurdly easy.

My brain would like a receipt for the struggle.

That doesn’t mean every issue is solved by a conversation. Sometimes the explanation is wrong. Sometimes access is missing. Sometimes you have to investigate further. And sometimes a cable needs a person standing there with a replacement cable. The phone has yet to grow arms.

The phone has yet to grow arms.

But enough of my everyday work now happens this way that it has changed my sense of what running a small IT business feels like.

I can bring experience and context to a problem, then get help with the searching, interpreting, and writing that used to consume so much attention. I spend less energy moving information between places and more energy deciding what matters.

That feels good. It also takes some getting used to.

I’ve loved technology for most of my life. I’m used to being excited about what computers might eventually let us do. Now I’m catching myself using something that would have sounded like science fiction to a younger version of me—and using it to answer a customer email.

That might be my favorite part.

The future turns up in the middle of an ordinary day. Something breaks. I talk to my phone. We figure it out. The day continues.

And I’m left holding this little rectangle, wondering how this became my life and what else I can build now that getting things done takes less out of me.

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.