LiteLLM Agent Control Plane: One API in Front of Six Agent Runtimes

The problem: agent runtimes multiply faster than your access model

A team that starts with one coding agent usually ends up with four. One person runs OpenCode locally, another uses Cursor Agents API, a third has Claude Managed Agents through a company account, and someone is experimenting with Deep Agents. Each of those has its own credential story, its own session model, and its own way of being invoked. The LiteLLM Agent Control Plane takes the position that this is an access and coordination problem rather than a framework problem. Its README lists five things it manages: a unified API across runtimes, access so that developers create and run agents without Bedrock or Anthropic console access, persistent sessions across runs, CRON schedules, and memory that carries context between sessions. The audience is therefore platform or infrastructure engineers at a company that has already committed to more than one agent runtime, not an individual developer trying to get a first agent working. The project describes itself as sitting on top of any runtime, which is the honest framing: it does not replace the runtime, it registers it.

How the control plane sits on top of a runtime

The architecture visible in the repository is a Rust binary plus a compiled UI plus Postgres. Cargo.toml builds a single binary named lite from src/main.rs, and the Dockerfile's runtime stage copies that binary to /usr/local/bin/lite and the built frontend to /app/ui, then sets CMD to lite serve with PORT=4000. Dependencies point at the shape of the thing: axum for HTTP, sqlx with the postgres and migrate features for storage, jsonwebtoken and hmac for auth, and crypto_secretbox for encrypting stored secrets. Runtime registration is the interesting part. compose.yaml defines a reusable x-runtime-registration block that runs a curl container, waits for both the control plane's /health endpoint and the runtime's own /health endpoint, then POSTs a JSON payload to /api/runtime-harnesses with fields alias, api_spec, api_base and api_key, falling back to a PUT against /api/runtime-harnesses/$RUNTIME_ALIAS if the create fails. That fallback is effectively an upsert, which is why bringing a profile up twice does not error. The default RUNTIME_API_SPEC in that block is claude_managed_agents, so the harness record carries which API dialect the control plane should speak to the runtime behind the alias. Sessions and memory are not held by the runtime; they are rows in the litellm_agents Postgres database, which is what makes persistent sessions across runs possible when the runtime itself is stateless.

Installing LiteLLM Agent Control Plane with Docker Compose

The README states one prerequisite, Docker Desktop, and gives a single command to bring up the full stack with the OpenCode template runtime. The compose file starts the web/API service, a Postgres 16 container, the OpenCode template runtime, and registers the alias local-opencode in the UI automatically.

docker compose --profile opencode up

After the containers report healthy, open http://localhost:4000 and sign in with the master key. The README says the default is sk-local, and compose.yaml confirms it by defaulting LITELLM_MASTER_KEY to sk-local. If you only want the base stack without a template runtime, the README gives the plain form.

docker compose up

Additional runtimes come up through their own profiles, and the README shows that profiles can be combined in one invocation so several aliases register together.

docker compose --profile opencode --profile deepagents up

The README lists local-opencode, local-deepagents, local-hermes and local-openclaw as the aliases those profiles register through the LAP API once services are healthy. One caveat before you run an agent: the README says to add provider credentials in Settings before running agents against a hosted model provider, so a successful login is not the same as a working agent. Postgres is published on 127.0.0.1:15432 by default, bound to loopback rather than all interfaces, which is a sensible default for a local stack.

Where the control plane model breaks down

The central limitation is that the unified API is only as unified as the api_spec values the runtimes actually support. The compose block hardcodes RUNTIME_API_SPEC to claude_managed_agents for the template registration, which suggests the control plane translates between a canonical request shape and a per-runtime dialect. Any capability that exists in one runtime and not another cannot be exposed uniformly, and the README does not enumerate which features survive translation. The second limitation is operational. The repository shows no releases, and the README documents no upgrade path, no migration procedure and no rollback command. Cargo.toml pins the package at version 0.1.0, and sqlx is compiled with the migrate feature, so schema migrations exist inside the binary, but the README does not tell you how they are applied or reversed. Third, the last push to the default branch was on 2026-06-20. That is not abandoned, but it is also not a project where you should assume a fix lands the week you file it. Finally, this is the wrong tool for a solo developer running one runtime. You would be adding Postgres, a control plane process and a registration container to solve a problem you do not have.

LiteLLM Agent Control Plane compared with running runtimes directly

The obvious alternative is to skip the control plane and call each runtime's own API or CLI from your own scripts. That approach has real advantages: no Postgres to back up, no master key to distribute, no version coupling between the control plane and the runtime's API dialect, and no dependency on a project whose last push was 2026-06-20. What it does not give you is a single session store. If you want an agent started in OpenCode on Monday to carry context into a Deep Agents run on Wednesday, you either build that persistence yourself or you accept that the two runs are unrelated. The control plane's memory and session management exist precisely to move that state out of the runtime and into a database you control. The trade is straightforward: you accept an extra service, an extra schema and an extra failure domain in exchange for one place to create agents, one place to see sessions, and one place to manage who can run what. If your team's runtimes never share context, the direct approach wins on simplicity. If they do, the control plane is doing work you would otherwise write.

Licence, maintenance and what an upgrade actually costs

The project is MIT licensed, stated in both the README's repository metadata and the license field in Cargo.toml. MIT is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice are retained. That is a description of the licence text, not legal advice, and the repository does not include any additional terms, patent grant or contributor licence agreement in the files listed. On maintenance, the facts are narrow: the repository is not archived, and the last push to main was on 2026-06-20. There are no retrieved releases, so there is no changelog to read before upgrading. The practical upgrade cost is therefore unknown from the documentation. Because sqlx is compiled with the migrate feature and the Dockerfile copies deploy/render.config.yaml as the default LITELLM_CONFIG, an upgrade means a new binary, a new UI bundle and whatever migrations that binary applies on startup. The README does not describe how to take a backup first, so the safe reading is that you should back up the litellm_agents database yourself before pulling a new image, and that you should test the upgrade against a copy rather than your production Postgres.

Editorial conclusion

Adopt it if your team already runs two or more agent runtimes and the handoff between them is manual, or if you want developers to create and run agents without handing out Bedrock or Anthropic console access. Do not adopt it if you run a single runtime you are happy with, or if you need a published rollback path, because the README documents no release history and no upgrade procedure. Verify three things before committing: that the runtime you depend on is actually listed under Supported Agent Runtimes, that your provider credentials work through the Settings screen rather than a runtime's own console, and that your Postgres backup covers the litellm_agents database, since sessions and memory live there and the repository documents no export command.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. LiteLLM-Labs/litellm-agent-control-plane on GitHub
4. Project website
5. README