Want to see, and control, everything Twira is doing?
Type /ar-dash. The whole control surface opens in your browser.

In your editor

Your IDE is where you write code. Your AI agent is where the work happens. The dashboard is the third surface, where you watch what the agent is doing, change how Twira behaves, and show the story to teammates, auditors, and stakeholders. Not where you do work; where you see and configure it.

What Localhost Dashboard does

Localhost Dashboard is a React 19 SPA embedded in the twira binary via rust-embed. Type /ar-dash in your agent (or twira dashboard open from any terminal); the CLI reads a lease file, re-uses any running instance, or spawns a detached server on port 8378 and opens your browser. 37 routes across four nav groups, Home (Welcome, Mission Control, Capabilities), Operate (Activity, Health, Sessions, Gateway, Diff, Port), Investigate (Search, Diagnose, Security, Team, Lore, Audit, Masterplan), Configure (Integrations, Tools, PII, Workspace, Data). A live WebSocket pushes every event from the project-local event bus into every connected tab. Auth: HMAC-signed cookies, CSRF tokens, sliding-window expiry, WebSocket Origin check. Binds to 127.0.0.1 only, no external network exposure.

How it actually works

Twira ships with a full interactive browser dashboard. Every setting Twira owns, every event it emits, every database it writes to, every multi-agent coordination signal, every audit-chain entry is in here. It is the visual control surface for the whole product. The CLI is excellent for the work loop, which is how the agent calls Twira through MCP; the dashboard is where you, the developer, go to see what is happening, change behaviour, wire up integrations, and explore. /ar-dash is the one-line way to get there from inside whatever coding agent you are in. Type the slash, hit return, the dashboard opens in your default browser.

The slash command resolves to twira dashboard open under the hood, and that CLI runs a three-phase flow rather than a naive "start a fresh server". Phase 1 reads the lease file at .Twira/dashboard.lease (a small JSON with the pid and port of the running server). If the lease exists and the pid is still alive and the port still responds to a TCP probe within 500 ms, the CLI just opens that URL, no second server, no port collision. Phase 2 fires only if the lease is missing or stale: clean up, spawn a fresh twira dashboard start --port 8378 --no-open as a detached background process (setsid on Unix, equivalent CREATE_NEW_PROCESS_GROUP on Windows). Phase 3 polls the lease and TCP probe in 200 ms intervals for up to 15 seconds; as soon as both signal up, the URL opens. If the window elapses without readiness, the CLI fails with a diagnostic that points you at running twira dashboard start in a foreground terminal so you can see the startup output, never silent. The shutdown counterpart, twira dashboard stop, reads the same lease, sends POST /__twira/shutdown to the running server, and deletes the lease on success.

The default port is 8378. The Gateway lives next door on 8377, the AI Compliance Proxy gets its own port. Both are configurable via --port. Each project gets its own dashboard server bound to 127.0.0.1 only, so there is no external network access and no cross-project bleed.

Inside the dashboard there are 37 routes across four sections. The shell is a React 19 SPA built with TanStack Router file-based routing, TanStack Query for data, and shadcn/ui primitives, embedded into the Rust binary via rust-embed. A collapsible left rail groups the routes into Home, Operate, Investigate, and Configure. Each group expands on hover to show its links plus a one-line hint.

Home is for orientation and tour. Welcome (the / route) is the 2-minute tour designed for the first launch: what Twira does, what is new, the four ways to use it. Mission Control (/mission-control) is the dashboard’s home base after onboarding, a live aggregator of failing detector runs, blocked masterplan items, MCP disconnects, recent audit entries, and sessions currently claiming files. Capabilities (/capabilities) shows all 42 capabilities Twira ships, browsable as an atlas (a graph view grouped by pillar) or a filterable grid; click any capability for a deep-dive sub-page covering what it does, where it surfaces, CLI examples, and the underlying MCP tool.

