GSoC 2026 Proposal Interest: [Idea 2] Studio Observability Dashboard

[moksha-hub]

Hi mentors! I am Moksha, I came across project Ideas and interested in working on Idea 2: Studio Observability Dashboard for GSoC 2026.

Proposed Approach

Phase 1: Backend Metrics Service (Weeks 1-3)

• Build metrics collection layer in mofa-runtime
• Expose REST endpoints: /api/agents, /api/metrics
• Implement WebSocket /ws for real-time streaming

Phase 2: Studio Integration (Weeks 4-6)

• Create Makepad-based visualization panels
• Integrate with existing makepad-chart and makepad-d3
• Implement 4 core views: latency, throughput, queue depth, model load state

Phase 3: Bottleneck Detection (Weeks 7-8)

• End-to-end scenario testing
• Documentation and reproducible setup

Questions:

1. Should the metrics service live in mofa-studio as a separate crate or extend mofa-monitoring?
2. What's the current state of agent event tracking - are there existing hooks I can leverage?
3. For MVP, which agent flow should I target first for bottleneck demonstration?

Looking forward to your guidance!

[moksha-hub]

Implementation Plan — Studio Observability Dashboard (Idea 2)

Hi @BH3GEI @yangrudan — I've spent time reading through the existing codebase before writing this, so this plan is grounded in what's actually there. Here's my full proposal.

---

Codebase Audit (What Already Exists)

crates/mofa-monitoring/ already has a solid foundation I can build directly on top of:

