Documentation

How PAI works.

A practical overview of the current alpha: installation, projects, PAI-Coder, verification, updates, release channels, and the architecture behind autonomous development.

01 · Start

Getting started

Download the current Windows installer, launch PAI, sign in when account access is available, and open an existing project or create a new one. PAI is intended to take you directly into the development workspace rather than forcing a separate project-management layer first.

Current platform

  • Windows 10/11, 64-bit
  • Developer alpha release channel
  • Native local PAI-Coder runtime
  • CPU fallback with CUDA acceleration where supported
02 · Projects

Working with projects

PAI's job is to understand the project before it edits it. That means identifying relevant files, languages, frameworks, entry points, requirements, dependencies, state flow, and cross-file contracts that could be affected by the request.

Primary workspace

Code is the main project workspace, Chat is the control surface, and Logs exposes build, verification, model, file, process, and error activity. Search behaves like an editor-style find experience rather than a separate destination.

03 · Runtime

PAI-Coder and model independence

PAI is the development system; the coding model is a worker inside it. The application owns planning, project context, file operations, verification, recovery, and outcomes. The current native PAI-Coder runtime is based on the project's trained coding adapter and packaged for local execution.

Why that matters

A stronger model can improve coding quality, but PAI's reliability should not depend on a model remembering every project constraint in a single prompt. Project-aware checks and verification live outside the model as part of the system.

04 · Evidence

Verification before completion

PAI is designed to treat compiler output, tests, runtime failures, deterministic checks, requirement coverage, and cross-file contracts as evidence. If verification fails, repair should target the failure rather than begin a speculative rewrite.

Outcome states

PAI can decide to edit, keep, or advise depending on whether a safe, useful implementation is supported by the available evidence.

05 · Distribution

Application updates

The 6.9 distribution architecture uses a release manifest and updater flow. Published packages are verified, staged, installed, checked after startup, and designed around rollback foundations so a bad application update does not become a user-project disaster.

Release manifest

Each channel can publish metadata such as version, channel, installer_url, package_url, sha256, and release notes.

06 · Channels

Release channels

Developer contains the newest alpha work for active testing. Beta is intended for preview builds after developer validation. Stable is intended for normal public releases once the product reaches the required reliability level.

07 · Access

Accounts and entitlements

PAI accounts use Supabase authentication and a server-controlled profile for plan and Founding Supporter status. The browser can read the signed-in user's profile, but entitlement changes are not trusted to the client. Payment information remains with the payment provider rather than being stored by PAI.