Use

Mobile apps

Omnesis has native iOS and Android apps. Each is two things at once: a full client for your gateway — chat, search, tasks, people, devices — and the runtime for sources whose data only exists on the phone. This page covers getting an app onto your phone, pairing it, Tasks, the phone-only sources, voice and quick capture, and what to do when phone data does not arrive. It assumes a running gateway (see Install).

Getting the apps

An official build is signed by the Omnesis maintainer under the published app identities; its notifications work without any setup on your gateway. A self-built app is one you build from the source repository and sign yourself; it needs your own push credentials for background notifications.

The official iOS app is distributed through one external TestFlight group, which Apple limits to 10,000 testers. The official Android app is in closed testing on Google Play: join the tester group, then opt in with the same Google account and install the app from the Play listing that page links to.

How each build receives notifications is covered in Notifications → Choose a transport.

Build and install iOS

You need a Mac with Xcode, XcodeGen, and an Apple development team. Copy ios/Local.xcconfig.example to ios/Local.xcconfig and set DEVELOPMENT_TEAM. Unless your team is authorized for the official App ID, also set OMNESIS_BUNDLE_ID to a base identifier registered under your team (for example com.example.myomnesis); the extension and Watch targets derive their identifiers from it. Then generate the project:

In Xcode, select your physical iPhone as the destination and run the app. The simulator works for basic UI testing, but it does not provide your phone's HealthKit data. The App IDs and capabilities each target needs are listed in the iOS contributor guide.

Build and install Android

You need JDK 17, the Android SDK, and adb. The full edition you build includes the Call Log source, which the Google Play app does not include. Build with the committed Gradle wrapper, connect a phone with USB debugging enabled, and install the APK:

Choose your own package id, so your build never collides with the Google Play app. Run omnesis push setup before building if you want background notifications; it writes the package id and Firebase client values to the ignored android/local.push.properties. Without push, you can put only OMNESIS_ANDROID_APPLICATION_ID=dev.example.omnesis in that file. Keep the same id for later updates to your build. See the Android contributor guide for the full process.

Pairing

On the gateway host, mint a pairing QR with the CLI:

Expires in 599s. Scopes: admin, read, push:claim, write:apple-health, write:activity-segments, write:photos, write:core-location-visits

Use --kind android for the Android app. The portal's Devices page and both apps mint the same code with a kind picker. The QR carries the gateway URL, a pairing code that expires after ten minutes, and how the phone should trust the gateway's certificate. If the camera is unavailable, both apps accept the same payload through Paste JSON. Manual entry, which takes the gateway URL and pairing code typed by hand, carries no fingerprint, so it works only with a certificate the phone trusts; the portal and the CLI print the code for it in that case. The phone names its own device entry, which you can rename later with omnesis devices rename.

For a gateway on a public HTTPS address, the phone checks the certificate the normal way, so a routine certificate renewal does not require pairing again. For a private or self-signed address, the QR instead carries the certificate's SHA-256 fingerprint, and the app pins that gateway. If the public address differs from gateway.publicBaseUrl — including a different port — add its exact origin to gateway.pairingSystemTrustOrigins. The address you pair with also decides where the phone works: a LAN or .local address only works at home. To use the phone away from home, follow Setup → Remote access before pairing.

The gateway chooses the address to put in the QR code, and the portal and the CLI show its choice. It offers only addresses the phone being paired can use, puts the one that reaches furthest first, and says where each works. Under the QR code, the portal lists the other usable addresses under Use a different address, and the CLI prints each with the --gateway-url that selects it. An address the phone would refuse is named with the reason instead of being offered. An iPhone accepts the gateway's own self-signed certificate only on the local network, at a private LAN address or a .local name. Anywhere else, including at a Tailscale IP, iOS requires a certificate it trusts, such as a Tailscale certificate for the gateway's Tailscale name. An Android phone accepts the pinned certificate at any address it can reach.