• DashboardServer + axum router with CORS, tracing middleware, embedded assets (rust-embed) and routes: GET /, /styles.css, /app.js, /assets/*, /api/*, /ws — all wired in server.rs
• WebSocketMessage enum in websocket.rs already defines: Metrics, AgentUpdate, WorkflowUpdate, LLMUpdate (with tokens_per_second, avg_latency_ms, error_rate), Alert, Heartbeat, Subscribe/Unsubscribe — the WS contract is already spec'd
• ApiResponse<T> + ApiError in api.rs — generic JSON wrapper with success/data/error/timestamp
• AgentStatus and WorkflowStatus response types already derived from AgentMetrics / WorkflowMetrics — health scoring logic exists (healthy/degraded/unhealthy based on failure ratio)
• sysinfo crate is already a dependency for CPU/memory snapshots
• mofa-kernel provides: DebugEvent, TelemetryEmitter, ChannelTelemetryEmitter, RecordingTelemetryEmitter, SessionRecorder, InMemorySessionRecorder
• mofa-foundation provides: WorkflowExecutor.with_telemetry(), WorkflowGraph.to_dot()

mofa-studio already has GPU-accelerated Makepad UI with dark/light theming, plugin app system, DirtyVec dirty-tracking primitives (used in mofa-widgets), and makepad-chart / makepad-d3 as available visualization deps.

This changes the design significantly — the scaffolding is there; the gap is in connecting it end-to-end and building the Studio-side UI panels.

---

Related Issues I've Identified

Repo	Issue	Relevance
mofa	#331 — Visual Debugging [Task 18]	Directly adjacent: adds SessionRecorder → REST/WS debug endpoint layer on top of mofa-monitoring. I'll coordinate scope carefully to not overlap.
mofa-studio	#14 — Studio Observability Dashboard [Issue 1]	Foundation libs/mofa-metrics crate — I'd like to coordinate ownership of this with whoever is working on it.
mofa-studio	#40 — Vec::drain O(n) CPU spikes in log panel	Related: log buffers feed the dashboard. Fix is VecDeque-based — I can submit this as a pre-GSoC contribution.
mofa-studio	#38 — Decouple Studio from Dora CLI [Task 15]	Stretch goal dependency: unified monitoring across Dora + mofa-native backends.

---

Design Decisions

Q: Where does the metrics service live?
I propose keeping runtime-side metrics collection in crates/mofa-monitoring/ (already publishable to crates.io per Cargo.toml) and wiring it as a background service started from the Studio shell — not as a separate libs/mofa-metrics. This avoids duplication and the existing MetricsCollector + DashboardConfig builder pattern is clean enough to extend.

Q: How does Studio connect to the backend?
Via a local WebSocket client in the Studio shell (mofa-studio-shell) connecting to ws://127.0.0.1:8080/ws. The existing WebSocketMessage enum is already tagged JSON (#[serde(tag = "type", content = "data")]) — I'll deserialize this on the Studio side and fan events into Makepad's Cx::post_action / signal system.

---

Phased Implementation Plan

Phase 1 — Ground Truth Metrics (Weeks 1–2)

Goal: stable, tested /api/agents, /api/metrics, /ws emit real per-stage timings

The current LLMUpdate message already carries tokens_per_second and avg_latency_ms. What's missing:

1. A PipelineTrace struct in mofa-monitoring/src/dashboard/metrics.rs capturing per-stage timestamps: asr_start/end, llm_start/first_token/end, tts_start/end
2. Hook into WorkflowExecutor.with_telemetry() in mofa-foundation to emit these from the running agent steps
3. A /api/metrics/pipeline endpoint returning rolling p50/p95 latencies per stage
4. Unit tests: seed MetricsCollector with synthetic traces, assert correct percentile math and JSON shape

crates/mofa-monitoring/src/dashboard/
├── metrics.rs          ← add PipelineTrace, stage timing logic
├── api.rs              ← add GET /api/metrics/pipeline
└── tests/
    └── pipeline_metrics_test.rs  ← new

Phase 2 — Studio Panels (Weeks 3–5)

Goal: 4 live views in MoFA Studio consuming real data

I'll add a new app apps/mofa-observatory/ in the mofa-studio workspace following the same plugin pattern as mofa-fm:

Panel	Widget	Data Source
Latency	makepad-chart line chart (p50/p95 per ASR/LLM/TTS stage)	/api/metrics/pipeline + WS Metrics event
Throughput	makepad-chart bar chart (req/s, tokens/s)	WS LLMUpdate → tokens_per_second
Queue Depth	makepad-d3 gauge	WS AgentUpdate → tasks_in_progress
Model Load State	makepad-d3 state indicator	WS AgentUpdate → state (Offline/Idle/Active/Error) + health score

The Studio shell's WS client will deserialize WebSocketMessage (already tagged JSON) and dispatch to each panel via Makepad's action system.

mofa-studio/
└── apps/
    └── mofa-observatory/
        ├── Cargo.toml
        └── src/
            ├── lib.rs
            ├── ws_client.rs       ← WebSocket → Cx::post_action bridge
            ├── panels/
            │   ├── latency.rs
            │   ├── throughput.rs
            │   ├── queue_depth.rs
            │   └── model_state.rs
            └── screen/
                └── dashboard.rs   ← panel compositor

Phase 3 — End-to-End Demo + Docs (Weeks 6–8)

Goal: acceptance criteria fully met

• Bottleneck scenario: Run a mofa-fm voice chat pipeline, deliberately introduce latency in the LLM stage (via a slow mock), demonstrate the dashboard surfaces it as a p95 spike in the latency panel with a model state flip to degraded
• Wire Alert WS messages to surface actionable notifications when p95 > configurable threshold
• Integration test: spawn DashboardServer in-process, run a multi-node workflow with telemetry attached, assert /api/metrics/pipeline returns ≥ 3 stage entries in correct order
• Reproducible setup: cargo run --example observatory_demo in mofa-monitoring

---

Pre-GSoC Contribution (Starting Now)

To get familiar with the codebase before the proposal deadline, I've identified mofa-studio #40 (Vec::drain O(n) CPU spikes) as a clean first fix — replacing the log buffer in mofa-fm, mofa-asr, and mofa-debate with VecDeque<String> to match the ring-buffer pattern already used in mofa/crates/mofa-monitoring/. I'll open a PR for that this week.

---

Questions for Mentors

1. Is mofa-studio #14 (foundation libs/mofa-metrics) still open for contribution, or is it already in progress? I want to coordinate rather than duplicate.
2. The existing WebSocketMessage::LLMUpdate is a strong signal that per-model observability was already planned — is there already an instrumentation hook in mofa-runtime emitting these, or is that the gap I should fill in Phase 1?
3. For the bottleneck demo, is mofa-fm (voice chat) the preferred target flow, or should I target a simpler pipeline first?

---

Looking forward to your feedback. Happy to adjust scope based on what's already in flight.

[moksha-hub]

Can I get Assigned now to start Working.

[lijingrs]

Submit GSoC proposals separately.