Pi

All agent state lives in documented local locations (~/.pi/agent for settings, auth, instructions, extensions and sessions; project .pi folders), so a copy is available instantly without provider approval. However, no export/import pair or documented 'copy this folder' procedure covers the whole agent: /export and /import handle single sessions only. Restoring on another machine means installing Pi and copying directories by hand (optionally setting PI_CODING_AGENT_DIR). That is one shortfall: restore is not a single documented action.

• Configuration: agent directory
• Sessions: export and import
• Slash commands

In the default configuration everything that defines the agent is on the owner's disk: settings, models.json, auth.json credentials, SYSTEM.md/AGENTS.md instructions, skills, extensions, prompt templates, MCP config and full session trees including tool calls and compaction summaries stored with their source entries. Pi has no built-in schedules and no identity, so those classes are treated as met (G11). Integrations are re-linked with the owner's own API keys, OAuth tokens or MCP sign-in; no Earendil-registered client or broker is needed by default.

• Configuration
• Session file format
• Choose a model (auth.json)

The runtime is MIT-licensed, with no licence key, account or payment. The provider network calls in source (version check, install ping, model-catalog refresh) fail silently and are disabled by --offline or PI_OFFLINE. The bundled catalog and cached catalog data are used offline. This is a desk assessment; a blocked-network run was not performed.

• LICENSE (MIT)
• version-check.ts
• remote-catalog-provider.ts
• models.md (offline catalog)

Tools run in the Pi runtime, not in a hosted model feature. The owner chooses among many providers and can point Pi at the llama.cpp router (first-party /llama integration, documented to need --jinja for tool calling) or at Ollama, LM Studio or vLLM through models.json, without provider involvement. Classifier calls in codemode also work with llama.cpp chat models. No capability tied to one vendor's models was found.

• Choose a model
• Local models with llama.cpp
• pi.dev homepage

All agent state is local-first on the owner's device by default, so there is no account whose termination or shutdown could cut off access.

• Sessions: storage
• Configuration

Sessions are JSONL with a published per-entry schema. Settings, models and auth are JSON; instructions and skills are Markdown; extensions are TypeScript source. Nothing is encrypted or held in an opaque format.

• Session file format
• Configuration

The session file persists system messages with every prompt section and tool declaration, later patches to them, compaction summaries with a system-prompt checkpoint, and the model and thinking level on every assistant message and model_change entry. /session and the HTML export show these. One edge path is recorded here but not counted: an owner-installed extension using forceSystemPrompt sends text that differs from the recorded structured sections.

• Session file format (system messages, compaction)
• How Pi works: context

On a default install Pi sends an install/update report (version plus a User-Agent with OS, runtime and architecture) to pi.dev/api/report-install, and it sends version-check and model-catalog requests to pi.dev. pi.dev and earendil.com publish no privacy policy or retention period for this data (the /privacy and /terms paths return 404), so retention is undisclosed (G12). No agent content is sent by default.

• interactive-mode.ts (reportInstallTelemetry)
• pi-user-agent.ts
• pi.dev/privacy (404)
• earendil.com/privacy (404)

Source shows no paid placement or self-preferencing in the agent's context or defaults. /login preselects no provider, Earendil's Radius is one option among many, and per-provider default models are ordinary vendor models. Attribution headers sent to OpenRouter, NVIDIA and Cloudflare do not affect the agent's context or choices; they are documented and can be switched off via enableInstallTelemetry or PI_TELEMETRY.

• model-resolver.ts (defaultModelPerProvider)
• provider-attribution.ts
• Settings: telemetry

Every model tool call (with arguments), tool result and owner shell command is persisted to the session JSONL and never pruned. A failed append aborts the run instead of failing silently, because session persistence runs in an awaited agent-event listener. One shortfall: actions taken by extension event handlers (hooks) and extension commands outside model tool calls produce no session entry.

• agent-session.ts (persistence on message_end)
• session-manager.ts (_persist)
• agent.ts (awaited listeners)

Session JSONL entries carry no hashes, signatures or chain, so edits or deletions leave no trace.

• Session file format
• session-manager.ts

By default the agent's bash, write and edit tools run with the permissions of the user running Pi and no sandbox, so they can alter or delete files under ~/.pi/agent/sessions. The docs say Pi has no built-in sandbox and treat running inside a container as the owner's responsibility.