The .local name offered is the one the gateway advertises itself (omnesis.local unless gateway.mdns.hostname sets another), which it announces with the machine's LAN addresses only. Give each gateway on one network its own name with gateway.mdns.hostname; two that announce the same name answer for each other. The machine's own .local name is not offered: on a host running Docker or virtual machines its announcements can include addresses a phone cannot reach.

A gateway in Docker's default bridge network sees only the container's own address and the .local name it announces on Docker's network, and a phone reaches neither, so the pairing screen lists them as not offered. It offers the host's addresses instead, at the port Docker publishes: its LAN addresses, its Tailscale address, and its .local name when the host answers mDNS (macOS does; Linux does with avahi-daemon running). The omnesis command on the host records them every time it runs, so after the router gives the host a new address, any omnesis command updates what the next pairing offers. The phone verifies the gateway by its pinned fingerprint at these addresses, whichever names the certificate covers; with a Tailscale certificate, the Tailscale name is offered first and verified by platform trust. A phone paired by fingerprint on a gateway whose certificate renews, such as a Tailscale certificate, stops connecting at the next renewal; the pairing screen gives the date, and the Tailscale name avoids it.

--gateway-url states the address instead, and the CLI refuses one the phone cannot use, with the reason and the alternatives. On a host with several network interfaces, set OMNESIS_IOS_GATEWAY_URL in the CLI's environment to use one address for every phone QR code, iOS and Android alike, from omnesis devices pair and omnesis devices repair; a --gateway-url flag still takes precedence.

On scan, the app exchanges the code for its own device token. The default grant is a full-client token: admin (the app manages sources, devices, and models), read (search and the agent), push:claim (fetching its notification text), and write access for its on-device sources. To withhold management, mint the code from the CLI with an explicit list: omnesis devices pair --kind ios --scopes read,push:claim. The gateway always restores write access for the phone's own on-device sources when it connects. The full scope list is in Devices and connections.

iOS stores the credentials in the device-only Keychain; Android in encrypted preferences. Re-pairing and unpairing live in the app's Settings. Pair every iPhone or iPad separately: each receives its own gateway identity and token, and iOS pairing credentials do not sync through iCloud Keychain or a device restore. If iOS says Pair this device again, the app found a pairing credential that had reached it through iCloud rather than being issued to this device, and removed it. Your gateway data is untouched; mint a fresh code and pair it.

A paired phone reports its app version to the gateway, and omnesis devices list and the portal's Devices page show it beside a reading: current, behind or unsupported. Behind is ordinary rather than a fault; the gateway keeps serving the app. Only unsupported asks you to update the app, which you do on the phone: a fleet update never updates phone apps. Version compatibility explains each reading. Settings → About on the phone shows the version, build and protocol number to quote when asking for help.

Finding your way around

Search results can show other documents with matching text, storage locations and connections to related documents. Tap a linked title to open that document. These facts are available when the gateway supports graph context and has it enabled; search still works with older gateways or when graph context is disabled. Matching text does not establish that files have identical bytes, and a bounded trail can be incomplete.

Both apps open on the agent chat. The menu reaches Search, Tasks, Sources, People, Tell Omnesis and Audit, lists recent conversations, and carries Settings and a new conversation at its foot. Swipe right (on the iPhone Tasks screen, from the left edge), or use the menu button, and the screen you are on slides aside to uncover it; tap the strip still showing to come back. There is no tab bar.

In a completed agent answer, tap the copy icon beside a value or after the last line of a plain multiline value to copy its contents. The button copies only that value, without its label or Markdown formatting, and remains available in saved conversations. See The agent.

Settings → Gateway holds Configure Models, Configure Devices, Policies, and Authorize an MCP connection. The first three open as child pages; Authorize opens the code-gated access flow (a sheet on iPhone) described under Privacy controls.

If you return within an hour, the app reopens the conversation you were using. After an hour away, it opens the agent on a fresh empty conversation with the composer ready; the earlier conversation remains available from the menu.

