Magpie Gives Every Coding Agent Any Model, and Reads Your Sign-Ins to Do It
A switchboard for Claude Code, Codex and Gemini CLI is really a credential broker. Here is how to run it on your terms.
Every coding agent ships married to its maker's models. Claude Code wants Claude, Codex wants OpenAI, Gemini CLI wants Gemini. Developers who pay for two or three of those subscriptions end up juggling config files, environment variables and quota warnings across tools that refuse to share.
So a new category of tool is climbing GitHub: the agent gateway, a local program that sits between your agents and the model providers and lets any agent use any model. On Trendshift's daily momentum board at about 3 PM ET on October 14, two of them sat in the top 25: free-claude-code at #9 and yetone/magpie at #23.
Magpie is the smaller of the two, at about 13,000 stars against free-claude-code's 61,000, and the one whose README says the most about what it touches. Its pitch is one line: "Every agent's model. One place." The part of the pitch nobody prints on the box is what a gateway like this has to hold to do its job.
What Magpie does
Magpie is a menu-bar app and command-line tool for macOS, Windows and Linux (plus Docker, and Termux, the Android terminal app) that runs a model gateway on your own machine. Every agent you point at it talks to 127.0.0.1:3425 instead of a vendor's API. The gateway understands four request formats, the different shapes each vendor's API expects (OpenAI Chat, OpenAI Responses, Anthropic Messages and Gemini), and translates between them, so Claude Code can send an Anthropic-style request and get an answer from a Gemini or DeepSeek model without knowing the difference.
It sets this up by editing your agents' own config files. The reference doc lists them: ~/.claude/settings.json for Claude Code, ~/.codex/config.toml for Codex, ~/.gemini/settings.json and ~/.gemini/.env for Gemini CLI. The README says it "edits the one key that matters in the agent's own config," and that the rewrite keeps comments, order and formatting.
Then it adds the features that make people install it:
- Failover. When a quota runs out, Magpie moves to the next account or model, and in the README's words, "the agent never sees the error."
- Routing groups. A handful of modes (
smart,rotateand others) decide which account or model handles each request. Intent routing, which picks a model by what you are asking for, can send test-writing to a strong model and quick questions to a cheap one. - Subscriptions as providers. Beyond API keys, it can route through Claude, ChatGPT (Codex), GitHub Copilot, Gemini Code Assist, Antigravity and SuperGrok sign-ins.
- Plugins and middleware. Plugins add providers. Middleware, small pieces of code that sit in the path of every request, can read and change requests and replies on the way through.
Run three agents, pay for three subscriptions, and Magpie turns that mess into one menu. It is easy to see why it is trending.
The shift: a gateway is a credential broker
Here is the way to think about any tool in this category.
A gateway that can route every agent to every account has to be able to reach every account. It sits in the middle of all your agent traffic: your prompts, your code and the model's replies. Depending on the provider, it either stores the key, holds a copy of a sign-in, or drives the original agent's own login. Either way, that makes it a credential broker, a single program trusted with access to every provider you turn on. Whatever its quality, it is now the most sensitive process on your laptop after your password manager.
Magpie's README is unusually honest about this, which is to its credit. You just have to read past the feature list to find it.
It reads your agents' sign-ins by default. The README says Magpie "finds the subscriptions your agents are signed in to by reading their sign-ins," and names Claude Code's and Codex's files and the macOS Keychain as sources. This is how the subscription feature works without you pasting anything. It is also a program reaching into the credential stores of other programs.
It sends a daily usage ping by default. Once a day a released build sends "a random id, its version and system," plus which agents, providers and models you use, by Magpie's own ids, along with counts of partner impressions. The README adds: "No names, URLs, accounts, keys, prompts or usage." It also says the usemagpie.ai server counts partner link clicks and list fetches regardless of your settings.
Plugins run third-party code on your traffic. Plugins can come from npm ("Any OpenCode auth plugin or pi package from npm") and "run on Bun" (a JavaScript runtime), "downloaded the first time one needs it." Middleware can read and change requests and replies. Installing one is installing a stranger's code into the one process that sees everything.
It changes often, and it updates itself. The README says "every build updates itself." The release feed shows nine versions on October 14 alone, v0.1.1233 through v0.1.1241. Whatever you reviewed at breakfast is not what is running by dinner.
None of this makes Magpie malicious. Each behavior has a reason, and each is documented. It does mean the default install trusts the tool with far more than "pick a model."
Silent failover cuts both ways
The feature people love most deserves a second look.
"The agent never sees the error" is great when a quota runs out during a long refactor. It also means the model doing the work can change mid-task without anyone telling the agent or you. If your smart routing group falls from a strong model to a cheap one at step 60, the code after step 60 came from a different model, and nothing in the agent's output says so.
For exploratory work, that tradeoff is fine. For anything you will merge without reading line by line, you want to know which model wrote it. Keeping a routing group to a single account until you trust it makes any fallback impossible to miss.
There is also a question the README cannot answer for you. Routing a consumer subscription through a third-party gateway is a matter for that provider's terms of service. Read them for the plans you pay for before you wire them in.
Put this into practice
The goal is to get the switchboard without handing over the whole building on day one.
1. Snapshot your agent settings first. Magpie has profiles that "Snapshot every agent's settings under a name and switch all of them back in one move." Make one before you change anything. Copy the raw files too, since the README does not describe a general undo:
mkdir -p ~/agent-config-backup
cp ~/.claude/settings.json ~/.codex/config.toml ~/agent-config-backup/ 2>/dev/null
cp ~/.gemini/settings.json ~/agent-config-backup/gemini-settings.json 2>/dev/null
2. Install. The README offers a script, a Go install, the app download at usemagpie.ai and a Docker image:
go install github.com/yetone/magpie@latest
Building from source lets you read what you are running, and it has a bonus: the code's own comment says "a build from source never sends" the daily usage ping (stats.go at v0.1.1241). The curl -fsSL https://usemagpie.ai/install.sh | sh script works too, but piping a script from the internet into your shell is the same trust decision as everything above.
3. Start with discovery and telemetry off. The README gives both switches:
magpie accounts discovery off
export DO_NOT_TRACK=1
MAGPIE_NO_ACCOUNTS=1 turns sign-in discovery off for one run without changing the saved setting. "API-key providers work either way," so nothing breaks.
4. Add one API-key provider and one agent. Point a single agent at the gateway, using the README's base-URL pattern:
export ANTHROPIC_BASE_URL=http://127.0.0.1:3425 ANTHROPIC_API_KEY=magpie
What to expect: the agent works as before, but its requests now show up in Magpie's Requests view, and you can switch its model from the menu. Run a real task and compare the output to what you get on the vendor's model.
Then check what Magpie changed on disk. After you pick a model for an agent in the menu, compare its config file with your backup:
diff ~/agent-config-backup/settings.json ~/.claude/settings.json
If the README's promise holds, you should see one changed key and nothing else. If you see more, you have learned something about the tool before it held any of your sign-ins, which is the cheapest time to learn it. To back out, copy your saved files back into place.
5. Leave network sharing off. The reference doc says sharing "listens on every interface," and that when the gateway is neither shared nor on the network, "a remote request is refused (403)." If you do share it, give each client its own gateway key with a token and cost limit, which the README supports.
6. Skip plugins until you need one, then read its source. Treat a Magpie plugin like a browser extension with access to every page.
Turn sign-in discovery back on only after a week of this, and only for the accounts you actually want routed.
Honest limitations
The undo story is thin. Magpie promises all-or-nothing edits that touch one key, and profiles help, but the README does not describe a single "restore everything" command. Your own backup is the real safety net.
It is MIT-licensed, but the maintainers do not accept outside pull requests. The README says "This repository doesn't take pull requests" and asks for fixes on Discord. You can fork it; you cannot easily fix it upstream.
The README carries a sponsor link (APINEBULA) and the gateway counts partner impressions, so the project has a commercial interest in which providers you see. That is normal for free tools. It is worth knowing.
The pace is a risk of its own. Nine releases in a day means fast fixes, and it also means a tool with access to your credentials changes faster than anyone can review it. If that bothers you, the Docker image or a pinned source build is easier to hold still than the self-updating app.
And none of this is unique to Magpie. Free-claude-code and every other gateway in this category sit in the same seat. Magpie just documents it better than most.
Your move
Before installing any agent gateway, answer three questions from its README: what credentials does it read, what does it send home, and what code can run inside it. If the README cannot answer, that is your answer.
Magpie can answer all three. So the question is not whether to trust it. It is how much, starting when, and with which accounts.
Sources: yetone/magpie README and docs/reference.md and internal/stats/stats.go at v0.1.1241; magpie releases; Trendshift daily board, read about 15:08 ET on October 14, 2026; star count from shields.io, October 14, 2026.
Medium metadata
Title: Magpie Gives Every Coding Agent Any Model, and Reads Your Sign-Ins to Do It
Alternates to test:
- You Don't Have to Pick One AI Coding Agent's Models Anymore. Read This First.
- Coding Agents Aren't Tied to Their Makers' Models Anymore
- Magpie Turns Your Coding Agents Into One Switchboard. Here's What It Holds.
Subtitle options:
- A switchboard for Claude Code, Codex and Gemini CLI is really a credential broker. Here is how to run it on your terms. (picked)
- The trending gateway that routes any agent to any model, and the four defaults to change before you trust it
- One menu for every coding agent's model, and every account behind it
Description: Magpie lets Claude Code, Codex and Gemini CLI use any model. It also reads your sign-ins by default. Here's how to adopt it safely.
Tags:
- AI Agents: core audience
- Claude Code: the most-searched agent the tool supports
- Cybersecurity: the credential-broker angle is the article's insight
- Open Source: a trending GitHub repo
- Developer Tools: broad reach to working developers
Article type and publish plan: Type A (a real, trending repo with a clear payoff and a practical setup). Post at 7 to 8 AM ET, let Medium distribute for 2 to 6 hours, and send to subscribers only if it is performing.