AI Orchestrator (OrchestratorCLI)
A desktop Electron app, led by teammate Md Ahbab, that treats every AI coding CLI a developer might have installed — Claude Code, Gemini, Copilot, Codex, Cline, and others — as an interchangeable backend behind one orchestrator. A central planner (Grok, Gemini, or DeepSeek, in that fallback order) plans and dispatches work across them in parallel, over real PTY-backed terminal sessions rather than screen-scraped output.
The Problem
Juggling several AI coding CLIs by hand means manually noticing when one hits a rate limit, re-typing context into whichever tool is free, and getting no parallelism even when a task splits cleanly across agents. Packaging that as a desktop app adds its own failure class: process spawning, credential storage, and terminal I/O all behave differently on Windows than on the POSIX systems most CLI tooling is written for.
The Solution
The orchestrator plans a task, splits it into divisions, and dispatches each division to a CLI agent through a PTY session it owns end to end — spawn, resize, kill, and process-tree teardown all go through one service. Providers are health-sorted (online before limited before offline) so failover is visible in the UI, not just silent. A user-defined CLI registry lets someone register a coding agent the app doesn't know about out of the box, validated the same way the built-in ones are.
System Architecture
Electron wraps a React/TypeScript frontend and a local FastAPI + SQLite backend, so the desktop build and the browser dev build share the same code paths. Real-time terminal I/O and orchestrator events stream over WebSocket; REST covers sessions, providers, and settings. On Windows specifically, PTY spawning goes through pywinpty's low-level API, which — unlike the POSIX path — expects the process environment as a single null-terminated block string rather than a list of key/value pairs.
Key Features
Innovative solutions developed to solve complex technical challenges.
Multi-provider planning with automatic failover
A central planner (Grok, falling back to Gemini, then DeepSeek) breaks a task into divisions and routes each to a coding CLI agent, retrying against the next healthy provider rather than surfacing a rate-limit error to the user.
Real PTY-backed terminal sessions
Each dispatched agent runs in an actual pseudo-terminal the orchestrator manages — spawn, resize, and kill all go through one PtySession service, with process-tree teardown (taskkill /T on Windows, process groups on POSIX) so a killed session doesn't leave orphans.
Custom CLI registry
Users can register their own coding CLI (slug, command template, verb map) through a Settings tab; custom entries are validated and merged into the same registry the built-in agents use.
Health-sorted provider display
Providers are ordered online > limited > offline (then by name) everywhere they're listed — the providers panel, the collapsed sidebar, and onboarding — so which agent is actually usable right now is visible at a glance.
Encrypted local credential storage
API keys for each provider are encrypted at rest, with production configuration required to fail fast rather than silently mint a throwaway encryption key that would brick stored credentials later.
Cross-platform desktop packaging
electron-builder produces signed Windows, macOS, and Linux installers with the FastAPI backend bundled via extraResources rather than PyInstaller, plus an auto-updater wired through IPC.
Challenges & Breakthroughs
Challenge: Every terminal spawned by the Windows-packaged build crashed, because pywinpty's low-level spawn call expected the process environment as a single null-terminated block string, not the list of "KEY=VALUE" strings the POSIX path uses.
Growth: Rebuilt the Windows branch to join the environment into a `\0`-joined block with a trailing terminator, guarding against embedded nulls in any key or value. The fix only surfaces on an actual packaged Windows build, not in dev, which is exactly the kind of platform gap that's invisible until someone runs the installer.
Challenge: A PTY spawn could hang indefinitely on Windows with no timeout, leaving a runtime stuck in a 'starting' state that the UI had no way to recover from.
Growth: Wrapped the spawn call in `asyncio.wait_for` with a 10-second budget, and on timeout explicitly marked the runtime row 'failed' in the database instead of leaving it in limbo — a hang and a crash need different handling, and only one of them was covered before.
Challenge: The session-creation path had a double-checked-locking bug: the existence check ran inside one lock scope but the session got constructed and inserted outside it, so two near-simultaneous requests for the same runtime could each build a full PTY session before either was registered.
Growth: Moved session construction inside the same lock as the existence check, and added an explicit kill-and-replace path for the loser instead of leaking an unregistered process. Narrowing the lock window is only safe once every write it's supposed to protect is actually inside it.
Results & Impact
Next Project
Complete Legal Aid