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
- 4mo ago
- License
- MIT
- Primary language
- Rust
- FA score
- 50/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platform
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- 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.
- Not a fit if
- Solo developers unwilling to run Docker and Postgres
- Integrators who need ready-made API docs and curl examples
- Source review
- 50/100 · Major gaps
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 | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| LiteLLM Agent Control Plane This agent | 50 · Major gaps | Self-hosted serviceFree + model costs | ★ 1.3k | 4mo ago | Rust | — |
| MonoCode | 71 · Some gaps | Desktop appFree | ★ 3.8k | today | Rust | Codex · Claude Code |
| Claude-Mem | 64 · Some gaps | CLIFreemium | ★ 115k | today | TypeScript | Codex · Claude Code |
| EOC — Everything OpenAI Codex Workflow OS | 64 · Some gaps | Agent plugin / skillFree + model costs | ★ 77 | 5mo ago | JavaScript | Codex |
How does FollowAgents rate this agent?
Why each dimension lost points
The docs distinguish the gateway master key from upstream provider credentials, say provider keys are encrypted, and recommend virtual team keys with budgets, model restrictions, and expiry. The bridge samples check runtime keys on non-health requests, and OpenClaw code identifies sensitive fields in persisted MCP configuration. Deductions: the local default is sk-local; auth is disabled when no master key is configured; and a bridge with no runtime key accepts any request carrying an x-api-key header. The sample does not establish granular permissions, user confirmation, complete data flows, or recovery procedures. The dependency list provides no evidence of vulnerability scanning or mitigation. Attribution is limited to the repository name and license copyright notice; publisher identity remains unknown.
The README and quickstart broadly agree on local startup and runtime registration, and several bridges expose health endpoints. The samples return readable errors for invalid OpenClaw configuration, missing runtime keys, and upstream request failures. Deductions: the README runtime list and Quick Start profile examples do not fully align, and this sample cannot establish all backend behavior or dependency availability in target environments; no availability commitments are shown.
The docs cover local individual setup, team keys, multiple runtimes, tool and skill selection, and link to API, channel, and runtime guidance. Deductions: guidance is limited on intended scale, disallowed scenarios, runtime-specific feature differences, and when scheduled runs should trigger. Docker Desktop is the main stated environment; hosted deployment and other environments are not developed in this sample.
The repository includes a Quick Start, authentication guide, runtime onboarding, and a contribution link. Install steps state prerequisites and Compose commands; Cargo.toml and LICENSE identify MIT, and naming is mostly consistent in the sample. Deductions: known limitations, FAQ, release history, and clear maintenance responsibility or support commitments are not provided. The skill file is an integration development checklist and does not fill these user-facing gaps.
A unified API, persistent sessions, scheduled runs, memory, and a shared UI are clear product uses; the UI steps and local startup command make initial use approachable. Deductions: the sample does not quantify time saved, cost, resource use, or runtime tradeoffs, so benefits are only partly supported; details on output formats and cross-runtime consistency are also limited.
Local startup, default key, runtime registration, and authentication behavior receive partial corroboration across README, quickstart, auth docs, and bridge code. Deductions: the product scope and runtime lists are not fully aligned, and the integration skill does not substantiate all supported capabilities; product claims are not systematically labeled as facts, inferences, or items needing validation.
- Local Compose defaults to sk-local; configure a strong master key and use virtual keys with least necessary access before team or production deployment.
- In the sampled bridge code, an unset RUNTIME_API_KEY means only that an x-api-key header must be present; do not treat that configuration as effective authentication.
- This assessment uses only the supplied static sample. No code was executed, and files not supplied, dependency status, and publisher identity were not independently verified.
Maintain this project? Add the FARS badge to your README
[](https://followagents.com/en/agents/litellm-agent-control-plane)<a href="https://followagents.com/en/agents/litellm-agent-control-plane"><img src="https://followagents.com/badge/litellm-agent-control-plane.svg" alt="FARS review"></a>FAQ
What is required to start it locally?
How do I sign in to the local UI?
Can it run against hosted model providers?
Does it preserve context between runs?
What does it cost?
Thanks — we use this to improve the page.