The apps reach your data only through your gateway, and contain no telemetry or third-party analytics SDK. The phone is one more paired device, so when the gateway is unreachable the app is offline. Notification text also stays on the gateway: Apple's and Google's push services carry a fixed, content-free wake, and the app fetches the text over its paired connection. See Notifications.

Tasks

Tasks is a list of things you mean to do, kept the way a bullet journal keeps them. It is in the apps' menu and at /portal/tasks in the portal, and works on every gateway with no model assigned. Each task has a planned time, separate from any real deadline: a day, a month, or someday for no particular time. Planning a task for Friday does not make Friday its due date.

Each view's tab shows how many open tasks it holds, and the menu's Tasks entry shows today's. On iPhone, swipe left or right across the list to move to the next or previous view; a swipe that starts at the left edge of the screen opens the menu instead. To add a task, tell Omnesis: the microphone button at the top right of Tasks opens a Tell Omnesis note. A note such as "call the garage on Friday" adds a task, and "I won't repaint the fence after all" strikes it. A task that came from your documents lists them under its title, each with its source's icon; tap one to open the document. A task planned for an earlier day stays on Today until you complete, move or strike it; nothing drops off on its own.

Tap a task's circle to complete it. In the apps, touch and hold anywhere on the task for its other actions, which fan out above and to the left of your finger. Keep holding, slide onto one and let go; letting go anywhere else changes nothing. Rest on Other month to see the months. With VoiceOver or TalkBack, the same actions are in the task's accessibility actions.

• Done, or Done + note to say how it ended, by voice or typing as with a Tell Omnesis note;
• Tomorrow, Next month, or Other month for any later month, to move it;
• Cancel task, for a task you no longer intend to do;
• Tell Omnesis, to capture a note about this task. Its title is shown as fixed context. On iPhone, it starts listening immediately; say what you want to change, or stop the microphone to type instead. Saving the note does not itself reopen a completed task. This action requires matching app and gateway support; older gateways do not offer it.
• Chat about this, to start a conversation with the agent about the task, which needs an agent model assigned.

Tap the task itself for its details: edit its title, description, planned time and deadline, and see its history, every change and where it was made. In the portal, clicking the task opens these actions beneath it instead, with Next week (the coming Monday) as a further move, and Chat about this to the right of History.

Every change shows a one-line receipt with Undo. Undo reverses the latest change to that task; an earlier change cannot be undone once the task has changed again. A task can also change from a conversation with the agent or from a Tell Omnesis note; its history records which.

iOS task widgets

Add Omnesis → Tasks from the Home Screen widget gallery. Choose small, medium, large, or the extra-large iPad layout. Lock Screen widgets are available in inline, circular and rectangular sizes. Open the paired app once after installing to make its tasks available to the widgets.

In Edit Widget, choose a day, week or month. A start offset of 1 starts tomorrow, next week or next month respectively. Use the arrows on a Home Screen widget to browse earlier or later periods, tap the date between them to return to the current period, and use the page counter to see more tasks. If two widgets have the same date settings, give them different Panel values to browse them independently.

Tap a task's circle to complete it from a Home Screen or rectangular Lock Screen widget; the device may ask you to unlock first. Tap its title to open the task in Omnesis. Future periods show their planned tasks and deadlines; today's outstanding tasks are carried into the current period. The Today view shows tasks newest first. Unscheduled tasks without a deadline stay in the app's Anytime view. Widgets refresh when iOS allows and after task actions; if the gateway is unreachable, a Home Screen widget labels its saved list as offline. Completion requires a connection and a failed action leaves the task open.

Android task widgets

Add Omnesis → Tasks from your launcher's Home Screen widget picker. Resize it horizontally and vertically for a compact list, a larger task list, or a wide tablet layout. Each widget keeps its own date range and page.

