Skip to main content
Neroli feels simple when you treat the session as the unit of work. A session is not just a terminal tab. It is an isolated worktree, provider TUI, panes, status, automations, review state, and optional cloud handoff moving together.
Placeholder image: one Neroli session containing a provider TUI, browser pane, run automation, changed files, and review status.

A session keeps the agent, files, panes, automations, status, and review evidence together.

Workspace, session, worktree

This is what lets you run multiple agents without losing track of which files, commands, browser, or review belong to which job.

What belongs to a session

Why direct TUIs matter

Neroli launches the real provider interfaces directly. That keeps the app fast and avoids a stale wrapper around your agents. You still get the provider’s native behavior, shortcuts, auth, model features, and release-day updates. Neroli adds the workspace layer around it: isolation, visibility, automations, panes, review, and cloud handoff.

Session panes

Panes keep useful context attached to the work instead of scattered across your desktop.
Cloud sessions can keep terminal, browser, diff, and file panes. Simulator and preview panes are local-only because they depend on your Mac.

Status is part of the product

Neroli tracks whether a session is running, waiting for input, asking for approval, blocked, failed, ready for review, local, or cloud. The point is not to watch every token. The point is to know which session needs attention.

Agents can use the workspace too

The Neroli CLI is mostly for agents and automations. It lets them inspect the current workspace, attached panes, browser, simulator, known services, recent sessions, and saved automations. That is why you can ask an agent to run the browser, verify a UI flow, create setup automations, or analyze recent sessions without handing it a pile of local paths.

The useful habit

When you start a job, think in this order:
1

Pick the session

Start fresh for new work, or continue an existing session when the context already lives there.
2

Attach the right panes

Add the browser, terminal, simulator, diff, or file viewer that makes the work visible.
3

Use automations

Run the workspace’s setup, run, build, verify, and stop actions from the session.
4

Move the session

Use the sidebar board to reflect where the work actually stands.
5

Review before merging

Ask the agent to self-review, inspect the result, then decide what lands.
Next: organize parallel work with the Session board, then turn the model into repeatable workflows with Automations.