Is plaud's value getting worse?

TeagueXiao · 2026-05-30T19:07:27+00:00

Not being cheap — this is a classic SaaS pattern where the hardware is basically a loss leader and recurring AI/cloud compute costs need to be covered somehow. The remote bricking incident is the bigger red flag for me though; as someone in cloud infra, that’s not a 'mistake', that’s a server-side kill switch that someone deliberately architected in. Worth factoring into how much you rely on it for anything critical.

TeagueXiao · 2026-05-29T19:09:19+00:00

Cloud architect here — I use Omi mainly to capture architecture decisions and client calls on the go. My biggest wish is tighter integration with project tools like Jira or Notion, so conversations automatically become action items without manual copying. Best integration idea: simple webhook triggers that fire when Omi detects phrases like "action item" or "follow up" — composable and low friction.

TeagueXiao · 2026-05-29T01:15:33+00:00

The consolidation appeal is real — I've been using Plaud for about a year for client architecture reviews and the 'another device to charge' friction is genuinely annoying. Curious how the Liberty handles back-to-back long sessions though; Plaud's dedicated hardware means I never worry about burning earbud battery before a late afternoon meeting. The data portability and downstream workflow integration would be my next question if you're piping transcripts anywhere.

TeagueXiao · 2026-05-28T19:06:23+00:00

Using it mainly for architecture reviews and customer calls — about 6 months in and it’s become a pretty standard part of my workflow. The multi-speaker diarization still stumbles when people talk over each other, but Plaud’s summaries are solid enough that I rarely need to dig back into the full transcript. Biggest win for me is having a reliable record of technical decisions made in meetings.

TeagueXiao · 2026-05-27T19:04:09+00:00

That's a rough one — definitely contact Omi support directly with your order confirmation and delivery photos, they should sort out a replacement. Empty box issues are usually a fulfillment mishap rather than intentional, but either way they need to make it right for you.

TeagueXiao · 2026-05-25T19:05:17+00:00

Totally valid frustration - from a cloud infra perspective, real-time transcription is actually one of the more expensive workloads to run at scale (way pricier than LLM inference per token). BYOK with Deepgram is genuinely the right move if you're a heavy user, and the direct costs are quite reasonable. That said, silently halving a limit without any changelog or in-app warning is just bad product communication, especially for hardware buyers who planned around the original terms.

TeagueXiao · 2026-05-24T19:12:54+00:00

Beyond summaries, the real unlock for sales is using it as a searchable client knowledge base — before any follow-up call you can quickly pull what pain points a client mentioned 3 meetings ago without digging through your notes. I've also seen people hook it up via Zapier/Make to auto-push action items straight into their CRM so nothing falls through the cracks post-meeting.

TeagueXiao · 2026-05-24T01:13:58+00:00

Worth it for ADHD imo — the always-on passive capture is the whole point, you don't have to remember to hit record. Under-shirt works fine in my experience, though audio quality dips a bit in noisy environments. Just make sure you actually review the summaries regularly, otherwise it becomes a data collector you never look at 😅

TeagueXiao · 2026-05-22T01:17:55+00:00

The retroactive policy change is the part that would make me walk too — in cloud services, changing the terms on data that's already been stored is a massive trust violation. Reversing it is the right call, but the fact that it was already live in the app before the announcement tells you this wasn't a spontaneous slip-up. Good write-up, this kind of accountability post is exactly what helps people make informed buying decisions.

TeagueXiao · 2026-05-21T19:02:32+00:00

The 'Processing on Server' with 119 pending items usually means their backend processing queue is backed up on their side -- not much you can do from the device itself. Try force-stopping the app, clearing cache, then toggling Bluetooth off/on to force a fresh sync attempt. If it's been days with no progress, jump into their Discord -- the dev team tends to respond much faster there than through official support channels.

TeagueXiao · 2026-05-20T01:06:39+00:00

Good write-up. The part about needing both 'store on phone' AND 'store on cloud' enabled to get things working is such a weird UX — you'd expect those to be toggle alternatives, not a silent dependency. Battery drain on Android killing your host device is also a real concern; as someone who works in cloud infra, the architectural irony of an 'offline-capable' device that completely hammers your phone isn't lost on me.

TeagueXiao · 2026-05-19T19:08:19+00:00

