docsuse castserver dashboard

Server dashboard

Where you manage everything. A browser-based dashboard with two kinds of surface — panels for the mechanical stuff, and five console agents that handle the work that benefits from describing what you want in chat.

Getting here

The Cast server prints a URL when it starts. Run pnpm dev and a clickable http://localhost:5051 shows up in the terminal — open it in any browser. By default the web UI listens on 5051, and everything binds to 127.0.0.1 only (your machine, not the public internet).

If this is your first time, the Quickstart walks through installation end-to-end. For pinning the port to a fixed value, see Advanced → Runtime options. The dashboard stays on this machine by design; to reach your agents while you're away from it, wire up a transport — see Advanced → Deployment.

What you land on

The landing view is All Agents — a fleet-wide rollup with a stat summary and anything needing your attention. A sidebar gives you the fleet-scope console agents (Design, Configure, Review) plus a per-agent view for each agent on the server.

Server Dashboard — http://localhost:54321
Server
Messaging
Identities
Activity
Settings
All Agents
Design
Configure
Review
On this server
Rresearch-assistant
Eemail-triage
Hhousehold3
Pprediction-edge
Ddraft-botdraft
All Agents
5
Agents
12
Conversations today
2
Pending approvals
Needs attention
1 draft pending review

Click an agent in the sidebar and you land on its page. Same layout structure, but everything is now scoped to that single agent — its prompt, its config, its channels, its per-agent console agents.

Two kinds of surface

Across the dashboard, two kinds of surface do the work. Panels for the mechanical stuff — adding a transport route, pasting an API key, toggling who can talk, watching a status indicator. Console agents for the work that benefits from describing what you want in chat — wiring up a transport for a specific agent, narrowing someone's access, reviewing whether a change is safe.

Panel — Transports
Telegram
Enabled
Bot token
••••••••••••••••••••
Connected
Console agent — Configure
ConfigureSDK-only
Wire this agent up to Telegram.
Done. Telegram is enabled — Transports panel should show green.
Type to Configure…

Most operator work hops between the two. You set the model in a panel; you ask Per-agent Configure to wire up Telegram; you go back to the panel to check the status indicator turned green.

The five console agents

Console agents are LLM sessions with tightly-scoped tools, accessed by chat in the dashboard. They're the same kind of thing as the agents you author — but their job is to help you author and operate other agents.

⚠ HEADS UP
Console agents are an early preview and still being sharpened. When one falls short, the work it does is all plain files you can edit by hand or hand to Claude Code — the mature terminal path with the full authoring envelope.

Three live under All Agents and operate across the fleet — Design, Configure, and Review. The same Design and Configure shapes also exist scoped to a single agent — opened from inside that agent's page.

All Agents
Design
Compose multi-agent systems. Decompose a goal into draft agents and brief each per-agent Design session.
Configure
Survey and bulk-edit across the fleet — rotate a secret, change the global model, audit who's wired to what.
Review
Read-only QA gate across the fleet. Reviews design, configure, economy, and security lenses before a change ships.
Per-agent
Per-agent Design
Author this agent's behavior — prompt, channels, props, capabilities. Designer territory; an Operator dips in to tweak operator-facing props.
Per-agent Configure
Wire this agent to your install — model, secrets, transports, access, runtime knobs. Where an Operator spends most of their time.
🔒 SECURITY
Design has internet (for lookups) but no access to your secrets. Configure has secrets but is locked to model-only egress. Neither can do both, by construction — a compromised Design can't leak keys; a compromised Configure can't dial out.

When to open which

For per-agent work the split is mechanical: Per-agent Design for changes to what the agent is; Per-agent Configure for changes to how it's deployed on your install. The Operator persona lives mostly in Per-agent Configure:

You ask Configure
Wire this agent up to Telegram. Bot token is in the route I added yesterday.

Configure makes the change, reloads routes, and tells you when the Transports panel should turn green. The same pattern holds for every Configure-shaped task: you describe the outcome, Configure executes and reports back.

For cross-agent work — composing a multi-agent system, auditing the fleet, agent-to- agent permissions — switch to one of the All Agents console agents. Per-agent Configure handles human access only; agent-to-agent permissions and fleet-wide audits live under All Agents.

What console agents won't do

Console agents operate in a constrained envelope. Anything that runs as host code is outside what they'll attempt:

  • Service code (host-executable TypeScript that runs outside the container).
  • Modifying Cast packages — extensions, transports, gateway internals.
  • Cross-folder git operations, shell access, arbitrary file writes outside the agent.

When you ask for one of these, the console agent tells you it's out of scope and suggests Claude Code on the host — where you have the full authoring envelope. See Working in Claude Code for that path.