Features

What Enso does for you, one page per feature. Each page uses the same six parts: what it shows, how to open it, what it looks like, what to look for, what it doesn’t do, and where to go deeper.

If you want to know how Enso works inside, start at the architecture instead.

Page	What it is for
Chat	Talking to pi in the browser: threads, streamed replies, tool calls, thinking, images and the command palette.
Sessions and projects	Choosing where a thread runs and on what: projects, the start dialog, and resuming a thread later.
Prompts	Your prompt library: system, append and session prompts, what each costs, and the manager to write them in.
Forks and lineage	Forking a thread at a prompt, and the record of the conditions each thread ran under.
Guards and receipts	What Enso refuses before a tool runs, and the receipt that says which rule refused it.
Permission modes	How much pi may do without asking, and how to change it.
Questions and dialogs	Answering pi from the browser: ask_user questionnaires and pi’s own prompts.
Context	What the next request is made of, and how the context grew request by request.
Context browser	Opening any request to see exactly what the model received.
Stats	What a thread spent, and on what: tokens, cache, cost per turn, and the costliest calls.
Diff	Every file that differs from the last push, as a tree, and the chosen file’s diff side by side.
Session eval	A thread’s scorecard and timeline, on the Stats tab or from the command line: what the person did, what the agent did.
Web access	How pi reads the web: web_fetch with an allowlist, and web_search.
Logs and debugging	Reading the day’s log, the debug views, and a bundle to attach to an issue.
Terminal	Running pi in your terminal with Enso loaded, sharing one login with the browser.
Settings	The page’s colour theme and fonts.

How the screenshots are made

Every screenshot is regenerated by bun run docs:screenshots. The script runs the real app in a throwaway home and a small throwaway project, shop-api, and plays one session through the page the way you would: the start dialog, four prompts, a model switch, a questionnaire, a permission prompt, a compaction and a fork. The home’s prompt library holds two prompts, an append prompt and a session prompt. Only the model is scripted: it is a local stand-in, listed as the demo provider, that answers with fixed replies. Everything else, from the guards’ refusals to the costs, is the app’s own. After a UI change, rerun the script and the pages match the app again. Every page uses the Enso Signal theme.

The numbered rings on a screenshot match the numbered list under it.

How the pages are made

Every page is built by the same run (#482). Its words live in a spec beside the capture (scripts/docs/features/<page>.ts), and the capture writes down what it saw: the clicks that reached each screenshot, the element each ring circles, and every value the page quotes from the session (docs/features/facts/<page>.json). A fact the code owns, such as a size limit or the list of guard rules, is read from the code itself. The page is assembled from those, so its instructions are the clicks that were made, its numbers are the ones on the screenshot, and its lists are the code’s. The pages are build output (bun run docs:build), not files in the repository.

To change a page, edit its spec and rerun bun run docs:screenshots --only <page>. A shot taken while the session runs (the start dialog, the questions) is retaken only by the full run. The docs build refuses a page whose spec and last capture disagree.