Try Pipkin alpha.
Know the edges.

Choose a simulated tour, run with a real Pi engine from source, or build an Arch package locally. Pipkin works on the author's Arch / Omarchy Wayland setup, but there is no published release or update channel.

Before you start

Alpha, not a published download

Built and used on Arch / Omarchy with Hyprland Wayland. A clean-machine install and some native accessibility and scaling checks remain. Other Linux desktops are unverified; macOS and Windows are unsupported.

For a no-credentials tour, run the simulated demo after building. For actual agent work, use your Pi credentials with a compatible engine. The screenshot below shows the built-in demo, not a real model session.

Pipkin's simulated demo welcome screen with its mascot and the message Ready when you are
Welcome screen · simulated demo

Prerequisites

You need a Wayland or X11 desktop, a Vulkan-capable GPU driver, and Node.js 22.19 or newer. X11 has only been checked under Xwayland. See the platform notes for the exact qualification.

  • For a source build, use the Rust toolchain pinned in rust-toolchain.toml and a Pi checkout with dependencies installed using npm ci.
  • For the Arch package, makepkg needs a Pi checkout beside the Pipkin repository; the resulting package includes the engine.
  • For real models, Pi reads your existing credentials from ~/.pi/agent. Provider requests may use the network. Pipkin does not sandbox the agent's tools.

Read the upstream installation guide before building; package prerequisites may change.

Explore the simulated demo

Demo · simulated agent

From a Pipkin source checkout, build and launch the demo without model keys or a provider connection:

From the pipkin repository root
cargo run -p pipkin-app --release -- --demo normal

If you have built and installed the local Arch package instead, use pipkin --demo normal. Other demo scenarios are listed in the README. The demo's replies and changes are simulated.

Run with real Pi from source

Place the Pipkin checkout alongside pi-fork/pi (or change the --pi-repo path). Install the Pi checkout's dependencies with npm ci, configure credentials in ~/.pi/agent, then run this from the Pipkin repository root:

Source build · real engine
cargo run -p pipkin-app --release -- --pi-repo ../pi-fork/pi --pi-agent-dir ~/.pi/agent --project .

The Pi engine runs locally; model-provider requests depend on your Pi configuration. For an offline real-engine scripted workflow without keys, see scripts/try-m2.sh—unlike the built-in demo, this exercises a real engine with a scripted provider.

Build an Arch package locally

On Arch / Omarchy, arrange a Pi checkout at ../pi-fork/pi relative to the Pipkin repository root, with its dependencies installed. Then:

From the directory containing pipkin/ and pi-fork/
git clone https://github.com/last-refuge/pipkin
cd pipkin/packaging
makepkg -si
pipkin --diagnose --probe

--diagnose --probe checks the install with a throwaway offline engine. The package bundles its Pi engine, but building it still needs the neighboring checkout. See packaging details. Release tarball installation and rollback tooling exist, but no tarball has been published; do not download a package from an unverified source.

What to expect

Built and tested
Streaming answers, tool cards, diffs, steer/queue/stop, drafts and recovery, saved conversations and search. The real-engine workflow has tests; real-model use is reported on the author's machine.
Still to check
Clean-machine pacman -U installation, 150% scale, minimize/suspend/resume, and broader platforms. Typed characters are not yet spoken in the composer by a screen reader; IME was tested with one engine.
Not measured
Wider beta reliability and usability targets. There is no telemetry or published release channel. Read the beta targets.

Help and feedback

Check the README, packaging notes, and native gate notes. Run pipkin --diagnose --probe on an installed build and report reproducible problems in GitHub issues. Diagnostics redact the home directory and do not read credentials, but review any logs or screenshots for tokens, private paths, and project content before sharing.

Review project status