Magpie: A Local Gateway to Unify All AI Coding Agents

Developers pay for multiple AI coding assistants every month, yet often find unused subscriptions when one quota runs out. An open-source project called Magpie aims to solve this: it runs a lightweight gateway on your machine that routes all agent requests to different models or subscriptions. Less than a month after launch, the project has surpassed 17,000 GitHub stars.

Why a Unified Gateway Is Needed

According to a demo by the YouTube channel MasaTech, most developers' AI coding environments today are fragmented: Claude Code can only connect to Anthropic, Codex can only connect to OpenAI, and each agent maintains its own config files, keys, and Base URLs.

MasaTech uses an airport analogy for this state—every plane has its own runway, and when a runway closes, the plane can only circle and wait. Magpie is like a unified control tower: all agents communicate with the tower first, and the tower decides which runway each request lands on.

This gateway runs on local port 3425 and supports a long list of agents including Claude Code, Codex, Gemini CLI, OpenCode, Cursor CLI, and Klein.

The Full Path of a Request

MasaTech traces the entire process from a request leaving the editor to the answer returning, using a dental clinic appointment app as the development scenario.

Config rewriting: After selecting a model for Codex on Magpie's agent page, Magpie rewrites only one key in Codex's config file, preserving all comments, ordering, and formatting. Codex doesn't know Magpie exists and sends requests to the local gateway as usual.

Protocol translation: Codex uses OpenAI's message format, but if you want a Claude model to answer, the request must be converted to Anthropic's format; Gemini uses yet another format. The gateway translates in flight, including streaming output, tool calls, and reasoning content. This is exactly why Claude Code can run on Kimi and Codex can run on DeepSeek^Ad.

Routing selection: In Magpie, a model set that an agent sees as a single model is called a routing group. In sequential mode, the first model is used, and if it can't respond, the next is tried. In rotation mode, each round switches to the next member. Smart mode picks the subscription that still has quota and resets earliest, reducing plan waste.

Intent routing: An optional small model reads each new request first. Write tests go to a strong model, simple questions go to a cheap one, avoiding paying top-tier prices to ask what a function is called.

Switching when quota runs out: When Claude's quota runs out during Central Time, the routing group switches to the next account or model, and Codex is completely unaware of the error. As long as the vendor's prompt cache is still valuable, the conversation stays on the account that answered it.

Usage dashboard: The usage page shows tokens per request, cache hits, and cost at list price. Running magpie quota in the terminal shows the remaining amount for each key and plan, and alerts you when a quota window is about to reset with low usage.

Prompt Caching is an optimization mechanism offered by vendors such as Anthropic and OpenAI: when the prefix of a request (system prompt, tool definitions, conversation history) heavily overlaps with a previous request, the vendor can reuse the already-computed KV cache and skip redundant prefill computation, significantly reducing latency and cost (cached input tokens are typically billed at 10%–25% of the original price). Cache validity generally ranges from a few minutes to several hours and is bound to a specific account. So when the gateway switches accounts due to exhausted quota, the new account lacks the old account's cache, and first-round token costs rise; this is the direct motivation for the strategy in this article—"as long as the vendor's prompt cache is still valuable, the conversation stays on the account that answered it"—switching is a cost trade-off, not unconditional fault tolerance.

Difference from OpenRouter

Magpie and OpenRouter are not the same kind of product. OpenRouter is a cloud service that sells model access, while Magpie runs on your own machine—and OpenRouter can actually be connected as one of its upstream providers.

Upstream Provider refers to an external service to which the gateway delegates requests in the forwarding chain. Magpie itself does not sell model access; it only does local scheduling. So when there is no available local key or quota, you can configure OpenRouter, a vendor's official API, or even another self-built gateway as an upstream to handle final authentication and billing. This layering lets Magpie hold multiple non-interfering credential sources at once, and lets users freely combine "subscription accounts," "own API keys," and "third-party aggregation services" based on compliance and cost—without changing any agent client's configuration.

The Setting You Must Turn Off Before Use

MasaTech particularly emphasizes one setting. To discover plans you've already paid for, Magpie reads agents' login information, such as Claude Code and Codex files and the system keychain.

If you don't want this, turn off subscription accounts in Settings → Privacy. The reason is that using subscriptions outside their own apps is not always permitted—Claude Code's documentation states this explicitly.

MasaTech's advice: have routing groups prefer API keys, or providers that explicitly allow third-party tool access. Magpie also sends anonymous usage statistics once a day, which can likewise be turned off in the privacy menu.

Risks of an Early-Stage Project

The project is only a few weeks old, ships updates almost daily, and does not accept Pull Requests. MasaTech's advice is to test daily and validate on side projects first before letting it touch client-paid work.

Whether the project can be maintained long-term and whether its routing strategies are robust enough still need time to prove. But the problem it raises is real: when paying for multiple AI subscriptions in parallel, a local scheduling layer can indeed reduce idle waste.

Key Takeaways

• Magpie is a locally running AI agent gateway that unifies request scheduling for tools like Claude Code, Codex, and Gemini CLI.
• It supports protocol translation, routing groups, intent routing, and automatic switching when quota runs out, reducing idle time across multiple subscriptions.
• Before using subscription accounts, turn off subscription reading in privacy settings and prefer API keys to avoid terms-of-service risks.
• The project is early-stage, updates frequently, and does not accept PRs; test on side projects first.

Background Notes

Base URL is a field in the configuration of OpenAI-compatible clients (Codex, Cursor CLI, OpenCode, etc.) that specifies which domain API requests are actually sent to. The default points to the vendor's official endpoint (e.g., https://api.openai.com/v1); changing it to http://localhost:3425/v1 makes the client hand traffic to the local gateway. Because these tools mostly follow OpenAI's /chat/completions or /responses interface conventions, as long as the gateway reproduces the same paths and methods locally, clients need no code changes and need not be aware of the middle layer—this is the technical premise that lets Magpie achieve "Codex doesn't know Magpie exists."