What on-device should mean for a Mac AI assistant

An AI assistant can run as a Mac app and still send its most important work somewhere else. The window is local. The data path might not be.

That distinction matters more than the label on the download button.

I have been building Pace as a local-first Mac assistant, and the useful question has become: which parts of the interaction actually stay on the machine?

Follow the whole request

A screen-aware assistant can touch several types of data during one task:

1. microphone audio and its transcript
2. the visible screen or selected text
3. the prompt assembled for planning
4. model inference
5. memory or conversation history
6. the action sent to another application
7. optional network features such as updates or linked services

Calling the product on-device because one model runs locally is incomplete. The privacy boundary is the path taken by all of this data.

Local-first is a system property

A meaningful local-first assistant should make the local path the normal path. Speech recognition, screen context, planning, memory, and actions should not quietly depend on a hosted assistant. Networked features can exist, but they should be optional and visible.

This also affects latency and failure behavior. A local interaction should not stop working because a remote service is unavailable. If a feature does require the network, the interface should make that boundary clear before the request leaves the machine.

Screen context needs restraint

Reading the screen is powerful and easy to overreach with. The assistant rarely needs a permanent archive of everything visible. It needs enough current context to complete the requested task.

That suggests a narrower design:

• capture only when the interaction needs it
• keep the context bounded to the current task
• avoid uploading screenshots as a hidden default
• store memory locally and let the user clear it
• request macOS permissions at the point of need

The permission prompt is only one layer. Good behavior after permission is granted matters just as much.

Actions reveal the real boundary

An assistant becomes useful when it can do something: open an application, type into a field, copy text, or complete a workflow. That is also where the trust model becomes concrete.

I want each action to remain attributable to a user request, use the smallest required permission, and preserve enough state to explain what happened. A local model does not remove the need for confirmation around consequential actions. It only changes where planning occurs.

A practical test for on-device claims

Before trusting an assistant's privacy claim, I now ask:

• Can the core workflow run with the network disconnected?
• Which features explicitly require a connection?
• Are speech, screen context, prompts, and memory stored locally?
• Can I inspect and clear retained data?
• Does the product explain macOS permissions before requesting them?
• Are actions bounded and attributable?

If these questions are difficult to answer, the on-device label is doing more marketing work than technical work.

I mapped Pace's current data path and boundaries at https://heypace.app/on-device-ai-assistant-mac/. The project is still evolving, and the public page keeps the limits visible alongside the local-first design.