Use Day, Week and Month to choose the date range, the arrows to browse earlier or later periods, and the date to return to the current period. The page control shows more tasks. Tap a circle to complete a task, or its title to open it in the app. Future periods show their plans and deadlines; only the current period includes today's outstanding tasks. The Today view shows tasks newest first. Month-only plans appear in the month view. Tasks without a plan or deadline stay in Anytime in the app.

Widgets follow the device's light or dark theme. A saved list remains available while the gateway is unreachable, labelled offline; completing a task requires a connection. Android schedules background refreshes, and opening the app or changing a task requests a refresh. Removing or changing the pairing clears the widget's saved list.

Phone-only sources

Some data never leaves the phone by any other route — there is no server to sync from. For these, the app reads the data on-device and pushes extracted text and typed rows to the gateway. For photos, that means OCR text and labels computed on the phone, plus captions on supported iPhones — never the image itself.

Every source is off until you turn it on. After the first pairing, the app opens a short setup flow: you choose which of this phone's sources to add, and each chosen source gets a page that lists what is sent to your gateway and what stays on the phone before the platform's own permission prompt appears.

Nothing is preselected, and you can skip it: Settings → Set up this iPhone (or Set up this phone) reopens the same flow, and each source's card in Settings keeps its own toggle and a summary of what it sends. The app asks for notification permission only from the setup flow or from the Turn on notifications action in Settings; it does not prompt on its own. On Android it offers to exempt Omnesis from the system's pause for unused apps, so sources keep syncing on a phone you rarely open.

Each enabled source shows this phone's sync state, last successful update, errors, and a Sync now action. Once synced, the data is searchable like everything else and the structured rows are queryable with SQL — see Search, and the full catalogue in Available sources.

On iOS:

On iOS, Limited Photos access indexes only the items selected in the system picker. A Limited or Denied library view is never treated as proof that previously indexed photos were deleted. After Full access returns, Omnesis performs a complete library pass and republishes newly visible items without reducing the analysis already stored for them. Each sync also scans one small page of the accessible library, which eventually finds older imports and items newly exposed through Limited access.

HealthKit does not reveal after the prompt which data types you allowed, so Omnesis reports that consent as unknown rather than treating an empty result as proof that access is healthy. Background App Refresh is reported separately for every iOS source that depends on it.

On Android:

On Android 14 and later, selected-photo access is usable but incomplete: Omnesis indexes the selected items, labels the source as limited, and never treats hidden items as deletions. Granting full access starts a complete library pass so older newly visible photos are included. Access to embedded photo locations is a separate, optional permission: denying it keeps photo text and labels syncing but omits place names.

Health Connect reports record-type consent separately from background-read and history access, so the app can say exactly which part is reduced. If Health Connect fails to read an enabled record type, the sync reports an incomplete result and names the affected types; data already uploaded is kept, and a later sync retries the failed reads. The permissions action opens general Health Connect settings when Android does not allow a direct link to the app's permissions. Re-enabling Activity Segments restores the activity history the phone still holds, both day summaries and analytics rows.

Permission health

Each enabled phone-only source regularly reports its permission state to the gateway. When access is reduced, the app shows the affected capability, its impact and the platform's repair action, and your phones receive a reminder. If a phone stops reporting, Omnesis says the source check is overdue; it never concludes that a permission was revoked from an empty sync or a quiet period.

A source can also show permission-degraded, background-access-missing, or unavailable: the last sync finished, but the phone reported that some collection is incomplete. Repair the source in the app. omnesis sources sync --wait treats these states as completed but unsuccessful, so automation receives a non-zero exit instead of waiting until timeout.

On several phones

Apple Health is shared across your Apple devices: they all read the same HealthKit library and Omnesis keeps one copy. If another iPhone already hosts it, setup offers three choices: leave it there, use both iPhones, or move it to this iPhone. Activity Segments, Location Visits, Health Connect, Call Log, App Usage and Photos are per device: turning one on for a second phone adds that phone's data alongside the first and keeps the first phone's history. These choices happen in the app before any system permission prompt; phone-only sources cannot be added from the portal or the CLI.