• Run Pi safely

All runtime packages are MIT-licensed in a public monorepo. npm releases are published with `npm publish --provenance`, so Sigstore build provenance links the default distributed package to the source commit and CI workflow. The pi.dev installer installs that npm package. This is a desk assessment; build verification was not performed.

• LICENSE
• scripts/publish.mjs (--provenance)
• pi.dev installer script

Pi has no agent identity: no keypair, DID or owner-domain identity, and outbound actions carry only the owner's own service credentials.

• Configuration

Within a session, the tree records model, thinking-level, prompt-section and tool changes, and /tree or /fork restores earlier conversation points. Changes to settings.json, SYSTEM.md/AGENTS.md, skills, extensions, auth and the runtime version are neither recorded nor attributed, and cannot be restored.

• Sessions: branching
• Session file format

The base prompt can be replaced or extended through SYSTEM.md and APPEND_SYSTEM.md at user and project level, and skills and prompt templates are Markdown. The built-in compaction and branch-summary prompts and the built-in tool descriptions can be replaced only by writing TypeScript extensions, so G3 caps the test at partial.

• Configuration (SYSTEM.md)
• Compaction reference (settings, extension hooks)

Pi has no hidden memory store. The only content reused across sessions is AGENTS.md/CLAUDE.md context files and skills, which are plain Markdown the owner can view, edit and delete. Compaction and branch summaries stay within their session file.

• Configuration: context files
• pi.dev homepage (context engineering)

Owners add any tool through MCP servers in mcp.json, extensions or git/npm/local packages, with no review. The defaultTools setting and --no-builtin-tools remove every built-in tool, and -builtin:<name> disables built-in extensions.

• Settings: tools and resources
• pi.dev homepage

The only provider-imposed protection is project trust, which the owner can set with defaultProjectTrust, /trust or --approve. Session logging can be turned off with --no-session. Pi ships no locked sandbox or content filter.

• Run Pi safely: project trust
• Sessions (--no-session)

Runtime and package updates only notify the owner and are applied by the owner. However, by default Pi refreshes a model catalog from pi.dev (at startup and on a 4-hour interval) that overlays and replaces built-in model entries by ID. The owner gets no notice before each change and does not consent to it. This is documented and can be deferred indefinitely only through the broad PI_OFFLINE/--offline switch or per-model overrides.

• remote-catalog-provider.ts
• model-runtime.ts
• models.md (catalog overlay)

Limits are per-tool on/off only, with no built-in path, network-egress or contact scoping. The docs say tools run with the full permissions of the user running Pi and the working folder does not restrict access. The agent can also edit its own settings.json and extensions with its write and bash tools. Two or more shortfalls apply. Spend is treated as met under G11 because Pi has no payment capability.

• Run Pi safely
• Settings: tools

Pi documents 'No permission popups' and asks for no approval by default. The npm package ships a first-party example extension, permission-gate.ts, that the owner can load to gate a fixed set of bash patterns (rm -rf, sudo, chmod 777). Gating any other action class requires writing an extension.

• permission-gate.ts example
• pi.dev homepage (No permission popups)

Aborting stops the current run, kills the bash process tree and returns queued messages to the editor without running them. Pi has no built-in scheduler, background jobs, subagents or provider-side work. A documented guarantee for this was credited; hands-on timing was not checked.

• How Pi works: agent loop
• bash.ts (killProcessTree on abort)

Content goes only to the model provider the owner selects; /share and /bug uploads are explicit owner actions, and opt-in analytics defaults to false. Non-content install/update telemetry to pi.dev is on by default (enableInstallTelemetry: true) and can be disabled via the setting or PI_TELEMETRY=0. There is no published data policy covering staff access or changes to data terms.

• Settings: updates, telemetry
• telemetry.ts
• Sessions: share and bug report

Credentials are stored in the documented, owner-readable ~/.pi/agent/auth.json or in environment variables. /logout removes them per provider and MCP sign-ins are managed per server. By default Earendil holds no owner credentials.

• Choose a model: authenticate
• Configuration

No provider-side agent copy exists by default. The documented uninstall explicitly leaves configuration, credentials, sessions and packages in ~/.pi/agent, so full deletion takes several manual steps (delete ~/.pi/agent and each project .pi folder), and no completion confirmation is given.

• Quickstart: uninstall
• Session file format: deleting sessions