Can I use LiteLLM as a Ringlet provider?

Yes — that's a common setup. Add LiteLLM as a custom OpenAI-shaped provider in Ringlet, pointing at your LiteLLM proxy's URL. Ringlet handles agent + isolation + cost-tracking; LiteLLM handles model-routing on the other side.

Does Ringlet replicate LiteLLM's routing features?

Ringlet's optional ultrallm proxy covers basic per-request routing (tool-use, token count). LiteLLM is more mature for routing — budgets, retries, fallbacks, fine-grained rules. If you already run LiteLLM, point Ringlet at it.

compare · vs LiteLLM

Ringlet vs LiteLLM — different category, complementary tools

Side-by-side: Ringlet's agent CLI orchestrator vs LiteLLM's LLM gateway / proxy. They sit at different layers in the stack — most teams that need both can run them together rather than choose.

This is the comparison page we expected to be most controversial and ended up being the least. LiteLLM and Ringlet are different tools at different layers of the stack. They genuinely aren’t alternatives.

The shortest version: LiteLLM sits between an application and a model API. Ringlet sits between a developer and an agent CLI. Different layer, different problem, different audience.

This page exists because people search “Ringlet vs LiteLLM” enough that we should clearly answer “they’re complementary, here’s how.”

The two layers

┌──────────────────────────────────────────────────────┐
│  Developer (you)                                     │
│       ↓                                              │
│  ringlet profiles run work    ← Ringlet's layer      │
│       ↓                                              │
│  claude  (or codex, grok, ...) ← the agent CLI       │
│       ↓                                              │
│  HTTPS to provider            ← optional gateway     │
│       ↓                                              │
│  LiteLLM proxy / OpenRouter   ← LiteLLM's layer      │
│       ↓                                              │
│  Anthropic / OpenAI / etc.    ← the model API        │
└──────────────────────────────────────────────────────┘

Ringlet’s layer answers: “Which agent should run, with which credentials, against which provider URL, in which isolated HOME?”

LiteLLM’s layer answers: “When this HTTPS request to the LLM hits me, which actual provider should I route it to, with what budget, with what retries?”

You can absolutely run both: Ringlet launches Claude Code with ANTHROPIC_BASE_URL=http://your-litellm.internal/anthropic, and LiteLLM does the routing.

What LiteLLM does that Ringlet doesn’t

Unified OpenAI-style API in front of 100+ providers. Useful for application code that wants one API.
Production-grade routing rules. Budgets per virtual key, retries, fallback chains, model aliasing.
Multi-tenant key management. Each team / project gets a virtual key that maps to upstream credentials. Useful for organisations.
Spend dashboards across teams. A central place to see usage by virtual key.
Self-hostable as a service. Docker, Helm chart, Kubernetes operator.

What Ringlet does that LiteLLM doesn’t

Manages the agent CLI itself. Profiles, HOME isolation, agent-to-provider binding. LiteLLM doesn’t care which CLI is calling it; Ringlet’s whole point is the CLI.
Per-developer credential isolation in the OS keychain. LiteLLM holds credentials server-side; Ringlet holds them in the developer’s keychain.
Sandboxed agent exec. bwrap / sandbox-exec wrap for remote sessions. LiteLLM has no opinion on how the calling agent runs.
Hooks on agent lifecycle. Pre-tool-use, tool-use, stop. These are events on the agent, not the LLM call.
Remote terminal sessions. Browser-accessible PTY for running agents on a dev box. Completely outside LiteLLM’s scope.
Single binary install. No Python, no Docker, no daemon to operate (unless you want the web dashboard).

When to install which

You almost certainly want LiteLLM if:

You’re building an application (not running AI agent CLIs).
You need per-team budgets, audit, and multi-tenant key management at the LLM-call level.
You already run a Python/Docker stack and another service fits naturally.
You want a polished spend dashboard out of the box.

You almost certainly want Ringlet if:

You’re a developer (or a team of developers) running coding agent CLIs.
You need to isolate credentials and HOME across projects on your laptop.
You want cost tracking at the agent / developer / project level, not the API-call level.
You want a small Rust binary, not a service to operate.

If you want both:

Run LiteLLM as your organisation’s LLM gateway.

Add LiteLLM as a custom OpenAI-shaped (or Anthropic-shaped) provider in Ringlet:

# ~/.config/ringlet/providers/litellm.toml
name = "litellm"
shape = "openai"
endpoint = "https://litellm.yourco.com/v1"
key-env = "LITELLM_API_KEY"

Profiles bound to the litellm provider get LiteLLM’s routing, budgets, and central spend visibility — plus all of Ringlet’s per-developer isolation.

What we ended up doing

We don’t run LiteLLM at Neul Labs because we don’t have organisation-level LLM call governance to worry about. Each engineer manages their own profiles. If we grew to a size where central LLM-call governance mattered, LiteLLM is the tool we’d reach for, and we’d point Ringlet at it.

If you’re at that size already, install LiteLLM first and point Ringlet at it on day one. The two don’t fight; they slot together.

Honest things to know

LiteLLM has been actively developed for longer than Ringlet and is more mature for the routing / proxy / gateway shape of the problem. We have no plans to compete with LiteLLM’s routing surface; Ringlet’s optional ultrallm proxy is intentionally minimal.

Conversely, LiteLLM isn’t going to manage your ~/.claude directory or sandbox your remote PTY. Those are Ringlet’s job. The combination is genuinely the right setup for medium-sized teams.

Pick Ringlet if…

You're managing AI coding agent CLIs (Claude Code, Codex, …) and need profile isolation, credential management, and cost tracking at the agent level.
You want one tool to coordinate the agent's environment without running another service.
You want sandboxed remote sessions, event hooks, or a web dashboard for agent management.
You'd rather have a single Rust binary than a Python/Docker-deployed gateway.

Pick LiteLLM if…

You're building an application that calls an LLM API directly and need a routing/budget layer in front of multiple providers.
You want a unified OpenAI-style API in front of 100+ providers.
You have an organisation that needs per-team budgets, multi-tenant key management, and rich routing rules.
You're already running a Python or Docker-based stack and want a gateway that fits there.

FAQ

Can I use LiteLLM as a Ringlet provider?: Yes — that's a common setup. Add LiteLLM as a custom OpenAI-shaped provider in Ringlet, pointing at your LiteLLM proxy's URL. Ringlet handles agent + isolation + cost-tracking; LiteLLM handles model-routing on the other side.
Does Ringlet replicate LiteLLM's routing features?: Ringlet's optional ultrallm proxy covers basic per-request routing (tool-use, token count). LiteLLM is more mature for routing — budgets, retries, fallbacks, fine-grained rules. If you already run LiteLLM, point Ringlet at it.