Magpie vs LiteLLM: pick the right gateway for your coding agents

Two gateways, one promise: stop editing config files every time a model changes. Magpie has 33,828 stars after seven weeks. LiteLLM has 63,054 after three years. The star counts say both are wanted. The designs say they are wanted for different jobs.

The question is not which gateway is better. It is which job you are hiring it for — and this tutorial answers it by installing both and routing the same agent, Claude Code, through each. If you only need the three-way agent comparison, see Claude Code vs Codex vs Gemini CLI.

The head-to-head

Read the table as a personality test. Magpie assumes you are one person with several agents and several accounts. LiteLLM assumes you are a system with several callers and one bill. Both assumptions are correct — for different readers.

What you’ll need

• Claude Code (or any agent that takes a base URL) — the guinea pig for both gateways.
• A provider API key (DeepSeek, OpenAI, Anthropic, or similar) or a Claude or ChatGPT subscription sign-in — Magpie accepts either; LiteLLM needs keys.
• Python 3.10 or newer for LiteLLM; macOS, Windows, or Linux for Magpie. No GPU anywhere — both gateways only route requests.
• About 20 minutes. Nothing here is deployed anywhere; both gateways run on localhost.

Step 1 — Install Magpie and add a provider

Magpie is a Go binary with a menu-bar app, a terminal UI, and a CLI; the installer picks the right one for your machine. On a desktop it installs the app; with no desktop it installs the terminal build and tells you which package to add.

curl -fsSL https://usemagpie.ai/install.sh | sh

Or, if you prefer to see exactly what you are getting: go install github.com/yetone/magpie@latest, or the Docker image linked from the project’s README. The installer is the path the project documents first, and it self-updates afterwards.

Open Magpie and go to Providers → Add provider. Pick a preset and paste a key — or sign in with a subscription. That second option is the whole pitch: a Claude, ChatGPT, Copilot, Gemini, or Grok plan you already pay for becomes a provider every other agent can use. Magpie finds the subscriptions your agents are signed in to by reading their sign-in files; turn that off in Settings → Privacy → Subscription accounts if you would rather it did not.

Step 2 — Route Claude Code through Magpie

One command moves Claude Code onto a model it was never sold with. The README’s own example runs Claude Code on DeepSeek — the same trick our hands-on Magpie tutorial uses to run Claude Code on Kimi:

magpie provider add deepseek sk-...              # a preset needs only the key
magpie claude deepseek/deepseek-v4-pro          # Claude Code on DeepSeek
magpie codex moonshot/kimi-k2.5                 # Codex on Kimi

Magpie rewrites the one key that matters in the agent’s own config, atomically, keeping its comments and formatting. Start a new session and the agent is on the new model. Check what is left on every plan:

magpie quota                                    # what's left on every plan

Anything else that takes a base URL can use the gateway too — the README documents the exports for a generic agent:

export OPENAI_BASE_URL=http://127.0.0.1:3425/v1
export ANTHROPIC_BASE_URL=http://127.0.0.1:3425

That is the test that matters: the gateway on 127.0.0.1:3425 speaks OpenAI Chat, OpenAI Responses, Anthropic Messages, and Gemini, translating between them with streaming, tool calls, and reasoning intact. If your agent talks one of those protocols, Magpie can sit in front of it.

Step 3 — Build a failover routing group

A quota running dry at 3 pm is the moment a gateway earns its keep. Magpie’s answer is a routing group: several models an agent picks as one, with five modes — smart, order, rotate, usage, and pace. Smart mode uses the subscription with quota left that renews soonest, so less is wasted at the reset.

magpie group add "Opus anywhere" models=claude/claude-opus-5-5,copilot/claude-opus-5.5 routing=smart
magpie claude group/opus-anywhere               # fails over between subscriptions

With one account and no group there is nothing to move to, and the error reaches the agent — the README says so plainly. The group is the feature; a single provider is just a redirect. Profiles save every agent’s setup under one name (magpie save work && magpie use work), so a “budget” afternoon is one command away from a “focus” one.

