Watch and run all of Fulltrace from inside the editor
The window onto Fulltrace, built into my code editor: a VSCode extension that shows everything the system is doing without leaving it. A sidebar tree gives status at a glance; a seven-tab panel goes deeper, headlined by Studio. I pick a job, see the price before it runs, approve the spend, and watch it work live through to the finished report.
07 dashboard tabs07 studio views03 clients tracked0 runtime dependencies
the_tour[01]
The Dashboard, Toured
Five tours of the dashboard, walked live and played end to end: the sidebar rail, the seven tabs, a workflow taken from the catalogue through to what it cost, a finished run opened up to its per-stage verdicts, and the findings report where a fix is either offered or refused. Hover to hold a step, or drive with the dots.
Demos
FULLTRACE DASHBOARD···
STATUS1
Online5h 21m
MEMORY
57 MB
RESTARTS
2
UPTIME %
88.7%
Start
Restart
Stop
Open Dashboard2
USAGE3
SUBSCRIPTION
CLAUDE USAGE
5h42%
7d83%
5h resets in 20m7d resets in 23h 50m
CODEX USAGE
30d99%
resets in 24d 7h
API
OPENROUTER CREDITS
used50%
$17.39 left$35.00
TOOL USE4
SESSION
ALL-TIME
Uptime
5h 21m
6d 5h
Requests
165
1,689
Context reads
0
14
Commands
39
185
Tokens
16K
7.9M
TOKENS BY MODEL
kimi
0
7.1M
deepseek
0
798.7K
haiku
9.5K
34.9K
sonnet
5.9K
33K
opus
594
16.1K
fable
0
2.9K
unattributed
0
10.6K
MCP SERVER5
Context
Commands
Memory
Hooks
1Runtime health. Online state, uptime, memory and restarts, with start, restart and stop controls.
2Open the workspace. Open Dashboard opens the full panel and fills the main area with the workflow catalogue.
3Budget windows. Live usage against Claude's 5h and 7d windows, Codex's 30d window, and OpenRouter credits, each with its reset timer.
4Session telemetry. Session and all-time counters, plus a per-model token breakdown for attributable spend.
5MCP surface. The extension's own MCP server: Context, Commands, Memory and Hooks as live resource trees.
1Studio. The run hub: Workflows, Runs, Audits, Models and Agents, priced and launched from one screen.
2Config. Setup wizard, MCP servers with live probes, shared commands, settings and hooks.
3Analytics. Per-model usage and cost across Claude, Codex, Cursor and OpenRouter, with a Compare view.
4Context. The ten portfolio files, with read counts and last-read times.
5Memory. Claude and Codex memory in one list, with create and guarded remove.
6Logs. Every log stream in one place, plus per-client file sync checks.
7Development. Dev slices, the roadmap and build log, the UI/UX register, and the decision inbox.
1Studio's five views. Workflows, Runs, Audits, Models and Agents, organised around the life of one run.
2Workflow catalogue. Executable against Planned, capability flags, and a real average cost per run before launch.
3Open a workflow. Clicking a row opens its detail: the shape it runs, what it costs, and what past runs did.
4The shape. Fan out across the enrolled targets, an optional deterministic verify gate, an advisory challenge, then gather.
5Capabilities and options. What the workflow can do, and the Configure toggles for this run only.
6Targets and parallelism. Which projects the run fans out across, and how many run at once.
7A model per stage. Per-stage defaults, each overridable for a single run without touching the workflow default.
8Priced before it runs. An estimate from past runs, with the real average and pass rate beside it as an honesty check.
9Where the money goes. Spend, requests and tokens split by model: 90.6% of the spend on 40.2% of the requests.
1Every run in one place. In-progress, completed and queued, in one read-only list with filters.
2The limit, and what it is killing. Ninety-one finished jobs by duration; three killed at the 10m limit and re-run.
3Hover any bucket. What completed in that band, which stage, and how many were aborted in it.
4The failures behind the number. Fourteen failed and four recovered, each naming its node, model and limit.
5What each one cost. Forty-five completed runs, with cost, tokens and models joined onto every one.
6Open one. A code audit that finished at 7:27 pm on 30 July: $0.36, across three models.
7What the run was. Workflow, outcome, start, duration, tokens in and out, and the node tally.
8What it cost, model by model. Spend, requests and tokens split three ways, against the workflow average.
9The branch that set the length. 24m 12s of node time in a 12m 46s run, and one serial stretch of 6m 28s.
10The graph it actually ran. Three targets audited, verified and challenged in parallel, then gathered.
11Into a node. Clicking a fan-out node opens the stages it ran and the report it wrote.
12Every stage, every model. Five stages, a rejection, a correction and a second review that approved.
13Inside one stage. Execution at 1m 43s and six tool calls, with the thinking time between them.
14What it found. A passed verdict and seven findings, ready to carry into review and apply.
1The report a node wrote. What it audited, under which conventions, and that review approved it.
2Context in, findings unmoved. The files the run was given, what each was for, and a hash of what was sent.
3Graded before it is read. Severity, model confidence, and the risk of the fix, then the file, line and function.
4Reasoning, then remedy. The argument is kept separate from the patch, with a jump to the source.
5Not every finding gets a fix button. Structural findings are refused an automatic fix and offered a plan instead.
6The safe ones get a dry-run. Prepare fix drafts a change and freezes it as a hashed artefact, applying nothing.
7My call, and it stays mine. Accept, reject, defer or ask for evidence, recorded with no effect on future audits.
studio[02]
One Hub for the Whole Run Lifecycle
Studio consolidates workflows, runs, signals, projects, audits, models, and agents into one screen organised around the life of a run. I choose the work, check the price, confirm the spend, and watch it happen live through to the result, without touching a terminal. Watching is always read-only; anything that acts, launching a run, editing a workflow's saved default models, warming or evicting a local model, running or removing a sub-agent, recording a disposition against a finding, is a deliberate, confirmed press, and every one of those acts is ledgered.
flowchart LR
D["Discover workflow catalogue"] --> C["Configure choose options and targets"]
C --> E["Estimate cost priced from run history"]
E --> L["Launch explicit spend confirmation"]
L --> O["Observe live runs + graph view"]
O --> U["Understand results and findings"]
%% Blueprint tokens as literal hex (Mermaid cannot parse CSS vars or color-mix)
classDef step fill:#62d99a1f,stroke:#62d99a,stroke-width:1.5px;
classDef spend fill:#e0be621f,stroke:#e0be62,stroke-width:1.5px;
class D,C,E,O,U step;
class L spend;
Live without a reload
The screen updates itself every 4 seconds while a job runs, advancing node statuses and moving finished runs from Active to Completed. An idle tick never redraws the page or closes something I have open.
Outcomes, not just statuses
Graph nodes badge whether their newest stage was approved or rejected, not just whether it ran. Finished runs carry their cost, tokens, and models, and by-model donut charts break spend down per model for a workflow or a single run.
Drill through to the evidence
Clicking any fan-out node opens its detail: the findings report it produced, a clear passed-or-failed verdict, the models and tokens each stage used, and a jump straight into the Audits view with that target already selected.
Projects, read-only by design
The newest pill draws one card per product with its code targets underneath, derived fresh on every read from the committed registries and the run history. Readiness is a counted checklist (present, absent, or not applicable), never a score, and the only button is Refresh: changing a project stays a hand-reviewed git edit.
Enrolment that only proposes
Enrol a project starts from a repository folder and an AI tool of my choice. The runner composes a fenced interview prompt and hands it to that tool on my own account, so Fulltrace spends nothing and writes nothing. What comes back is a proposal: the registry entry still lands as a reviewed edit plus a restart.
Signals, descriptive only
The Signals pill mines the run ledgers into per-workflow signal: verifier verdicts, decision rates, what the evidence actually supports. Deterministic and display-only, with no model anywhere in it. Every number states its denominator and whose opinion it aggregates, my code decisions are never blended with my website rejections, and a store that has never been written says so instead of borrowing "not built yet". It informs what I pick next; it changes nothing on its own.
apply[03]
Approving a Fix, Without Trusting It
The audit does not just find problems, it offers to fix them, and this is the one place in Fulltrace where an AI can actually change my code. So it is the part I was most careful with. The flow is four steps: review, dry-run, approve, apply, and what makes it safe is what sits between them. I see the exact change first, the project's own build has to accept it before I am even asked, and what I approve is that one specific change, not a standing permission.
architecture[04]
Single Poller, Two Surfaces
One StatusPoller polls the gateway's GET /status every 4 seconds and scans the filesystem for skills, commands, memory files, and agents. The sidebar and the full panel both read from that same poller, so the two surfaces never drift out of sync with each other.
Sidebar TreeView
Always visible in the VSCode activity bar. Shows server status, uptime, last memory sync time, and the portfolio file list, and opens any portfolio file straight into the editor. No interaction needed to keep it current: the poller drives updates automatically.
WebviewPanel
Opens on demand from the activity bar or command palette into the full seven-tab interface. It is a passive consumer of the same poller state, so opening it triggers no extra requests. The layout fills the editor window and scrolls within the active tab only; the status card and tab nav stay fixed.
status_poller_scanwhat one poller reads, every 4s
StatusPoller(4s interval)
├── polls GET /status ──▶ server metrics, token counts, logs
The extension runs on only the VSCode extension API, Node's own built-ins (http, child_process, fs), and the TypeScript compiler at dev time only. No npm packages ship at runtime, no bundler: just a VSIX installed via code.cmd --install-extension.
02
Theme-aware, colour-coded UI
Every colour is a var(--vscode-*) theme token, not a hardcoded hex value, so the webview matches whatever theme the editor is in automatically, and a nonce-based CSP keeps it from running injected script. Each AI client also gets its own distinct, consistent colour across every tab and badge, so a client is recognisable at a glance.
configuration[06]
Settings
Every part of the connection is configurable under agentOsDashboard.* in VSCode settings: which host and port the gateway listens on, how often it polls, and which pm2 process the Start/Stop/Restart controls drive. Those controls call pm2 with no shell and a process-name allowlist regex, so the configured name can never break out into an arbitrary command.
dashboard_settingsevery agentOsDashboard.* key
Server connection
host: MCP server host (default: 127.0.0.1)
port: MCP server port (default: 3000)
statusPath: status endpoint path (default: /status)
pollInterval: poll frequency in ms (default: 4000)
pm2 integration
pm2ProcessName: pm2 process to control (default: agentOS-portfolio)
Start/Stop/Restart buttons in the Status tab drive pm2 via child_process.spawn with no shell, plus a process-name allowlist regex, so the configured name cannot break out into arbitrary commands