nap

Describe an app. Step away. Come back to a project with evidence behind it.

nap is an open-source AI app builder for software work that needs more than a model response. You describe an app in chat. An agent writes it into an isolated sandbox, serves a live preview, commits the workspace, and runs the project's own checks before nap calls the work verified.

Use nap as an app, a local runtime, or a reference implementation for long-running coding-agent systems.

A model saying "done" is a claim. A passing checkpoint is evidence.

Live demo · Docs · Architecture · NapBench

The GIF is a 22-second cut from a real two-minute session. It shows the prompt, sandbox tool calls, project checks, verification, and the resulting app. The full session is on the docs page.

What nap does

• Builds in an isolated workspace. The agent reads and edits files in an E2B sandbox. A Vite server exposes the project through a live preview while the turn runs.
• Keeps work after the browser goes away. The API admits a turn to a durable Postgres queue. A worker executes it, so closing a tab or deploying the API does not cancel the work.
• Streams from a durable event log. Events are appended before they are published. A reconnect asks for everything after its last sequence number, so it can catch up without duplicates or gaps.
• Separates commits from checkpoints. Every file-changing turn creates a commit. Only a commit that passes the discovered checks becomes a checkpoint, which is nap's last known-good state.
• Repairs bounded failures. A failed check opens another turn with the failure in its context. The repair budget has a hard limit.
• Puts idle projects away. nap stores the Git repository, destroys the idle sandbox, and restores the project when you return.

How a prompt becomes a verified project

prompt
  ↓
durable job → worker → agent in sandbox → commit
                                      ↓
                              project checks
                                ↙       ↘
                           pass          fail
                            ↓              ↓
                       checkpoint    bounded repair turn

The job and its transcript come from the same append-only event log. That gives nap one answer to what happened, what was verified, and where to continue. The full event model, job lifecycle, and verification rules are in the technical docs.

Evidence, with scope

These are historical measurements, not a promise about every deployment. The load test used fake model and sandbox providers, so it measured nap's queue, event log, workers, and WebSocket path. The real-model measurements tested the verification path and did not establish a model-score improvement.

Result	Measurement
Concurrent turns in the latest cluster run	100
Turns completed in that run	2,422
Job, turn, and verification completion	100%
Sequence gaps, duplicate events, WebSocket failures	0
Event delivery at 100 concurrent turns	20 ms p95
Fast local suite at this revision	3,982 tests in 288 files

The latest cluster run included 231 mid-turn reconnects. It ran on 24 August 2026 after an earlier run on 23 August. Read the cluster report and the single-process baseline for the test profile, caveats, and comparison.

The verification measurements covered 12 real runs and cost $0.15 in total. They found and fixed a real verifier blind spot, but the sample was too small to support a claim about score improvement. See the first measurement and the re-measurement.

Run bun run test:fast to reproduce the local-suite result. The cluster numbers use fake model and sandbox providers. They describe the deployment path, not production model or sandbox capacity.

Try it without credentials

The runtime has fakes for external services, so you can exercise the core loop locally without Docker, API keys, network access, or spend.

bun install
bun run test:fast
bun run harness "build a todo list"
bun run ws:smoke

The harness prints the event stream for one complete turn. The smoke test drives the WebSocket path over a real socket. test:fast runs the unit, type, and web suites without Postgres.

Run the full app locally

You need Bun, Docker, an E2B key, a model-provider key, and a Cloudflare R2 bucket for snapshot storage.

bun install
docker compose -f infra/docker-compose.yml up -d
cp apps/api/.env.example apps/api/.env

Fill in the required values in apps/api/.env. For a local worker setup, also set:

NAP_EVENT_BUS=postgres

The example file documents each variable. The API validates its configuration at startup, including the database, model provider, authentication, key encryption, and snapshot storage settings. Production also rejects configurations that would make sign-in depend on third-party cookies. See the deployment requirements.

Start the processes in separate terminals:

This is the beginning of the README. Read the rest at the original. Read the full README ↗