Control center

What the dashboard is for

The embedded dashboard is where you re-enter the loop. It keeps enough runtime state visible that you can check progress, spot drift, and intervene only when the queue actually needs you.

Three questions should be easy to answer from the dashboard:

• Can I leave the loop alone for a while longer?
• Which issue actually needs a developer right now?
• Are retries, sessions, or token burn drifting in a way that needs intervention?

Core surfaces

Overview

Use the overview page before you open a specific issue. It tells you whether the loop is healthy enough to leave alone or whether it needs attention:

• running agents
• retry queue pressure
• total issue count
• token burn across recent runtime snapshots
• 24h throughput and retry trends

Work board

The work board is where you reroute work without losing the rest of the queue:

• drag issues between lanes
• filter by project, state, and search
• keep blockers, live sessions, and token spend visible on the card
• inspect an issue quickly without losing board context

Issue detail

Issue pages are intentionally dense because this is the main re-entry surface. They keep the execution transcript, live state, blockers, branch and PR state, token usage, image attachments, and agent controls close together so you do not have to context-switch during supervision.

The image card on the issue page is where screenshots and bug captures live:

• thumbnails stay visible next to the transcript and controls
• uploads and deletions happen directly on the issue page
• the same local images also appear when you edit the issue through the composer dialog

Sessions

The sessions surface is for active orchestration periods when multiple workspaces are moving at once. Use it to read live session identifiers, last activity, and retry context without opening each issue individually.

Embedded server behavior

By default, maestro run starts the HTTP server on http://127.0.0.1:8787. Use --port to override it. That server serves:

• the embedded dashboard on /
• the health endpoint on /health
• the live observability API on /api/v1/...
• the dashboard application API on /api/v1/app/...
• the dashboard invalidation stream on /api/v1/ws

The UI and API are intentionally colocated because they describe the same live daemon.

The split matters:

• the dashboard UI reads the richer local control-plane API under /api/v1/app/*
• the CLI helpers such as status --dashboard, sessions, and events use the older live runtime endpoints under /api/v1/*
• the browser refreshes dashboard data when /api/v1/ws sends an invalidate event

Practical reading order

If you are debugging live behavior:

1. Start on overview.
2. Move to the work board to isolate the affected issue.
3. Open the issue detail page for transcript, screenshots, and control data.
4. Use sessions when the problem is broader than one issue.