_{MAC CLIENT FOR PI}

Super light. Clean by design.
A faster, smoother way to work with Pi.

≈10 MB DOWNLOAD  ·  MINIMALIST DESIGN  ·  SMOOTH EXPERIENCE

Download for macOS · Requirements · Development

Ousia gives Pi a focused, polished workspace on macOS. It works with the Pi already on your Mac, so your models, extensions, settings, and conversations are ready to use.

The download is only about 10 MB, so Ousia is quick to install and takes up very little space.

• Super lightweight — only about 10 MB to download, with a small footprint on your Mac.
• Cleaner, more polished UI/UX — projects, conversations, light and dark themes, live tool progress, and a simple message box that keeps the focus on your work.
• Faster, smoother performance — a responsive interface that stays smooth while Pi is working, even during long conversations.
• Improved stability and reliability — protects saved conversations, prevents duplicate windows, and clearly tells you when something goes wrong.

The current release supports macOS on Apple Silicon.

1. Download the latest DMG from GitHub Releases.
2. Open the DMG and move the app to Applications.
3. Launch it and select your existing Pi executable, or let the app install Pi into its own managed directory.

Release builds are signed with a Developer ID certificate, notarized by Apple, and validated with Gatekeeper before publishing.

• Organize conversations into projects and sessions.
• Stream assistant responses, thinking, tool calls, and file previews in real time.
• Queue follow-up messages while Pi is working, or switch to steering mode.
• Choose from the models and providers already configured in Pi.
• Interrupt, compact, branch, move, archive, and export sessions.
• Tune theme, content width, type size, line spacing, and message density.
• Reuse the same Pi credentials, extensions, settings, and session directory across the CLI and desktop app.

┌──────────────────────────┐        JSONL RPC        ┌──────────────────────┐
│          Ousia           │  ───────────────────▶   │   pi --mode rpc      │
│  interface + native host │                         │   your Pi runtime     │
└──────────────────────────┘                         └──────────────────────┘
                                                               │
                                                               ▼
                                                  config · models · sessions

Ousia owns the desktop experience. Pi owns the agent runtime. There is no duplicate credential store and no bundled runtime hidden inside the application package.

To connect an existing Pi installation, Ousia only needs a valid pi executable. It can discover Pi from your login-shell PATH, common install locations, the active npm global prefix, or a path selected in Settings.

If Pi is not installed, Ousia can use your existing Node.js and npm to install @earendil-works/pi-coding-agent into an app-owned directory. This optional setup does not change the system npm prefix and never removes ~/.pi.

Prerequisites:

• macOS
• Node.js and npm
• Rust toolchain
• Pi, or a path supplied through PI_GUI_PI_PATH

Start the development app:

npm ci
npm run desktop:dev

Use a specific Pi executable when needed:

PI_GUI_PI_PATH=/absolute/path/to/pi npm run desktop:dev

Run the required checks:

npm run typecheck
npm run lint
cargo test --manifest-path src-tauri/Cargo.toml
npm run build

Build the macOS app locally:

npm run desktop:build -- --bundles app

The application is written with React, TypeScript, Tauri, and Rust. The desktop host communicates with Pi through strict line-delimited JSON over standard input and output.

export APPLE_SIGNING_IDENTITY="Developer ID Application: Your Name (TEAMID)"
export APPLE_ID="you@example.com"
export APPLE_PASSWORD="app-specific-password"
export APPLE_TEAM_ID="TEAMID"
npm run release:mac

• Pi remains the owner of its configuration, credentials, models, extensions, and sessions.
• Ousia stores only desktop UI state and the mapping required to reopen Pi sessions.
• State is written atomically.
• Host, subprocess, RPC, and renderer failures are recorded in structured local logs.
• Message content and tool payloads are not written to performance logs.

See LICENSE for the project license and NOTICE for third-party notices.