pome run records to the dashboard by default. The raw trace also lands on disk under runs/<task>/<run-id>/ — events.jsonl, the state snapshots, and a verdict.json per hosted trial. The score itself is computed in the cloud, so the dashboard is where it lives.
What you find
Navigation is a left sidebar. Home sits on its own at the top — the workspace overview: metric tiles, a 7-day evals trend, your agents, and a rail of runs that need attention. Everything else is grouped:
Signing in drops you on Home. Documentation is a link in the sidebar footer,
next to your plan and account — not a nav item.
Agents
The entry point to per-agent reliability rather than a roster. One card per registered agent; open one and you get Tasks, Runs, Twins, and Settings tabs. The drill-down asks the reliability question one level at a time:- Agent → the tasks it is graded on, and how it does on each.
- Task → every trial of that task, so a result you cannot reproduce reads as a pass rate instead of a green checkmark.
- Trial → one run: its trace, its score, its handoff.
Runs
A run is a single task execution. The run page shows:- The full trace. Every tool call the agent made, in order: one row per LLM turn — model, tokens in and out, latency — with the tool calls nested under the turn that made them. Any agent that exports OTLP spans gets this, whatever framework it is built on.
- The journal: the twin side of the same run, one row per call your agent made into the twin. Select a call that wrote and the step inspector opens a State diff — the twin’s state before and after that one call — alongside its request and response.
- The score against the task’s acceptance criteria.
- The handoff, written by the narrator. A concise summary plus an actionable suggestion to fix or improve the agent. Use it as the next prompt back to your coding agent.
Twins
A catalog of twins, with a monitor for the sandboxes you start from it. The page opens on the catalog, grouped by category — Dev tools, Fintech, Communication, Project management — and searchable. A twin whose runtime is mounted in the cloud is marked available and can be selected; the rest are coming soon. Available today: GitHub, Stripe, Slack, Gmail, Linear, one page each in the Digital twins reference. Select one and Start sandbox boots it. Loading the page never starts a sandbox on its own — sandboxes are real backend resources that cost money, so nothing spins up until you ask for it. This selector takes one twin. The platform itself allows up to three per sandbox; the dashboard’s own screen offers a single one today, and that is a limit of this screen rather than of the product. To start a multi-twin sandbox, usepome sandbox create --twin … --twin … or
POST /v1/sandboxes — Sandboxes
sets the two side by side.
A running sandbox shows up above the catalog, and the Running stat at the top
of the page counts them. Open one for the endpoints you point your agent at: the
MCP URL, the API URL, and the bearer token every /s/<sandbox-id>/… request
carries. Stopping the sandbox tears its twins down with it.
Sandbox lifecycle is also driven from the CLI via pome sandbox create / list / stop.
How runs end up here
Anything that talks to the backend lands on the dashboard:pome run <task>from the CLI.- Coach-driven runs over the Pome MCP — the
pome-run-taskskill, or any MCP client callingrun_taskandfinalize_runitself. - Any agent you have registered with
pome register agent, once it makes scored runs.
POME_API_KEY first when it is set (CI), then the macOS Keychain (where pome login stores the key on macOS), then ~/.pome/credentials.json (other OSes, or when Keychain is unavailable). See Your own agent for the login flow.
Open it
pome register agent prints when it registers the agent.
Next
Write a task
Turn what a run shows you into your own graded exam.
Sandboxes
What the Twins page starts: one id, one lifetime, one to three digital twins.
Billing semantics
What Usage is counting, and when a run is charged.
CLI reference
pome run, pome register agent, pome sandbox, and the auth env vars.