Sixteen thousand stars in under four weeks: magpie was created on GitHub on 23 September 2026 and by 19 October 2026 it had 16,134 stars, 1,166 forks and 3,939 commits. The release pace is just as intense: on 18 October 2026 three versions shipped in less than an hour, up to v0.1.1290.
What it is: a local gateway that translates between agents
If you work with several coding agents you know the problem: Claude Code, Codex, Gemini CLI and OpenCode each keep their model in their own file, with their own format, keys and base URL, and a paid subscription only works in its vendor's agent. magpie puts all of that behind a desktop app (menu bar, window, TUI, web UI and CLI) and a local gateway at 127.0.0.1:3425.
The gateway speaks four dialects, OpenAI Chat, OpenAI Responses, Anthropic Messages and Gemini, and translates between them, streaming, tool calls and reasoning included. That is how it runs Claude Code against a DeepSeek model or Codex against Kimi: magpie rewrites only the key that matters in each agent's config, atomically, keeping comments and ordering intact.
The most interesting part from an operations point of view is routing groups. A group is a set of models the agent sees as one, and the gateway spreads requests according to its mode:
| Mode | What it does |
|---|---|
smart | Of the subscriptions with quota left, use the one that renews soonest |
order | The first model until it fails, then the next |
rotate | Move to the next member on each turn |
usage | Least-used member first |
pace | The account with the most of its week left per remaining hour |
A conversation sticks to the account that started it while the vendor's prompt cache is worth keeping. There is also a usage view with tokens, cost at list price, quota for every plan and OTLP export to your own observability stack. It is written in Go and MIT-licensed.
How to use it
The README's quick path is curl -fsSL https://usemagpie.ai/install.sh | sh, which means running a remote script unreviewed. Engineers have two more controllable options: go install or the ghcr.io/yetone/magpie Docker image.
go install github.com/yetone/magpie@latest
magpie provider add deepseek sk-... # a preset only needs the key
magpie claude deepseek/deepseek-v4-pro # Claude Code on DeepSeek
magpie codex moonshot/kimi-k2.5 # Codex on Kimi
magpie quota # what's left on every planAnything that accepts a base URL can use the gateway by pointing OPENAI_BASE_URL, ANTHROPIC_BASE_URL or GOOGLE_GEMINI_BASE_URL at http://127.0.0.1:3425.
What I like and what I don't
I like that it solves a real problem with a simple architecture: a single local process, no central server, fluent in the four protocols current agents use. The reference docs are exhaustive, listing the exact files it touches for each agent, and failover between accounts covers the most frustrating everyday case: running out of quota halfway through a task.
What I don't like, and what you should read before installing it:
- It reads your credentials. To offer your subscriptions to other agents, magpie looks for Claude Code's and Codex's sign-ins in their files and in the system keychain. Turn it off with
magpie accounts discovery off, or for a single run withMAGPIE_NO_ACCOUNTS=1. - Loopback needs no key. According to the reference, any token works on
127.0.0.1, so any process on your machine can spend your subscriptions through the gateway. Gateway keys are only enforced for remote requests, once you enable LAN sharing or expose it withMAGPIE_ADDR. - Daily telemetry, on by default: a random id, version, OS and which agents, providers and models you use. Turn it off with
DO_NOT_TRACK=1or in Settings → Privacy. - Maturity. More than 1,100 open issues, 0.1.x versions shipped several times a day, and a repository that does not accept outside pull requests: feedback goes through Discord.
The biggest caveat is a different one: using one vendor's plan from another vendor's agent depends on the terms of each subscription, and no tool can settle that for you.
magpie vs LiteLLM
LiteLLM is the open source reference for putting one gateway in front of many providers, but it starts from a different place.
| magpie | LiteLLM Proxy | |
|---|---|---|
| Focus | The developer's machine: wiring coding agents and subscriptions | Central gateway for teams and applications |
| Protocols | OpenAI Chat and Responses, Anthropic Messages, Gemini | OpenAI-compatible API for 100+ providers |
| Deployment | Desktop app, CLI, Docker | Server (uv tool install 'litellm[proxy]') or Python SDK |
| Access control | Gateway keys for remote access only | Virtual keys, spend tracking, guardrails |
| License | MIT | MIT, except the enterprise/ directory |
| Maturity | Repository from September 2026, 0.1.x releases | Mature project (licensed since 2023) |
When to use which. magpie makes sense on your laptop if you juggle several agents and accounts and want to switch models without hand-editing config files. If you need a whole team to go through one point with per-person keys, budgets and auditing, that is what LiteLLM is built for, and magpie is not.