Maestro (its-maestro-baby) — Summary

Maestro (its-maestro-baby) is a cross-platform desktop application built with Tauri 2.0 (Rust) + React that runs 1-6 AI coding assistant sessions simultaneously in isolated git worktrees, featuring a built-in MCP server for agent status reporting, a plugin marketplace, a GitKraken-style visual git graph, and a built-in Rust MCP server that exposes a maestro_status tool agents use to report their current state.

Problem it solved: The same core problem as the RunMaestro variant — serial AI coding is slow; parallel worktree isolation enables true parallel development. The its-maestro-baby variant differentiates on tech stack (Tauri/Rust backend for native performance vs Electron/Node) and the MCP-first agent status protocol.

Distinctive trait: The built-in Rust MCP server (maestro-mcp-server) that agents connect to via stdio and call maestro_status to report state — this is the only framework in this batch where the worktree manager itself exposes an MCP endpoint that agents actively call back into.

Target audience: Developers on macOS, Windows, Linux who want native-performance terminal multiplexing for 1-6 simultaneous AI sessions, with a plugin marketplace for extending per-session capabilities.

differs_from_seeds: Most similar to superpowers (Claude Code target, git worktrees) but is a desktop app shell rather than a skills plugin. The Tauri/Rust architecture and the bidirectional MCP server (agents calling maestro_status back to the app) are novel relative to all 11 seeds. Unlike claude-flow's outbound MCP (app calls tool server), maestro-its-maestro-baby's MCP is inbound: agents report status TO the app.

Maestro (its-maestro-baby) — Overview

Origin

Independent project by @maestro5240871 (Twitter). MIT license. Version 0.2.5. Active as of 2026-04-19.

Philosophy

From README:

"The Bloomberg Terminal for CLI Agents, its Maestro Baby!"

Core beliefs:

1. True isolation: "Each session operates in its own git worktree. No merge conflicts, no stepping on each other's changes."
2. AI-native workflow: "Built specifically for Claude Code, Gemini CLI, OpenAI Codex, and other AI coding assistants."
3. Status transparency: Agents should be able to report their state back to the orchestrator app via a standard protocol (MCP).

Design principles

Technology bet

Unlike the RunMaestro variant (Electron/Node), this project bets on Tauri 2.0 (Rust backend) for native performance and a smaller binary footprint.

Maestro (its-maestro-baby) — Architecture

Distribution

• Tauri 2.0 desktop app (macOS, Windows, Linux)
• No npm global install; download pre-built binary or build from source

Tech stack

Directory structure

maestro/
├── src/                  # React/TypeScript frontend
│   ├── components/
│   │   ├── git/          # Git visualization & operations
│   │   ├── marketplace/  # Plugin marketplace UI
│   │   ├── settings/     # Settings modals
│   │   ├── terminal/     # Terminal grid & panes
│   │   └── sidebar/      # Sidebar navigation
│   ├── stores/           # Zustand state stores
│   └── types/
├── src-tauri/            # Rust backend (Tauri commands, core logic)
│   └── src/
│       ├── commands/     # Tauri command handlers
│       └── core/         # ProcessManager, WorktreeManager
├── maestro-mcp-server/   # Rust MCP server (4 files)
├── cli/                  # CLI wrapper (maestro.sh)
├── docs/                 # Documentation
└── website/              # Docs website

Worktree path

~/.claude-maestro/worktrees/{repo}/{branch}/

Required runtime

• Node.js 18+
• Rust 1.78+ (build from source)
• Git

Target AI tools

• Claude Code
• Gemini CLI
• OpenAI Codex
• Plain Terminal

Maestro (its-maestro-baby) — Components

MCP Server: maestro-mcp-server

Built in Rust. Exposes one tool to agents:

Agents discover this MCP server via their MCP config. This is the orchestration backchannel — agents actively update the dashboard.

CLI wrapper

UI components

Plugin system

• Plugin types: Skills, Commands, MCP servers
• Per-session plugin configuration
• Automatic symlink management for commands and skills
• Marketplace-based distribution

No prompt templates, skills, hooks at the platform level

Like Crystal, this framework adds no behavioral modification to the AI agents. The plugins (skills/commands) that users install through the marketplace may add those, but none are bundled.

Maestro (its-maestro-baby) — Uniqueness & Positioning

differs_from_seeds

Most similar to superpowers in target tool (Claude Code) but is an orchestration shell, not a skills plugin. The defining novelty relative to all 11 seeds is the reverse MCP pattern: agents call back to the orchestrator app via maestro_status rather than the app calling a tool server. In claude-flow, the app calls 305 MCP tools hosted on a server; here, agents call one MCP tool hosted on the desktop app — inverting the typical MCP client/server relationship. No seed framework uses agents as MCP clients calling home to the UI. The Tauri/Rust backend (vs Electron/Node in every other desktop app in this batch) also differentiates on performance posture.

Positioning

• "The Bloomberg Terminal for CLI Agents" (project's own tagline)
• Targets users who value native performance (Rust/Tauri) over the broader feature set of RunMaestro
• Plugin Marketplace enables community extension without bundling opinionated methodology
• 1-6 session cap: explicitly sized for focused parallel work, not massive swarms

Observable failure modes

• 1-6 session hard cap may be limiting for large-scale parallelism
• No Auto Run / playbook system: no way to batch-execute AI tasks unattended
• No Group Chat: no multi-agent coordination beyond manual routing
• maestro_status requires agents to be configured with the MCP server; agents that don't call it won't show status

Inspired by

• Anthropic Claude Code SDK worktrees tutorial
• GitKraken (visual git graph)
• iTerm2 (split pane shortcuts)

Relationship to RunMaestro

Not a fork — entirely independent implementation in a different language (Rust/Tauri vs Electron/Node). Same conceptual space (parallel worktree manager), different architectural choices and feature scope.