Photos from each phone are indexed separately, so an image that several devices can see through iCloud or another cloud service can appear several times, with different extracted text. Only text and metadata are uploaded, never the image bytes.

Turning a source off in the app stops this phone's uploads and detaches the phone from the source; the confirmation says what happens to the data, which depends on the source's mode and whether other devices still host it. Pause on source details keeps the source and its data. What detach, pause and remove do in each mode is described in Sources on several devices and Managing sources.

Voice and quick capture

Both apps can ask the agent or capture a note without navigating through the app. Asking requires an agent model assigned on the paired gateway. Capturing does not: notes go straight into the built-in Omnesis Notes source, where they join the searchable index. A capture made while the gateway is unreachable stays in the app's private on-device queue and syncs later. The portal offers the same typed capture on its Tell Omnesis page, which also lists every captured note newest-first so individual notes can be amended or deleted; see Sources.

In both mobile apps, open Notes from the menu to browse saved notes without starting the microphone. The microphone button on the right of that menu row opens Tell Omnesis and starts listening immediately. You can also open Notes from the capture screen. Opening history stops listening and keeps your draft. Notes are listed newest-first; open one to read its full text, capture details and Omnesis's reply, edit the text, or delete it after confirmation. Refresh the list to see notes saved on another device. Notes still waiting in this phone's offline queue appear in history after they sync. Editing your captured note asks Agent to process the correction, as described below. Deleting a note removes its saved text and reply; task changes the agent already made remain until you undo them.

With a model assigned to Agent (under Settings → Models), Omnesis also reads each note you capture from your own clients: the portal, the apps and the CLI. Notes that external agents add through MCP, OpenClaw or Hermes are saved and searchable but never acted on. A few seconds after a note stops changing, one bounded agent turn acts on it: it adds the tasks the note asks for (“remind me to renew the passport next month”), completes, moves, strikes or edits the task a note reports progress on (“paid the plumber”), remembers facts you state about yourself or people you know, and answers a question the note asks. A request that needs watching over time, such as “tell me when the parcel ships”, is beyond one note; the reply says so plainly. A voice note waits for the gateway's transcript, for up to 30 minutes, before it is read.

What the turn did appears under the note on the Tell Omnesis page as a short receipt, with Undo beside undoable task changes. Reading a note normally sends no notification. If a clear request needs clarification, Omnesis keeps the note, opens a conversation containing your request and its question, and notifies you. Choose Continue in chat in the receipt to answer with the context kept. Chat and notes use the same Agent model; no open chat is needed for direct actions. Reading starts the first time an Agent model is assigned; notes captured before then are never read. If the model is later unassigned, notes captured in the meantime are read once a model is assigned again.

Act on Tell Omnesis notes, in the Agent details under Settings → Models, switches the note agent on or off (the agent.noteAgent setting). While it is off, notes are only saved, and notes captured in that time are never read, even after it is switched back on. It is on by default. GET /status reports whether notes are read as tasks.noteAgent, and the setting as noteAgent. If processing is unavailable, the capture screen explains that the note is saved without being acted on. Choose an available Agent model in Settings → Models to enable processing. Select Agent explicitly; other role assignments are not used as a fallback.

Editing your captured note also asks Agent to act on the correction. It compares the previous and current text with its prior result, so unchanged instructions are not a fresh request. Relative dates in a correction use the day you edit the note, in its capture time zone. Quick successive edits settle together; the edited note shows pending processing until its new receipt is ready. If an earlier action has an uncertain result, Agent can read back the state but asks you to review it before making a fresh, separate request. Edits made while note processing is switched off are only saved.

On the portal, notes are grouped by capture day, with a View combined note link to the day's searchable document. Expand Related to this day below the notes to see the dates they mention, each labelled Date mention with its kind, such as Event or Deadline, as on the portal's Calendar. Selecting a date opens its entry in the portal's time index. These links do not require the Brain and apply to the whole day's notes.

