Clair Flow is a hosted product, so trust has to be explicit. This page describes the current launch behavior of the product in plain language.
What Clair Flow stores today
- account data such as your email address
- browser sessions, device approvals, and device records
- hashed device API keys
- subscription and billing identifiers
- usage counters and dictation session metadata
- transcript text associated with completed dictation sessions
What stays local to the Mac app
- microphone capture
- hotkeys and shortcut preferences
- local permission state
- text insertion into the focused app
What the hosted service processes
During dictation, Clair Flow sends audio to the hosted service so it can:
- authenticate the connected device
- perform speech recognition
- clean and normalize the transcript
- apply glossary-aware terminology guidance
- record usage and account state
The current app database stores transcript text and session records. The current hosted service does not persist raw audio uploads in the application database as a first-class stored artifact.
Third-party services used at launch
- AssemblyAI for speech transcription
- Google Gemini for transcript cleanup and post-processing
- Stripe for subscriptions and billing
- Postmark for email delivery
What this means in practice
Clair Flow should be treated as a hosted productivity service, not as an offline dictation utility. If you need a no-cloud workflow, Clair Flow is not making that promise at launch.
Device security model
Clair Flow uses device-specific API keys for the native app:
- each connected device gets its own credential
- keys are shown once to the client and stored hashed on the server
- keys can be revoked from the account dashboard
Product trust posture
The product is designed around a clean boundary:
- local app for capture and insertion
- hosted service for processing, billing, and account state
That boundary is central to how Clair Flow works today.