Developer Preview · supervised runtime

Supervised subagents and workflows for coding agents.

Pixir is an Elixir/OTP harness for running agent work as supervised local sessions. Drive it from the CLI or ACP clients; Pixir owns subagent lifecycle, workflow outcomes, failures, timeouts, and replayable evidence without making the presenter the runtime.

Explore the 0.1.17 candidate →Not yet published on Hex.

pixir · one supervised worker
After provider setup · run from your project

$ pixir doctor --json
Inspect readiness and any warnings.

pixir delegate --spec first-worker.json --dry-run --json --timeout-ms 150000
Check the plan before calling the model.

pixir delegate --spec first-worker.json --json --timeout-ms 150000
Inspect the result, child status and local Log.

Get the spec and complete setup →

Supervised runtime spine

Sessionconversation process
Turnone provider/tool loop
Subagentchild session lifecycle
Workflowstructured step outcomes
Evidencelogs and artifacts

First run · CLI or another coding agent

One worker. One result.
A Log you can inspect.

Start in a project that has a README.md. This example reads that file without editing it. The real run uses your configured provider and its account quota.

  1. Install the published runtime

    You need Elixir 1.20+ and OTP 29+. Add Mix's escript directory to your PATH if your shell cannot find pixir.

    mix escript.install hex pixir
    pixir --version

    Hex installs the CLI/ACP runtime. Monitor and repository delegation Skills are separate source-checkout surfaces.

  2. Choose a provider, then check readiness

    For the ChatGPT subscription route, run pixir login. For API keys or a compatible Open Responses endpoint, follow the provider setup in HexDocs. Keep credentials in your own environment, never in this spec.

    pixir doctor --json

    Read warnings and next actions before continuing. Missing auth is not ready; an absent local ./pixir can be expected when using a Hex-installed binary outside a source checkout.

  3. Inspect a small read-only plan

    Download first-worker.json and save it in your project. Inspect it before running: one explorer, one task, a 120-second child budget.

    View the complete spec
    {
      "contract_version": 1,
      "strategy": "subagents",
      "mode": "read_only",
      "subagents": {
        "workspace_mode": "shared",
        "role": "explorer",
        "max_threads": 1,
        "max_depth": 1
      },
      "tasks": [
        "Read README.md only and summarize this project in three bullets. Do not edit files, run shell commands, or delegate further."
      ],
      "limits": {
        "timeout_ms": 120000
      }
    }
    pixir delegate --spec first-worker.json --dry-run --json --timeout-ms 150000

    Dry-run does not call the model. Continue only if the plan is accepted and would_reject is false. Read-only mode is not an OS sandbox.

  4. Run, then inspect the evidence

    pixir delegate --spec first-worker.json --json --timeout-ms 150000

    Read command_ok, work_complete, each child's status and its answer. A successful command is not proof that the requested work is complete.

    Replace PARENT_SESSION_ID below with the parent_session_id returned by your run:

    pixir tree PARENT_SESSION_ID --json
    pixir diagnose session PARENT_SESSION_ID --json

    A root agent can use the same commands. If a child fails or times out, inspect its evidence and suggested next actions before retrying; do not blindly repeat the whole batch.

Release preview 0.1.17 · candidate

More reliable delegation.
Evidence you can act on.

Prepared for the next release, not yet published on Hex. The first-run guide installs the latest published version.

Deliver the intended change

A read should not replace your result.

Virtual-overlay workers can mark an explicit deliverable. Later unmarked reads do not displace it; applying changes is still a separate step.

Recover without guessing

No replay after ambiguous effects.

WebSocket recovery stops when it cannot establish that replay is safe. Missing token usage stays unknown, not a healthy-looking zero.

Less local overhead

Inspect once. Fold efficiently.

Session trees read each selected Log once per query. Anthropic replay builds lists linearly. These are local processing gains, not smaller model context.

Also in this candidate: Astra catalog support on the compatible ChatGPT/Codex route, compiled build identity, and broader verification. Model access still depends on your provider. The px8/pa5 prompt-contract change intentionally starts a new cache-warming cycle.

Why Pixir

Use any UI. Keep one supervised runtime.

Pixir sits below the operator and the interface. Codex can plan and audit; Zed, T3Code, or another ACP client can present the work; Pixir runs the supervised local Sessions when tasks need subagents, workflows, lifecycle state, replay, and auditable evidence.

spawn_agent

Subagents are Sessions

Every delegated worker has lifecycle, status, logs, and supervision.

run_workflow

Workflows are runtime graphs

Dependencies, concurrency, cancellation, failed steps, timeouts, and partial completion are tracked structurally.

pixir acp

Presenters are replaceable

Zed, T3Code, CLI, and other ACP clients can request work while Pixir owns the runtime.

open_responses

Bring your own endpoint

The provider layer speaks the Open Responses contract: point it at a hosted or local endpoint, no OpenAI account required.

Runtime Model

Small spine. Supervised consequences.

