Dieciséis mil estrellas en menos de cuatro semanas: magpie se creó en GitHub el 23 de septiembre de 2026 y el 19 de octubre ya sumaba 16.134 estrellas, 1.166 forks y 3.939 commits. El ritmo de publicación es igual de intenso: el 18 de octubre salieron tres versiones en menos de una hora, hasta la v0.1.1290.
Qué es: un gateway local que hace de traductor entre agentes
Quien trabaja con varios agentes de código conoce el problema: Claude Code, Codex, Gemini CLI u OpenCode guardan su modelo en un fichero propio, con su formato, sus claves y su URL base, y una suscripción pagada solo sirve en el agente de su fabricante. magpie pone todo eso detrás de una app de escritorio (barra de menú, ventana, TUI, web y CLI) y de un gateway local en 127.0.0.1:3425.
Ese gateway habla cuatro dialectos, OpenAI Chat, OpenAI Responses, Anthropic Messages y Gemini, y traduce entre ellos con streaming, llamadas a herramientas y razonamiento incluidos. Por eso puede ejecutar Claude Code contra un modelo de DeepSeek o Codex contra Kimi: magpie reescribe solo la clave que importa en la configuración de cada agente, de forma atómica y conservando comentarios y orden.
La pieza más interesante para operación son los grupos de enrutado. Un grupo es un conjunto de modelos que el agente ve como uno solo, y el gateway reparte las peticiones según el modo:
| Modo | Qué hace |
|---|---|
smart | Usa, de las suscripciones con cupo, la que se renueva antes |
order | El primer modelo hasta que falla, luego el siguiente |
rotate | Cambia de miembro en cada turno |
usage | Primero el miembro menos usado |
pace | La cuenta con más semana por delante por hora restante |
Una conversación se queda en la cuenta que la empezó mientras compense la caché de prompts del proveedor. Además lleva un panel de uso con tokens, coste a precio de lista, cupos de cada plan y exportación OTLP a tu propio stack de observabilidad. Está escrito en Go y tiene licencia MIT.
Cómo se usa
La vía rápida del README es curl -fsSL https://usemagpie.ai/install.sh | sh, es decir, ejecutar un script remoto sin revisarlo. Para un ingeniero hay dos alternativas más controlables: go install o la imagen Docker ghcr.io/yetone/magpie.
go install github.com/yetone/magpie@latest
magpie provider add deepseek sk-... # un preset solo pide la clave
magpie claude deepseek/deepseek-v4-pro # Claude Code sobre DeepSeek
magpie codex moonshot/kimi-k2.5 # Codex sobre Kimi
magpie quota # lo que queda de cada planCualquier herramienta que acepte una URL base puede usar el gateway apuntando OPENAI_BASE_URL, ANTHROPIC_BASE_URL o GOOGLE_GEMINI_BASE_URL a http://127.0.0.1:3425.
Lo que me convence y lo que no
Me convence que resuelve un problema real con una arquitectura sencilla: un único proceso local, sin servidor central, que entiende los cuatro protocolos que usan los agentes actuales. La documentación de referencia es exhaustiva, con los ficheros exactos que toca en cada agente, y el failover entre cuentas cubre el caso más frustrante del día a día: quedarse sin cupo a mitad de una tarea.
Lo que no me convence, y es lo que hay que leer antes de instalarlo:
- Lee tus credenciales. Para ofrecer tus suscripciones a otros agentes, magpie busca los inicios de sesión de Claude Code y Codex en sus ficheros y en el llavero del sistema. Se desactiva con
magpie accounts discovery offo, para una ejecución, conMAGPIE_NO_ACCOUNTS=1. - El loopback no pide clave. Según la referencia, en
127.0.0.1cualquier token vale, así que cualquier proceso de tu máquina puede gastar tus suscripciones a través del gateway. Las claves de gateway solo se exigen a peticiones remotas, cuando activas compartir en red local o lo expones conMAGPIE_ADDR. - Telemetría diaria activada por defecto: un id aleatorio, versión, sistema y qué agentes, proveedores y modelos usas. Se apaga con
DO_NOT_TRACK=1o en Ajustes → Privacidad. - Madurez. Más de 1.100 issues abiertos, versiones 0.1.x publicadas varias veces al día y un repositorio que no acepta pull requests externos: el feedback va por Discord.
La cautela que más pesa es otra: usar el plan de un fabricante desde el agente de otro depende de las condiciones de cada suscripción, y eso no lo resuelve ninguna herramienta.
magpie frente a LiteLLM
LiteLLM es la referencia open source para poner un gateway delante de muchos proveedores, pero parte de otro sitio.
| magpie | LiteLLM Proxy | |
|---|---|---|
| Enfoque | El puesto del desarrollador: conecta agentes de código y suscripciones | Gateway central para equipos y aplicaciones |
| Protocolos | OpenAI Chat y Responses, Anthropic Messages, Gemini | API compatible con OpenAI para más de 100 proveedores |
| Despliegue | App de escritorio, CLI, Docker | Servidor (uv tool install 'litellm[proxy]') o SDK de Python |
| Control de acceso | Claves de gateway solo para acceso remoto | Claves virtuales, control de gasto, guardrails |
| Licencia | MIT | MIT, salvo el directorio enterprise/ |
| Madurez | Repositorio de septiembre de 2026, versiones 0.1.x | Proyecto con años de recorrido (licencia de 2023) |
Cuándo usar cada uno. magpie tiene sentido en tu portátil si alternas varios agentes y varias cuentas y quieres cambiar de modelo sin editar ficheros a mano. Si lo que necesitas es que un equipo entero pase por un punto con claves por persona, presupuestos y auditoría, LiteLLM está pensado para eso y magpie no.