Local runtime & data
Aleph is local-first: the desktop runtime and its workspaces, files, chats, artifacts, indexes, databases, memory and local execution live on the user’s machine. A remote model, API or connector crosses the network when that connected capability is invoked. Local-first is not a promise that no bytes ever leave the device.
What stays distinct
Section titled “What stays distinct”| Kind of state | Purpose |
|---|---|
| Chat or session | Conversation and workflow history for a particular interaction. |
| Workspace state | Domain-specific organization, views and working context. |
| Memory | Persistent context used beyond one exchange, with scope determined by the feature and configuration. |
| Files and artifacts | Source material and generated outputs, including structured documents, visualizations and other work products. |
| Indexes and databases | Local structures that support retrieval and application state where enabled. |
These are not synonyms for one shared chat log. Profile isolation and data-lifecycle controls matter for each of them. Availability and deletion controls should be checked against the installed build; this documentation does not imply a universal one-click erase operation.
Execution versus inference
Section titled “Execution versus inference”Local model inference and local code execution are different operations. On macOS, Python and shell tasks use an isolated guest boundary; the guest must not silently fall back to unrestricted host execution. A remote model provider is a separate network boundary even when the agent’s session and artifacts remain local.
Connected operations
Section titled “Connected operations”An external provider can receive the inputs required for the operation the user invokes. OAuth, browser access, search and connectors also have their own authorization and network boundaries. The security model describes the controls at those crossings.