On iPhone, say “Hey Siri, Ask Omnesis”; Siri then asks what you want to know. Say “Hey Siri, Omnesis note” or “Hey Siri, Omnesis capture” and Siri asks what to remember. Siri requires that follow-up because App Shortcut phrases cannot insert unrestricted dictated text into the opening phrase.

On iOS 18 or later, add the Omnesis logo control from the Control Center controls gallery or the Lock Screen controls picker. Tapping it opens voice capture and starts listening immediately, with the same microphone animation as Tell Omnesis. With a decision model available, tap Send and the gateway chooses whether to open an agent conversation or save a note. Without an available decision model, or with inference.dictation.useDecisionGateForWatch set to false, choose Ask or Tell yourself. This applies only to the control and voice shortcut; the app's chat and Tell Omnesis screens keep their separate flows. Phone controls and the Watch complication use the same gateway routing capability and setting, including gateways that already support Watch capture.

For the iPhone Action button, choose Settings → Action Button → Controls and select Omnesis. Alternatively, choose Shortcut and select Speak to Omnesis. The action opens listening directly, without a Siri question first. The system may require you to unlock before opening the app.

The same Ask Omnesis and Omnesis note Siri shortcuts are available on the Apple Watch and relay through its paired iPhone. The single Omnesis logo complication starts recording immediately, without showing a transcript. Tap Ask to stop recording and open a conversation, or Tell to save a note. “Got it. I'll deal with it.” confirms that the Watch has stored the recording; it does not wait for the phone or gateway. Recordings are kept on the Watch and retried for up to a week, then retained by the phone until processed. The phone retries unfinished captures when opened; delivery or transcription failures produce a notification. Interrupting or reaching the recording limit leaves the capture ready for an explicit Ask or Tell; it does not send an undecided recording.

Opening the Watch app normally shows Tap to speak; the complication starts recording immediately. Both enter the same capture screen. Notes return to the watch face after confirmation once their transfer is safely underway. Questions keep the Watch open for the answer. Playback starts only when you tap the speaker. The microphone records an audio-only Ask follow-up in the same conversation. Cancel returns to the answer during a follow-up, or to the watch face when capture was opened from the complication. If the Watch cannot display the answer, a notification brings you back to it. A confirmed displayed answer suppresses that fallback notification.

With a decision model available, the complication shows one Send button. The gateway decides whether the words need an answer or should become a note. Disable Use decision gate for Apple Watch complication in iPhone Settings to restore Ask and Tell. The corresponding gateway setting is inference.dictation.useDecisionGateForWatch; it defaults on when a decision model is available. Older gateways and disabled or unavailable decision models show Ask and Tell. If routing fails after Send, the recording is treated as Ask. Existing Ask and note Siri shortcuts keep their separate flows.

On watchOS 26 or later, add the Omnesis logo control to the watch's Control Center or Smart Stack. On Apple Watch Ultra, choose Settings → Action Button → Control and select Omnesis. This control runs on the watch and opens the same recorder as the complication; it does not open the iPhone app. Recording starts immediately, with Send or Ask and Tell following the same decision setting as the complication.

The Speak to Omnesis shortcut also opens that recorder, including on older watchOS versions. In Shortcuts on iPhone, create a shortcut containing that action and enable Show on Apple Watch in its details. On Apple Watch Ultra, choose Settings → Action Button → Shortcut and select it.

Gateway transcription applies to both Ask and Tell from the complication. When it is disabled, audio travels to the iPhone for strictly on-device transcription, including enabled personal vocabulary hints. Enable Speech Recognition from the Apple Watch section in iPhone Settings first. A supported on-device language is required; audio is never sent to Apple's speech service by this flow. A suspended phone or unavailable recognizer can delay processing. Pending recordings expire after a week, with a notification. Update the paired phone app before using the unified complication. Replace an installed Omnesis note complication with the Omnesis logo complication.