Operate is for watching what the system is doing right now. Activity (/activity) is the live feed of every event the system emits, streamed over WebSocket from the event bus, filterable by source (MCP, Dashboard, Gateway, Webhook), severity (Info, Warning, Error, Critical), and kind. Health (/health) shows database freshness, on-disk size per database, last-indexed timestamp, current index status, and MCP server connection state, the first place to look when something feels off. Sessions (/sessions) lists active and recent agent sessions with the files each one has claimed. AI Compliance Proxy (/gateway) is the Pro-only wire-layer control and audit surface for every LLM API call your stack makes, with reversible token substitution, signed receipts, and provider-key custody. Diff (/diff) shows working-tree and staged file changes at a glance, the dashboard’s answer to "what has the agent touched since I last looked?". Port migration (/port) gives the visual view of cross-language migration coverage: discovery sets, matched and unmatched and manual decisions, and how close the new codebase is to parity with the legacy one.

Investigate is for exploring what is in the code. Search (/search) does symbol, content, regex, and AI-mode search across the indexed code; AI mode is Lore-aware, searching the team knowledge layer alongside the index. Diagnose (/diagnose) runs any of the 65 deterministic detectors from a visual UI, with findings ranked by severity and full file plus line context. Security (/security) lists vulnerability findings (SCA) with drill-down to package, CVE, transitive path, and affected files. Team (/team) is the surface for multi-model brainstorms, peer reviews, and structured debates, pick the models, set the topic, see each model’s independent response side-by-side. Lore (/lore) is the team’s shared memory layer: lessons learned, gotchas, architectural decisions, surface counts; browse, search, and add new entries. Audit (/audit) is the tamper-proof signed log of every meaningful action, filterable by actor, date, and kind, with a one-click export of a signed bundle for compliance review. Masterplan (/masterplan) shows every plan in the project, with the item dependency graph, claim state, who is working on what, what is blocked, and what just completed.

Configure is the umbrella for changing what Twira does. Integrations (/integrations) is itself an umbrella over five sub-tabs: an overview diagram of how events flow through rules into webhooks and notifications; Webhooks (/webhooks) for outbound HMAC-signed POSTs to Slack, PagerDuty, or custom URLs with per-webhook secret and delivery history; Rules (/rules) for filters that match incoming events and emit RuleMatched synthetic events; Notifications (/notifications) for visual toasts, spoken alerts, browser notification permission, severity filters, and per-event-kind allowlist; and AI keys (/ai-keys) for OpenAI, Azure, Anthropic, and TTS provider keys, stored in the project .env and set, cleared, or tested from the UI. Tools (/tools) is the master on/off switch for every MCP tool, want the agent to use search but not gateway? Flip a toggle. PII (/pii) handles redaction settings: master enable, per-category toggles, severity floor, human-consent prompt config. Workspace splits into Account (/account) for install ID and tier and trial countdown, Pricing (/pricing) for the feature comparison and upgrade link, Updates (/updates) for update channels and version pin and rollback, and Settings (/settings) for telemetry, session-start nudge cadence, and other preferences. Data splits into Databases (/databases) for connecting Twira to your customer databases (Postgres, MySQL, MSSQL, DuckDB, MongoDB) for read-only schema awareness, Local storage (/database) for a read-only viewer over the local SQLite files Twira writes, and Encryption (/encryption) for the at-rest encryption toggle and key management.

Three standalone routes round it out. Documents (/documents) collects files the agent has surfaced as relevant to active work, PR descriptions, RFCs, ADRs that the indexer has linked to specific code paths. Savings (/savings) tracks cost for paid AI providers, broken down by provider, voice, and day. Benchmark (/benchmark) shows performance numbers against the legacy TypeScript Twira, index speed, search latency, detector throughput.