Pixir keeps the runtime model legible: Session to Turn to Provider to Tools. OTP supervision keeps Sessions, Turns, Subagents, and Workflows as runtime concerns instead of prompt conventions.

01
Start a Session

The workspace gets local runtime state, a session id, and append-only evidence.

02
Run a Turn

Provider calls and tool results flow through one inspectable loop.

03
Delegate safely

Subagents and Workflow steps can complete, fail, time out, detach, or resume.

04
Audit before trust

Summaries are not evidence. Logs, artifacts, and status records are.

Workspace choices

Choose where the work lives.

Isolation and storage are different decisions. Pick the workspace for the task; permissions still determine what a worker can do.

shared

Work in the current workspace

Useful for read-only exploration or carefully coordinated edits. There is no separate workspace copy; permitted writes affect the shared files.

isolated

Keep a separate disk snapshot

Useful when a child needs an independent physical workspace. Snapshot storage needs lifecycle management and cleanup as workers accumulate.

virtual_overlay · RAM

Avoid a physical copy per child

Useful for supported virtual commands across many workers. Edits live within one invocation; the next call reimports source files. Exported changes must be applied explicitly.

RAM mode is a storage and lifecycle choice, not a speed promise or a general-purpose VM. Canonical Logs and artifacts still persist on disk. In the 0.1.17 candidate, an explicit deliverable keeps a selected virtual result from being replaced by later unmarked reads.

Operator Primitives

Commands for operating agent work, not just chatting with it.

Pixir's first public surface is intentionally narrow: CLI and ACP. The primitives are built around diagnostics, continuation, supervision, and local evidence. The machine surface is a checked-in contract with pinned stable fields: docs/cli-contract.md.

pixir doctor --json

Check runtime, auth, config, workspace, and ACP readiness from a scriptable diagnostic gate.

pixir resume <session-id>

Continue from a durable Session instead of starting over from a transcript pasted into chat.

pixir tree <session-id> --json

Project the Session and Subagent hierarchy from local Logs without calling the model.

pixir compact <session-id> --dry-run --json

Preview history checkpoints before appending a durable compaction boundary.

pixir fork <session-id>

Branch exploration while preserving the original Session as evidence.

pixir acp

Run Pixir behind ACP clients while keeping JSON-RPC stdout clean and diagnostics separate.

Runtime Architecture

Presenters drive Pixir. Pixir owns the runtime.

Different tools, same boundary. Operators and presenters request work; Pixir executes, supervises, and keeps the evidence.

Operators & Presenters
Codex meta-orchestrator
CLI presenter
Zed ACP client
T3Code ACP client
Custom UI ACP client
Pixir Runtime
Session conversation process
Turn provider/tool loop
Subagents child Sessions
Workflows structured outcomes
Provider/Tools permissioned loop
Evidence Log logs and artifacts

Logos identify example operators or presenters. They do not imply bundled integrations, endorsement, or production support.

Evidence Layer

Agent work should leave evidence you control.

Log as truth matters because supervised work needs a durable record. Every run can be inspected, replayed, resumed, forked, compacted, or audited from local artifacts instead of a hidden chat store.

session.ndjsoncanonical format

Synthetic example, not a benchmark. Selected fields below; the download includes IDs and timestamps.

{"seq":1,"type":"user_message","data":{"text":"Summarize README.md without editing files."}}

{"seq":2,"type":"provider_usage","data":{"model":"example-model","usage_available":true,"usage_summary":{"input_tokens":1843,"cached_tokens":1190,"output_tokens":120}}}

{"seq":3,"type":"assistant_message","data":{"text":"README summary complete."}}
Download the complete NDJSON sample →
.pixir/sessions/*.ndjson

The Log is truth

Sessions persist as append-only local evidence for replay, repair, inspection, and audit.

provider_usage

Cache-aware work is measurable

Inspect the cached tokens reported by your Provider. Stable prefixes and WebSocket continuation are optimizations, not a cache-hit guarantee; missing usage is not evidence of zero cost.

pixir tree

Hierarchy is inspectable

Parent agents can query Session and Subagent status instead of blocking blindly.

Developer Preview

Preview scope.

Pixir is public enough to install and operate, but the contract is narrow on purpose. The site says this plainly.

scope.terminal Not a Pi TUI replacement

Pixir can be daily-driven through ACP, but it is not a finished standalone terminal app.

scope.adapter Not a packaged T3 provider

T3 Code pairing is dogfood through a local adapter, not a public install path.

scope.api Not a stable Elixir API

Hex installs the CLI/ACP runtime; internal modules are documented for transparency.

scope.sla Not production SLA software

No hosted service promises, telemetry, self-update, or enterprise support contract.

Get Started

Install the runtime. Run the diagnostic. Keep the evidence.

Start with Hex when you want the published daily-driver binary. Use a source checkout when you are working on Pixir itself.

Bring your operator.

Run the same CLI flow yourself or from another coding agent. Use pixir acp when your client speaks ACP.

Get the published package ↗