On Android, Gemini or Google Assistant can invoke the installed App Actions for Ask Omnesis and Tell Omnesis. The custom one-utterance phrases are English (United States) only. Long-press the Omnesis launcher icon for matching Ask Omnesis and Tell Omnesis shortcuts, or choose Omnesis for unified voice capture. Drag that shortcut to the home screen for one-tap access. In the expanded Quick Settings shade, choose Edit and add the Omnesis tile for the same flow. Both start listening immediately and use Send with a decision model, or Ask and Tell when routing is disabled or unavailable. They share inference.dictation.useDecisionGateForWatch with the iPhone control. A phone's configurable hardware button or gesture can use the shortcut if its manufacturer supports app shortcuts; the available buttons and setup vary by device.

Voice questions wait a bounded time in the foreground. If the answer takes longer, the assistant tells you it is still working; once the answer is ready, your phone gets an Answer ready notification and fetches the answer directly from your gateway. Notification services never receive the question or answer text.

Gateway dictation

The iOS and Android apps turn what you say to Tell Omnesis into text with the phone's own recognizer. With gateway dictation on, they also send the recording with the note, and your gateway's Transcriber — the same model that transcribes voice notes from your sources — transcribes it again and replaces the phone's text with its own. This applies to:

• Tell Omnesis in the app and the explicit Tell app shortcut;
• a Tell Omnesis request from Google Assistant that opens the app to listen;
• legacy Watch note capture. The unified Omnesis complication uses gateway transcription for both Ask and Tell, as described above.

The unified phone control and voice shortcut use gateway transcription before routing or opening chat when gateway dictation is active. Choosing Tell saves a voice note immediately, including to the offline queue, as Tell Omnesis does in the app. With gateway dictation off, these entry points use the phone's recognition. Existing agent conversations, explicit Ask Omnesis, Siri and assistant requests that already carry their words keep the phone's or the system's recognition.

Turning it on and off

It is enabled by default and transcribes when a Transcriber model is assigned under Settings → Models → Transcriber. The Transcribe voice notes in the Gateway switch on that same page turns it off, and the apps show the same switch under Settings → Voice. It is a gateway setting, so it applies to every phone paired with the gateway. In omnesis.json, switching it off is:

"inference": {
  "dictation": { "transcribeOnGateway": false }
}

GET /status reports the combined verdict as dictation, and the apps send recordings only while its active field is true. Without a runnable transcriber, the setting says what is missing, and notes keep the phone's own text.

Personal vocabulary hints can improve both the gateway's transcriber and the apps' on-device recognition, including voice questions to the agent and notes captured with gateway dictation off. They are on by default; setting inference.transcriptionVocabulary.enabled to false turns them off for the gateway and every paired app. The apps fetch hints in the background, keep them in memory for offline use for up to 24 hours, and refresh them opportunistically after 30 minutes when returning to the foreground or refreshing gateway status. Starting a recording never waits for hints. See Operating Omnesis for vocabulary behavior.

iOS supplies hints only to on-device recognition. Android requires Android 13 or later and a compatible on-device recognizer; the recognition service may ignore hints. Recognition that uses an operating-system cloud service receives no personal dictionary. Apple Watch recordings transcribed on the paired iPhone can use hints. Watch system dictation, keyboard dictation, and voice-assistant input do not expose vocabulary hints to the app. Android hints apply to the app's Ask/Tell voice capture and voice follow-ups; typing or using the keyboard microphone in the agent composer does not use this dictionary.

What happens to a voice note

