GSoC 2026 Proposal Draft - Performance Monitoring Dashboard

[aniruddhaadak80]

GSoC 2026 Proposal Draft: Performance Monitoring & Telemetry Dashboard

Hi Gemini CLI maintainers,

I am planning to apply for GSoC 2026 and have been exploring the repository. I've drafted a proposal for the Performance Monitoring Dashboard (based on project ideas discussed in the community) and would love to get your early feedback to align with the core team's vision.

1. Project Overview

As the Gemini CLI scales and incorporates complex agentic workflows (Conductor, MCP tools), users need visibility into token usage, latency (Time To First Token), and tool execution bottlenecks. This project aims to introduce a native performance monitoring system that logs metrics locally and visualizes them through an embedded TUI (Text User Interface) dashboard using ink.

2. Current Bottlenecks

• Users cannot easily track how many tokens a specific prompt or sub-agent sequence consumes.
• Identifying slow MCP tools or sandbox operations requires sifting through verbose debug logs.
• Hard to estimate API cost and latency hits during long autonomous runs.

3. Proposed Architecture

Phase 1: Telemetry Hooks in Core

• Inject lightweight execution wrappers around the gemini-cli-core API calls.
• Standardize a metric schema: imestamp, operation_type (LLM, Tool, IO), duration_ms, oken_count.

Phase 2: Local Storage Layer

• Persist structured usage data locally within ~/.geminicli/telemetry/.
• Ensure strict log rotation (e.g., retaining only the last 30 days) to prevent disk bloat.

Phase 3: Ink-Based TUI Dashboard

• Introduce a new command: gemini stats.
• Build an interactive terminal dashboard using ink to visualize token burn rates and average response times.

4. Timeline & Deliverables

• Weeks 1-3: Define schemas, implement core interceptors, and write unit tests for telemetry data collection.
• Weeks 4-6: Build the local JSON/SQLite persistence layer and data aggregation utilities.
• Weeks 7-10: Develop the interactive gemini stats dashboard and integrate ANSI-based charting.
• Weeks 11-12: Buffer for community testing, bug fixing, and finalizing documentation.

I would really appreciate any maintainer feedback on whether the abstraction layer for telemetry should live entirely inside the core package, or if it should be built as a separate internal module.

Looking forward to your thoughts!