LiteLLM Agent Control Plane
A self-hosted control plane for creating and running agents across supported runtimes.
- Source repo
- LiteLLM-Labs/litellm-agent-control-plane
- Stars
- ★ 1.3k
- Last updated
- 3mo ago
- License
- MIT
- Primary language
- Rust
- FA score
- 29/100 · Major gaps
At a glance
- Works with
- Universal · cross-platform
- You'll need
- Typical use
- A platform team needs one UI through which developers can create and run agents on OpenCode, Deep Agents, and Hermes.
- Main limitation
- The documented local quick start requires Docker Desktop and starts both Postgres and the platform service.
- Source review
- 29/100 · Major gaps 5 safety controls not found
What does this agent do, and when should you use it?
LiteLLM Agent Control Plane is a unified control plane for multiple agent runtimes. Its web/API service and UI let developers create agents, connect selected tools and skills, and choose a runtime for execution. The platform manages persistent sessions across runs, CRON schedules, and memory across sessions. Docker Compose starts the LiteLLM Agent Platform service, Postgres, and template runtimes, then registers local runtimes in the UI. It suits teams that want one operational surface for OpenCode, Deep Agents, Hermes, OpenClaw, Claude Managed Agents, or Cursor Agents API rather than a single-runtime workflow.
After startup, the LiteLLM Agent Platform web/API service exposes a UI and API at localhost:4000. A developer creates an agent in the UI, selects tools and skills to connect, then selects a runtime on which to run it. docker compose --profile opencode up starts the platform, Postgres, and the OpenCode template runtime and automatically registers local-opencode; the deepagents, hermes, and openclaw profiles register local-deepagents, local-hermes, and local-openclaw. The platform retains agent sessions, can run agents on CRON schedules, and preserves context across sessions; provider credentials must be added in Settings before using a hosted model provider.
- A platform team needs one UI through which developers can create and run agents on OpenCode, Deep Agents, and Hermes.
- An engineer using the OpenCode template runtime wants a local stack and an automatically registered runtime from docker compose --profile opencode up.
- A team needs an agent to retain context between separate runs and can use persistent sessions and memory.
- An operations team needs agent work to run periodically and can configure CRON schedules.
- An organization wants developers to create and run agents without direct Bedrock or Anthropic console access.
How do you install or deploy this agent?
Install Docker Desktop, then run: docker compose --profile opencode up. Open http://localhost:4000 and sign in with the master key; the documented default is sk-local. This starts the platform web/API service, Postgres, and the OpenCode template runtime, and registers local-opencode automatically. To start only the base platform stack, run: docker compose up.
How do you use this agent?
After signing in at http://localhost:4000, create an agent in the UI, select the tools and skills to connect, and choose a runtime to run it. Template profiles include: docker compose --profile deepagents up, docker compose --profile hermes up, and docker compose --profile openclaw up; profiles can also be combined with docker compose --profile opencode --profile deepagents up. Before running against a hosted model provider, add provider credentials in Settings.
What are this agent's strengths and limitations?
- Provides one web/API control surface for creating and running agents across multiple named runtimes.
- Docker Compose profiles automatically register local template runtimes through the platform API after services are healthy.
- Includes persistent sessions, cross-session memory, and CRON scheduling for recurring or long-running workflows.
- The documented access model lets developers work through the platform instead of requiring Bedrock or Anthropic console access.
- The documented local quick start requires Docker Desktop and starts both Postgres and the platform service.
- Hosted model-provider use requires provider credentials to be configured in Settings.
- The supplied documentation does not provide copyable API endpoints, request bodies, or curl examples.
- Integration steps for runtimes beyond the listed template profiles and supported runtimes are not documented.
How does this agent compare with similar options?
This is positioned as a common control plane rather than a replacement for one runtime: OpenCode, OpenClaw, Deep Agents, Hermes Agent, Claude Managed Agents, and Cursor Agents API are listed as supported runtimes.
Key facts side by side with the most closely related agents.
| Agent | Source review | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|
| LiteLLM Agent Control Plane This agent | 29 · Major gaps | ★ 1.3k | 3mo ago | Rust | — |
| EOC — Everything OpenAI Codex Workflow OS | 75 · Good | ★ 91 | 1mo ago | JavaScript | Codex |
| Claude-Mem | 73 · Some gaps | ★ 95k | today | TypeScript | Codex · Claude Code |
| MonoCode | 56 · Major gaps | ★ 1.1k | 1d ago | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows use of crypto_secretbox for sensitive data encryption, but key management details are absent; dependency locking (--locked) and CI checks provide some dependency security; no user confirmation, data flow transparency, external effects control, rollback, or source attribution found. Deductions: missing user confirmation, data flow transparency, external effects control, rollback, and source attribution.
README and Cargo.toml are consistent, CI includes tests, but no failure message design is provided; dependency versions are pinned but availability is not guaranteed. Deduction: missing failure messages.
README clearly identifies target users and scenarios, supports multiple runtimes; capability boundaries are partially described, but trigger precision and deployment environment requirements (Docker) are not fully specified. Deductions: insufficient trigger precision and environment fit.
Information architecture is clear, installation notes are detailed, license is explicit; but known limitations and version changelog are missing, naming stability is not clarified. Deductions: missing known limitations and changelog.
Output usability is not detailed, marginal value is clear (unified API), cost-benefit is not quantified. Deductions: insufficient evidence for output usability and cost-benefit.
Claims in README lack traceable evidence, no cross-source corroboration, facts and inferences are not separated. Deductions: lack of traceability and cross-validation.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Not found in source: data-flow disclosureWatch which external services it contacts (proxy or firewall logs) and keep sensitive data out until you know where it goes.
- Not found in source: disclosed external effectsEstablish which external systems it writes to, sends to or changes, and verify with test accounts or repos before production.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- Not found in source: verifiable attributionInstall from the official repo or registry and check the publisher and URL to avoid look-alike packages.
- No user confirmation mechanism is provided; agents may execute actions automatically.
- Data flow is not transparent; how sensitive data is transmitted and stored is not described.
- No rollback mechanism is present; recovery after failures is difficult.
- Dependency security relies only on locking and CI; no vulnerability scanning is provided.
- Publisher identity is unverified; source attribution is unclear.