An open-source project on GitHub has turned the management of multiple artificial intelligence agents into something resembling a spaceship control room. LCARS for Herdr works as a command centre for Herdr, allowing up to 2,000 agents to be monitored, their activity reviewed, Claude Code and Codex quotas controlled, and session context transferred from one agent to another without losing completed work.
The keys to LCARS for Herdr in 20 seconds
- The project lets users monitor up to 2,000 AI agents from a single dashboard.
- It tracks activity, blocked agents, speed, costs, context and quotas by account.
- Tasks can be transferred between Claude, Codex and other compatible engines.
- Context is stored outside the repository so switching engines does not lose previous work.
- Version 0.1.0 works on macOS and Linux; Windows remains in preview.
The interface draws attention because it is inspired by the LCARS system from Star Trek: The Next Generation, but the more relevant part is what lies beneath the design. The project attempts to address a problem that is becoming increasingly common in AI-assisted programming workflows: what happens when a developer stops working with one or two agents and starts managing dozens of them simultaneously.
LCARS for Herdr is not a replacement for Herdr. It is a plugin that connects to its local session and displays agent information through two interfaces. One is designed for widescreen displays and represents the fleet as a spaceship; the other provides a more compact view for conventional monitors and laptops.
A control room for programming agents
The dashboard can show agents that are working, blocked, waiting or finished. Each one is associated with its workspace and provides information about generation speed, time to first token, cost, tokens used and context.
There is also a dedicated quota section. The system keeps Claude and Codex accounts separate rather than treating all consumption as a single pool. For Claude, the project uses different local and telemetry sources to reconstruct five-hour and seven-day usage windows. Information can come from OpenTelemetry, the Claude Code status line or data from individual sessions.
One notable detail is that the project does not treat an unknown quota as available capacity. If a usage window does not provide a reliable signal, the interface reports that information is unavailable rather than turning missing data into 100 % availability.
The system can also issue warnings when an account falls below a specified quota percentage. The default threshold is 10 %, although it can be changed through configuration.
For users working with multiple accounts, LCARS supports separate profiles. The documentation describes, for example, work and personal Claude accounts alongside another Codex account. Switching is performed manually and requires confirmation rather than automatically rotating credentials.
Switching agents while keeping the work
The project’s most interesting feature appears when an agent runs out of quota or is no longer suitable for a particular task.
LCARS for Herdr can open another engine in the same working directory and transfer the stored task information to it. The original agent remains open until the operator confirms that the transfer has been completed successfully.
The project separates this memory into two parts. One is mechanical and comes from Git: modified files, repository, branch and checkout. The other is narrative and includes elements such as the objective, decisions made and the next step.
This separation means that the system does not depend entirely on each agent’s internal format. According to the documentation, the mechanical state is obtained directly from Git, even when LCARS cannot read a particular engine’s conversation history.
The transfer also has explicit limitations. Permissions, MCP servers, running tools and active subagents are not transferred. The new agent receives the available context and must start in the same working directory.
The project also accounts for failed transfers. If the new agent does not start, its panel closes and the previous state remains intact. If there is uncertainty about whether the context arrived correctly, the new panel stays open for inspection and the transfer chain does not continue until confirmation is received.
Claude, Codex, OpenCode and Pi in one dashboard
Although Claude Code and Codex play a major role in the implementation, LCARS for Herdr is not limited to those two engines.
The documented version includes adapters for Codex, OpenCode and Pi, in addition to the Claude Code integration. Each uses its own local data sources to obtain information about sessions, tokens, costs, tools and models.
For Codex, the project reads JSONL session files to obtain tokens, model, effort, duration, time to first token, context usage, tools and errors. OpenCode uses its local SQLite database, while Pi uses JSONL files from its sessions.
This allows the dashboard to present information from different engines through a common interface, although not every metric necessarily has the same level of accuracy. The project distinguishes between data sources and avoids inventing metrics when a particular signal is unavailable.
The architecture is organised around independent adapters. Adding another CLI requires creating an adapter that translates its sessions into the agent model used by the server.
A design intended not to become another problem
The project pays considerable attention to security because the dashboard can display terminal content, file paths and session data.
The server is restricted to local interfaces such as 127.0.0.1, localhost and ::1. It also checks Host and Origin headers when present to reduce risks associated with CORS and DNS rebinding attacks. HTTP controls accept only JSON requests and request-size limits are in place.
Credentials are not copied between profiles either. LCARS uses each CLI’s own authentication mechanisms and keeps account identifiers separate from secrets. The documentation also states that tokens used to query Claude data remain in memory during the request and are not written to logs.
The project includes tests covering HTTP security, the launcher, the status line, the memory system and concurrent writes. Continuous integration runs with Node 22, 24 and 26.
The available version is 0.1.0, so LCARS for Herdr should be understood as an early-stage project rather than an established enterprise platform. macOS is listed as supported and tested with a real fleet; Linux is validated through CI, although the author notes that a real installation against a Herdr instance has not yet been completed. Windows is listed as a preview.
The result is a tool that is curious on the outside and considerably more ambitious underneath. The Star Trek aesthetic is probably the first thing users notice, but the actual goal is different: turn a collection of independent programming agents into a fleet that can be observed, have its consumption measured and be moved from one engine to another without forcing each task to start from scratch.
Frequently asked questions
What is LCARS for Herdr?
It is an open-source plugin for Herdr that provides a control dashboard for monitoring AI agents, their sessions, quotas, costs and activity.
How many agents can it manage?
The project is designed to display and control up to 2,000 agents from a single interface.
Can a task be switched from Claude to Codex?
Yes. LCARS can open another engine in the same checkout and transfer the stored context. The change requires confirmation and does not move permissions, MCP servers or running tools.
Which operating systems does it support?
Version 0.1.0 is supported on macOS and Linux. Windows is available as a preview.