While you dictate, Tell Omnesis shows that it is recording rather than what the phone heard: the gateway's transcript is the one that counts. The phone still transcribes in the background, and that text is saved with the note at once so it is never empty. The gateway then works on the recording and replaces the text when its transcriber finishes. How long that takes depends on the gateway's hardware and on the voice notes it is already transcribing for your sources; nothing waits on it. The portal's Tell Omnesis page marks such a note as transcribing until the gateway's text arrives. If you edit the note first, your edit stays. Date extraction waits for the gateway's text too, for up to an hour (enrichment.dates.pendingContentWaitMs), so the dates the note mentions are read from its final words.

A Tell recording from the Apple Watch complication travels through your iPhone directly into the gateway's voice-note queue when gateway transcription is enabled. Other in-app Watch voice notes also carry the phone's fallback transcript when available. The watch keeps each note, recorded or dictated, until the iPhone confirms it has it, retrying for up to a week when the phone is out of reach. When the phone has no transcript to offer, the note reads "Voice note — transcribing…" until the gateway's arrives.

The gateway keeps the recording in its database, alongside the rest of your data and under the same encryption at rest, only until it has transcribed it, and retries a failed transcription for up to a week. A note it cannot transcribe keeps the phone's text. Deleting the note deletes its recording.

To stop, switch the setting off. The apps return to saving the phone's text once they next read the gateway's status, which they do at the latest when they come back to the foreground. Recordings already sent are still transcribed.

Privacy controls

The Audit screen lists what external agents asked and what left the gateway, and lets the phone approve or deny each pending answer. While a decision is waiting, the Audit entry in the menu carries a count, and opening the app presents the pending answer without waiting for a notification tap — once per app session, and again on the next launch if it is still waiting.

When an AI agent asks to connect, the phone gets a notification with no details in it. Tap it, or scan the QR code on the agent's approval page with the phone's camera, to open the request in the app, choose its access level, and approve or deny it; the same screen is under Settings → Gateway → Authorize an MCP connection. Access levels and the approval flow are described in Bring your own agent.

Privacy policies are read-only on the phone: Settings → Policies lists every policy, marks the default, and opens each one's text, and an exchange reviewed under a named policy says so on its detail screen. Edit policies in the portal under Settings → Policies.

A document can be deleted from its page or from a source's recent list, and the prompt offers both forms, Delete for good and Delete this copy; see Search → Beyond search for the difference. A day's quick-capture document cannot be deleted directly: its Manage notes action opens the portal's Tell Omnesis page at that day, where the original notes can be amended or deleted.

When data doesn't arrive

A phone sync is two steps: reading from the operating system, and uploading what it read. They fail independently, so a source can report a completed sync while its data sits on the phone. The app watches the upload step separately and warns about it above the source list and in Settings — the only place that state is visible, since every other indicator reads healthy. It warns about three problems:

• Refusing a source. This phone's token lacks the source's write scope. Grant it on the gateway and the held data is retried.
• Backlog aging. The gateway is unreachable or uploads are failing. Retry drains the backlog now and reports what happened; on iPhone that includes batches that belong to a paused source, which wait until the source is resumed.
• Could not be delivered. Some batches failed repeatedly and were set aside, out of the queue, so they stop counting as pending.

Activity still in progress is not an upload backlog. Android Activity Segments counts completed intervals ready for its next sync, not the raw transitions it keeps while waiting for an activity to end. An interval becomes ready when it ends or reaches the source's safety cutoff, and backlog age starts at that point.

Set-aside batches stay on the phone, but only the most recent are kept, and discarding them is final. Whether the data comes back on a re-sync depends on the source. One that re-reads a window of history each time, like Apple Health, can resend retained data. An ordinary Photos sync does not replay its whole library; resyncing that phone's contribution, or turning Photos off and on again, re-reads the photos it can still access. Deleted or no-longer-accessible originals cannot be recovered that way. Treat a set-aside batch as data that did not make it.

Mobile app support

When you ask for help with a mobile-app issue, include the platform, the three readings from Settings → About, and the screen or permission state where the problem occurred. Never include a gateway token, pairing payload, private indexed content, or other credentials. Data handling and deletion controls are described in the mobile privacy policy.