pi-magpie

One gateway, every provider — and it just works.

magpie's gateway as a pi provider. Install the extension, and pi talks to the magpie running on your machine — no login, no endpoint to type, no key to paste. magpie listens on a loopback address with a default port, so the extension finds it on its own.

magpie is one local endpoint in front of every model provider you have. It keeps one live model list, one quota view, and one routing engine that picks which account answers each request. This extension makes pi a first-class client of it.

Zero setup

magpie's own defaults are the extension's defaults. With nothing configured, it reaches http://127.0.0.1:3425 with the key magpie — the endpoint magpie listens on out of the box. Install, and your magpie models are there.

pi install npm:pi-magpie     # then open pi and pick a magpie model

If magpie isn't running, the catalog is simply empty — no errors, no setup wizard. Start magpie and /magpie refresh.

A gateway somewhere else (a LAN box, a shared key) is the only thing that needs a step: /login magpie asks for its endpoint and API key, and $MAGPIE_GW_URL / $MAGPIE_ADDR set the default when you'd rather not store one.

What it does

• The model list is magpie's, live. Every refresh reads GET /v1/models and installs exactly what magpie serves right now — routing groups, subscriptions, accounts and providers appear and disappear with magpie, instead of being frozen into a models.json that goes stale.
• Each model is asked on the protocol its provider speaks natively. A Responses model goes to the Responses API, a Claude to Anthropic Messages, everything else over Chat Completions — magpie relays instead of translating.
• Reasoning levels come from the model. supported_reasoning_levels becomes pi's level list: levels the model has are offered, the rest hidden. A Claude from 4.6 on is marked adaptive, so pi asks for adaptive thinking instead of a budget it would refuse.
• The footer tells you what's actually serving you. On a model, its tightest quota window (magpie 14% left · reset 3d); on a routing group, the strategy and the provider that answered last (smart → opencode-go). It follows the terminal's width and repaints on resize.
• No protocol code. Requests are handed to pi-ai's built-in openai-completions, openai-responses and anthropic-messages implementations, so message conversion, tool calls, usage accounting, cancellation and instrumentation behave exactly as they do for a built-in provider.

The footer

For a model, the tightest quota window magpie reports for that provider, cut to fit when the terminal is narrow (40 columns are always left for other extensions' statuses):

magpie 14% left · reset 3d        mag 14% · 3d

For a routing group, the routing strategy and who answered last — the provider alone while every member is one model (the model carries no news), provider and model when the members differ. A provider id over 8 characters is cut in the middle:

magpie smart → opencode-go
magpie order → ant..ity/gemini-3.8-flash

Leaving magpie for another provider clears the line.

Commands

Every one completes on Tab: the subcommands while the first word is typed, then the ids the subcommand takes — every model for quota, every routing group for group, ranked by a fuzzy match that puts a prefix or a contiguous hit first.

/magpie on its own is the overview: the endpoint and whether it's the default or a stored one, how many models and groups the catalog holds, and the current model's own reading — its tightest quota window, or its group's rule and last answered member.

Where the readings come from

The two readings magpie tells only this machine — quotas and the routing history — are skipped for a remote endpoint; the model list and the requests themselves work either way. The history is read from its tail, and the last decision is looked up per group in one pass, so a footer refresh doesn't re-read a day's file.

The models.json warning

magpie writes a providers.magpie block into ~/.pi/agent/models.json whenever one of its models is picked for pi in magpie's own UI. That block sets one baseUrl for every model of the provider — which would point an Anthropic model at /v1/v1/messages — and pi prefers its frozen models list over this extension's live catalog. Requests still work (the endpoint is stamped per request), but the model list and native paths don't. Set pi's model to default in magpie (which removes the block), or delete it by hand. The extension reports the conflict once at startup.

Notes & limits

• Every model reports cost 0: magpie's catalog carries no prices. The footer cost of a magpie session isn't meaningful; usage tokens are.
• A routing group is a normal model id (group/<id>) — magpie does the routing, and pi sees one model.
• MAGPIE_BIN points the group readings at another magpie binary; without the CLI, a group still shows its id, its members from the catalog, and its last request from the routing history.
• Quotas and the routing history are loopback-only, so a remote gateway shows the model list and routes requests but reports neither.

Install

pi install npm:pi-magpie

From a local checkout (development): pi install ./pi-magpie.

Requires Node ≥ 22.6 and pi ≥ 0.80. See CHANGELOG.md for the version history.