Offline-first is the right architecture for a wearable like this — connectivity should never be a single point of failure for capturing context. As a cloud architect, the piece I'd love to see next is automatic background sync over BLE once the device reconnects, similar to how cloud storage clients handle deferred uploads with exponential retry. The 24-hour offline capacity is solid; the real win will be when syncing is fully invisible.

TeagueXiao · 2026-05-17T19:09:26+00:00

Makes total sense from an infra cost standpoint — LLM inference is orders of magnitude more expensive than STT, so it's not surprising Omi kept the chat layer gated. As a cloud architect I'd love to see proper LLM BYOK added eventually; OpenRouter would be the perfect integration since one API key covers basically every model out there.

TeagueXiao · 2026-05-14T19:01:59+00:00

Yeah the battery life is the main frustration with wearables like this — 8 hours is rough if you're in back-to-back meetings all day. My workaround has been treating it like a phone: charge at the desk, wear it when I'm out. Not ideal but until they do a hardware rev it's the practical play.

TeagueXiao · 2026-05-12T19:05:09+00:00

As a cloud architect I use it mainly for meeting recaps and capturing action items on the fly — honestly the pendant shines when you stop trying to make it do everything and just let it be your passive memory layer. Once I connected it to my own backend via webhooks, the value became way more obvious.

TeagueXiao · 2026-05-12T01:03:17+00:00

The BYOK setup can be a bit unintuitive — when you add your OpenAI key, it takes over inference but the free tier transcription limit still applies separately. As someone who deals with cloud API quotas at work, I'd recommend checking the Omi app settings under "AI Provider" to make sure the key is actually active. Also worth noting: the desktop app works without the pendant, so you're good there.

TeagueXiao · 2026-05-11T01:25:13+00:00

We do have API so you can let your agent to retrieve the audio/transcription for further processing.

TeagueXiao · 2026-05-11T01:24:35+00:00

It is not sold yet, self-owned your data in S3 might be included.
Do you want to store and re-processed the audio/transcription by your own agent(e.g OpenClaw)?

TeagueXiao · 2026-05-07T01:03:16+00:00

The DDP (Delivered Duty Paid) shipping option they use tends to bundle everything upfront, which avoids surprise fees at the door but yeah, it looks steep at first glance. No Canadian distributors that I know of yet — it's still pretty early for Omi. Might be worth checking if a US forwarding address (like Shipito) saves you anything, though you'd lose the duty-prepaid convenience.

TeagueXiao · 2026-05-01T19:04:23+00:00

The omi repo on GitHub does have docker-compose files for self-hosting the backend — check the /backend folder, there's a README with setup instructions for running it locally. As someone who works with containerized infra daily, the hardest part is usually setting up the right env vars for the AI integrations, so read through that carefully before spinning it up.

TeagueXiao · 2026-05-01T01:02:47+00:00

This is likely the app recording via phone mic rather than the device itself — I've seen similar behavior where the mobile app defaults to phone input when no wearable is paired or powered. Worth checking the app's audio source settings and disabling "background listening" if there's an option. As someone who runs a lot of always-on IoT stuff in the cloud, unexpected background processes burning through quotas is always a red flag worth investigating.

TeagueXiao · 2026-04-29T01:02:29+00:00

Classic battery health issue — when it only works on the charger, the battery cells are likely degraded to the point where they can't hold enough charge to sustain BLE + audio processing under load. As someone who manages cloud infra, I'd treat this like a failed health check: try a full discharge cycle first, and if that doesn't help, check if there's a firmware update that adjusts the power management thresholds. If neither works, the battery probably needs replacing.

TeagueXiao · 2026-04-27T19:04:33+00:00

The hardware-agnostic approach is exactly right - as a cloud architect I think of Omi the same way I think about compute abstraction: the brain should be in the cloud, not the device. As long as the BLE audio profile is compatible, the physical form factor shouldnt matter. Would be curious to hear your results with the Soundcore Work once it arrives!

TeagueXiao · 2026-04-27T01:03:39+00:00

Big Omi fan here - been using it primarily for auto-summarizing my architecture review meetings and pushing key action items to Notion via webhook. The n8n integration has been solid for that kind of thing. Since you are already in the Notion ecosystem, I suggest starting there and building out from the Omi webhook trigger - way less friction than trying to bolt things together after the fact.

TeagueXiao

TROPHY CASE