The dashboard is not a snapshot, it is a live view. Every page that shows real-time data subscribes to a project-local event bus and updates as events fire. Five background services start the moment twira dashboard start runs. The event follower tails ~/.Twira/events/ (the shared cross-process event log) and fans events out via an in-process broadcast channel and a tail buffer, so newly-connected clients get the last N events on reconnect. The WebSocket broadcast service pushes the live event feed to every connected browser tab; Activity is the canonical consumer, but every dashboard page can subscribe to the kinds it cares about. A DB mtime bridge publishes IndexChanged, GatewayUpdated, and SessionsUpdated events when the underlying SQLite files change, so legacy producers that have not yet migrated to publishing events keep working. A webhook dispatcher subscribes to the same broadcast channel, fires an HMAC-signed POST for every event matching an enabled webhook rule, and logs delivery records to webhook_deliveries.jsonl for the history panel. A rules engine evaluates every event against every enabled rule, and on match emits a synthetic RuleMatched event back into the bus, webhooks and OS notifications both subscribe to that, so the rule plus notification architecture is genuinely one pipeline. A native notification dispatcher fires OS toasts via notify_rust, reloading preferences fresh on every event so the master switch in Settings takes effect within milliseconds without a server restart.

The dashboard binds to 127.0.0.1 only, but local does not mean unprotected. Four auth layers ship together. The cookie signing key lives at <data_dir>/cookie.key with file-mode 0600 enforced; if the server cannot load it, it refuses to start rather than degrading to unauthenticated. A CSRF token is freshly generated per server start, injected into the served HTML as a meta tag and read by the JS client; every state-changing API request (PUT, POST, DELETE) must echo it as x-dashboard-token, and a missing or mismatched token returns 401. Session cookies are HMAC-signed with a sliding-window expiry, so every authenticated request refreshes the cookie and idle sessions expire. The WebSocket upgrade handler inspects the Origin header and only accepts requests from the local dashboard origin, blocking cross-origin browser exploits that try to attach to the dashboard’s socket. Together that means a malicious site you visit cannot poke your Twira dashboard even though it runs on localhost.

The frontend is a React 19 SPA (TanStack Router, TanStack Query, TanStack Table, Tailwind 4, shadcn/ui, react-hook-form, sonner) compiled to dashboard-ui-next/dist/ and embedded into the Rust binary at build time via rust-embed. There is no separate frontend deployment, no npm install on the user’s machine, no Node.js dependency at runtime. The binary serves the assets directly from memory. The backend is 28 axum handler modules (about 9,000 LOC of Rust) covering ai_keys, audit, benchmark, compliance, controls, databases, diagnose, diff, documents, encryption, gateway, identity, index, lore, masterplan, pii, port, real_agent, savings, search, security, sessions, system, team, tests, toasts, tools, and updates. Every dashboard page maps to one or more handler modules. The handler layer is async (axum requires it) but bridges into the sync core via spawn_blocking where needed.

Separately from the slash command, Twira’s session-start hook may emit a one-line system-context message to the agent reminding it the dashboard exists and offering to open it. Cadence is configurable via Twira.json under dashboard.session_nudge, always (nudge on every session start), every-N-days (the default, with N = 7, only if last_nudged_at is older than N days), or never. The nudge is silently suppressed whenever the dashboard is already running (the user clearly knows about it) or when the project has not been initialised yet (no .Twira/ directory). The cadence is controlled from the Settings page, so users who want a quieter experience can dial it back without editing config files.

Setup is automatic. twira init installs the slash command to .claude/commands/ar-dash.md in the project (project-scoped only, different projects have different dashboards on different ports, so a global copy would be ambiguous). The corresponding Bash("twira dashboard open*") permission is pre-approved during init, so the slash command runs without a per-call permission prompt. Works with any coding agent that reads .claude/commands/. The underlying CLI call works from any terminal in the project root.

Tier is Free. The whole dashboard surface, every page, every background service, every integration, the embedded SPA, the event bus, the auth layer, ships in the Free tier forever. Pro features inside the dashboard (Lore, Masterplan, multi-model peer review, AI Compliance Proxy, audit chain, and the rest) require a Pro licence to be active. Free-tier users see the page; Pro-gated actions prompt to upgrade when used. The dashboard itself is free for ever.