Step 4 — Install LiteLLM and write the proxy config

LiteLLM is the older, heavier answer. It is a Python proxy with a Rust core, and its install is one uv command — the same proxy our LiteLLM gateway tutorial stands up for apps:

uv tool install 'litellm[proxy]'

Where Magpie configures itself through an app, LiteLLM configures itself through a file. Write config.yaml with two models behind one endpoint, a fallback between them, and a master key read from the environment:

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY
  - model_name: claude-sonnet-4
    litellm_params:
      model: anthropic/claude-sonnet-4-20250514
      api_key: os.environ/ANTHROPIC_API_KEY
router_settings:
  fallbacks:
    - gpt-4o: ["claude-sonnet-4"]
general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

Two entries with the same model_name become one load-balanced group; fallbacks moves a request to the next group once retries are exhausted. The model IDs above are the ones LiteLLM’s own README uses in its examples. No key lives in the file — os.environ/ reads each one from the environment, which is the difference between a config you can commit and one you cannot.

Step 5 — Start the proxy and point Claude Code at it

export OPENAI_API_KEY="..."
export ANTHROPIC_API_KEY="..."
export LITELLM_MASTER_KEY="..."
litellm --config config.yaml

The proxy listens on port 4000. Smoke-test it the way LiteLLM’s README tests its own gateway — a plain curl at the OpenAI-compatible endpoint:

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "gpt-4o", "messages": [{"role": "user", "content": "What is 2+2?"}]}'

Now aim Claude Code at the proxy instead of at Anthropic. The pattern is the same base-URL trick Magpie documents, pointed at port 4000:

export ANTHROPIC_BASE_URL=http://localhost:4000
export ANTHROPIC_API_KEY=$LITELLM_MASTER_KEY

One detail to get right: LiteLLM matches requests on model_name, so the config needs an entry whose name matches the model your agent asks for. If Claude Code asks for a name your config does not have, the proxy answers with an error instead of a model — add the entry and restart. The proxy also serves the Anthropic Messages endpoint (/v1/messages), so agents speaking Anthropic’s protocol do not need translation tricks.

Step 6 — Compare and pick

Run the same job through both gateways — a small refactor, a test run, a quota check — and watch what you actually touch. With Magpie you touch a menu bar and a magpie command; the gateway is invisible until a quota dies, and then it quietly moves on. With LiteLLM you touch a YAML file and a dashboard; the gateway is visible all the time, and that visibility is the product.

Pick Magpie if your day is spent inside coding agents, you hold more than one subscription, and the pain is “my plan works in one agent and nowhere else.” It is the only contender here that treats a sign-in as a provider.

Pick LiteLLM if the gateway serves an app or a team, if anyone needs a budget or a per-team key, or if spend tracking is a requirement rather than a curiosity. Three years of production use and 63,054 stars buy a kind of boring reliability a seven-week-old project cannot claim yet.

Run both if the split is real: Magpie for your agents, LiteLLM for your apps. They listen on different ports, they never see each other, and each one is free to run locally. What you built is not a winner — it is a routing layer you control, with the model choice moved out of a dozen config files and into one place you can see.

The catch

Magpie is seven weeks old and it shows in the release cadence: v0.1.3625, v0.1.3626, and v0.1.3627 all shipped on November 10, 2026. That pace means bugs get fixed fast and behaviour can change under you; pin a version if you automate around it. Its subscription discovery reads your agents’ sign-in files, and its privacy masking — which swaps secrets for placeholders before a request leaves your machine — is off by default, so turn it on in Settings → Privacy before you route anything sensitive.

LiteLLM’s catch is the opposite: it never pretends a subscription is a key. Every model needs a provider API key, every behaviour lives in a YAML file, and the full feature set — Postgres, Redis, the admin UI — is a small piece of infrastructure to own, not an app to install. And neither gateway makes the models free: the bill still arrives from the provider, or from the subscription you already pay for. A gateway routes spend; it does not remove it.