Built on Your Computer
A desktop shell, a local backend, and a frontend workspace working together on your machine, with the website kept separate for licensing and updates.
Three Layers, One System
Each layer has a different job. Together, they create the local runtime that powers the app without turning the website into the prompt relay path.
Desktop Shell
The native Tauri shell handles windowing, sidecar lifecycle, updater wiring, and OS integration.
- • Native window controls
- • Sidecar supervision
- • Updater orchestration
Local Backend Runtime
The local Python backend owns provider dispatch, auth bootstrap, persistence, key handling, and orchestration.
- • Direct provider dispatch
- • Local persistence
- • Request orchestration
Frontend Workspace
The React interface provides Chatroom, module controls, settings, history, metrics, and workflow surfaces.
- • Multi-provider UI
- • Module surfaces
- • Local workflow control
How It Works
You Type a Prompt
Enter your question or task in the frontend workspace, with files, settings, and other local workflow context layered in as needed.
Local Backend Routes It
The local backend applies the request logic, reads the local key material, and dispatches the prompt to the selected provider.
Response Returns to the Workspace
The result comes back into the desktop workspace, where local history, metrics, exports, and workflow modules can act on it.
Design Principles
Local Execution
The working runtime lives on your machine, which narrows the trust boundary for normal prompt execution and local state.
Encrypted by Default
Sensitive data handling is local-first, with the desktop stack responsible for key handling and local persistence rather than a central relay service.
Direct Connections
Normal provider requests are dispatched from the local runtime to the selected provider instead of being routed through website APIs.
Transparent Design
The system is easier to reason about when the shell, local runtime, provider path, and website layer each have distinct responsibilities.
Related Reading
The architecture page explains the system shape. These pages go deeper into the security boundary, local-first trust model, and the reasoning behind the design.
Security Model
→Read the security and privacy boundary around the local runtime and provider path.
About KeyRing
→Read the product mission, operating philosophy, and local-first rationale.
Local-First vs Cloud Relays
→See the architecture distinction that matters most for trust and workflow control.
Why It Is Not a Wrapper
→Read the direct explanation of local dispatch versus relay-based app design.