magpie: one screen for every coding agent's model

The whole interface is a list, and that is the design

The README describes the product in a sentence that reads like a constraint on purpose. `magpie` is a single screen that lists each AI agent on your machine and the model it is set to. Click a value, pick a model. That is the whole app.

The screen renders like this:

  ◉ magpie

  ▸ Claude Code   claude-fable-5-1[1m]                        ~/.claude/settings.json
    Codex         gpt-6-astra   effort medium
    Gemini CLI    gemini-3.1-pro
    OpenCode      anthropic/claude-sonnet-5   small anthropic/claude-haiku-4-5
    MiMo Code     anthropic/claude-sonnet-5
    Pi            openrouter/z-ai/glm-5.2:batch
    Goose         anthropic/claude-sonnet-5
    Cursor        auto
    Copilot CLI   claude-fable-5

  ↑↓ agent  ·  ←→ field  ·  ↵ change  ·  s save profile  ·  p profiles  ·  q quit

There is no dashboard, no usage chart, no prompt library, no agent runner. Each row is one agent, the indented column is the config file that decides its model, and the value is what that file currently says. OpenCode and Goose both showing `anthropic/claude-sonnet-5` is the kind of thing this screen exists to make visible.

The interaction model matches the simplicity. Up and down move between agents, left and right move between the fields within a row, enter changes a value, `s` saves a profile, `p` opens profiles, `q` quits. The README notes that only agents which are installed or configured are shown, so the list reflects your machine rather than a static catalogue.

It lives in the menu bar, so clicking the tray icon drops the panel down, and the same screen also opens as an ordinary window. There is a terminal version (`magpie tui`) and a plain CLI, which matters because a menu bar app is not an option on the headless machines where some of these agents actually run.

It edits config files in place, which is the part that has to be right

Every agent stores its model in a different file with a different syntax. Claude Code uses `~/.claude/settings.json`, Codex uses `~/.codex/config.toml`, Goose uses `~/.config/goose/config.yaml`, and OpenCode uses `opencode.json` or `opencode.jsonc` depending on whether you want comments. A tool that rewrites those files is either careful or destructive, and the README states which one this is: only the one key you change is touched, comments, ordering and indentation in your `settings.json`, `config.toml`, `opencode.jsonc` or `config.yaml` survive intact. Writes are atomic.

That claim is load-bearing, because people hand-edit these files. A settings file with comments and a particular key order is something a user built up over time, and a library that round-trips it through a generic JSON encoder destroys the parts it does not understand. Preserving them means parsing each format with a parser that models the format, which the dependency list supports: `pelletier/go-toml/v2` for the TOML files, `tidwall/jsonc` for the commented JSON, `gopkg.in/yaml.v3` for the YAML ones, and `tidwall/gjson` for locating a value without decoding the whole document.

Atomic writes are the other half. If the process is killed between truncating a config file and finishing the new content, you have destroyed the configuration for an agent that may hold credentials. Writing to a temporary file in the same directory and renaming is the standard answer, and it is worth noting that the README claims it rather than leaving it implied.

The four files named in that sentence are the ones with formats worth preserving. The JSON and YAML cases are unremarkable. The TOML case is not, because Codex's `config.toml` tends to carry comments that a naive rewrite drops, and the JSONC case matters because the comment syntax is not valid JSON and a strict parser rejects the file outright.

A local gateway that speaks three API shapes at once

The second half of the project is a proxy. The README describes magpie as running a local gateway that speaks OpenAI chat completions, OpenAI Responses and the Anthropic Messages API, and forwards to whichever vendor serves the model. Codex, Claude Code, OpenCode and the rest all point at `http://127.0.0.1:3425/v1` and pick from one catalogue, and the translation between APIs happens inside magpie, streaming and tool calls included.

The endpoint being a fixed loopback port is what makes the agents interchangeable. Each agent has one place it looks for a base URL, and magpie is that place, so the same model name resolves regardless of which agent asks. Models are spelled `provider/model` throughout, and agents never hold vendor keys or vendor URLs. Add a provider and its models appear in every agent's picker.

Three API shapes is a real translation problem, not a proxy to a single upstream. The Anthropic Messages API and OpenAI chat completions differ in how tools are declared, how streaming deltas are shaped, and how a system prompt is passed. Supporting Responses as well means handling a third. The README's phrase including streaming and tool calls is the load-bearing part, because an agent that cannot stream or cannot call a tool is broken rather than degraded.

The subscription sharing feature is the most interesting idea here, and also the one with the most obvious constraint. The README says you can sign in to Claude Code, Codex or Copilot and that login shows up as a provider, so every other agent can use its models through the gateway, with nothing copied and no key to paste. That works because magpie sits where the credentials already are on your machine. The same sentence is also the reason to think about what a gateway on your loopback interface is holding.

Model lists come from the vendors, not from the binary

A picker that ships a hardcoded model list is wrong within a week. magpie's answer is to ask. The README says that with a key in hand magpie asks the vendor which models it serves and offers exactly those, and that the models.dev catalogue fills in names, reasoning efforts and the list for vendors that have none, refreshing itself in the background once it goes stale.

That covers both cases. A major vendor has a models endpoint and answers authoritatively. A relay or a small provider might not, and models.dev supplies the metadata from the other direction. The background refresh matters because it is what lets the README claim that a model released this morning is in the picker on the next refresh.

You control the exposure rather than inheriting it. The README says you choose which models each provider exposes, or expose them all, which is the difference between a picker listing forty entries and a picker listing the three you actually use. Per-agent exposure also matters, since an agent with a small-model slot should not be offered the same catalog as one with a large-model slot.

Providers are described with one field each. Pick a preset and paste a key; custom vendors need a name and a base URL. The preset list is long enough to be worth reading as a market survey: Anthropic, OpenAI, Gemini, DeepSeek, Kimi, GLM, MiniMax, StepFun, Qwen, Tencent Cloud Token Plan, Mistral, Groq, xAI, OpenRouter, Together, Fireworks, SiliconFlow, AiHubMix, 302.AI, Ollama, LM Studio. Ollama and LM Studio at the end need no key at all, since they are local servers.

One security-relevant detail: the README states that magpie never reads keys from your shell environment. That is a deliberate choice rather than a limitation, and it cuts both ways. It means no API key leaks into a subprocess or a child process environment, and it also means magpie will not pick up a credential you exported for another tool without you pasting it into magpie.

Go 1.26, a Wails beta, and two build tags doing the work

The module declares `go 1.26.3` in go.mod, which places the project at the very front of the Go release line. The dependency list is small and tells you the shape of the thing: `wailsapp/wails/v3` at `v3.0.0-beta.24` for the desktop shell, `charmbracelet/bubbletea` with `bubbles` and `lipgloss` for the terminal UI, `modernc.org/sqlite` for a pure-Go SQLite with no cgo, `klauspost/compress` and `godbus/dbus` for the desktop integration, plus the four config parsers named earlier.

Depending on a Wails beta is a deliberate trade and worth naming. It is what lets the README say the desktop app is under 15 MB because it uses the system webview through Wails with nothing bundled, against 7 MB for the terminal-only build. The cost is that a beta can change its API, and the GUI is not the part of the project most likely to survive that unchanged.

The build tags explain the platform spread. The Makefile builds the GUI natively because it links the platform webview through cgo, while the `nogui` tag builds the terminal-only magpie which cross-compiles anywhere. On Linux the Makefile adds a `gtk3` tag, and the comment gives the reason: older distributions have GTK 3 and WebKitGTK 4.1, where Wails' default GTK 4 and WebKitGTK 6 would leave them out. On macOS the minimum is pinned with `-mmacosx-version-min=11.0` for both cgo flags.

TARGETS  = darwin/arm64 darwin/amd64 linux/amd64 linux/arm64 windows/amd64 windows/arm64

That line is the honest platform claim: three operating systems, two architectures each, no mobile targets, despite the menu bar framing. The macOS app target is worth noting as a detail. It builds a bundle with no Dock icon via `LSUIElement`, which is what makes a menu bar app behave like a menu bar app rather than something that bounces in the dock on every launch.

The source layout follows the CLI surface closely. Alongside `main.go` there are one-file-per-command files, `model_cli.go`, `providers_cli.go`, `sessions_cli.go`, `usage_cli.go`, `quota_cli.go`, `backup_cmd.go`, `webdav_cli.go`, `autostart_cli.go`, and a test file next to nearly each of them. Build tags split the GUI with `gui_on.go` and `gui_off.go`.

Twenty-six agents, and the config paths are the fragile part

The agents table is the real specification of this project, and it is longer than the idea of a model picker suggests. It runs from Claude Code and Claude Desktop through Codex, Gemini CLI, OpenCode, MiMo Code, Pi, Goose, Cursor CLI, Copilot CLI, Crush, DeepSeek Harness, Command Code, fx, omp, Devin, Hermes Agent, Cline, Qoder and Qoder CN, Grok Build, ZCode, WorkBuddy, OpenHanako and Alma. Several of those support more than one field, so Claude Code exposes provider plus model plus the opus, sonnet, haiku and fable slots, and Codex exposes provider, model and effort.

Reading the table also tells you how much of this is version-specific. ZCode is read from `~/.zcode/v2/config.json`, which encodes a major version in the path. Qoder and Qoder CN each need their own plan with bring-your-own-key. Claude Desktop is not a config file at all but a directory under `~/Library/Application Support`, with `%LOCALAPPDATA%` on Windows and `~/.config` on Linux, and changing its provider requires restarting the app. Alma and OpenHanako are reached through a local API while the agent itself runs, which is a different integration mechanism from the other twenty-four.

Several rows carry environment variable overrides in parentheses, `$DSH_HOME`, `$HERMES_HOME`, `$GROK_HOME`, `$HANA_HOME`, `$CLINE_DIR`, `$QODER_CONFIG_DIR`, `$WORKBUDDY_CONFIG_DIR`. That is the project being careful about people who relocate their config, and it is also a hint that paths move between versions often enough to be worth supporting.

The coverage is the value and the maintenance cost at the same time. Each row is a promise to keep tracking a file format that a separate project controls, and there is no compatibility guarantee in the README. Nine open issues against 1,540 stars and 93 forks suggests the queue is being worked, but a tool whose subject is other tools' config files will always be playing catch-up.

Scale, for reference: 1,540 stars, 93 forks, 9 open issues, MIT licensed in a file named LICENSE, default branch main, last push 2026-09-28. GitHub reports no published releases, so the version is derived from git describe at build time rather than from a tag you can pin. The topics are claude-code, codex, deepseek, gemini-cli, llm and macos.

Editorial conclusion

The problem magpie solves is administrative rather than technical, and it is the kind of friction that compounds daily. Every coding agent keeps its own model in its own config file, in its own format, and switching one to a cheaper model means finding and editing a different file. magpie turns that into a single list with a picker, and it does so without rewriting the files it touches, which is the detail that makes it safe to point at a config you also maintain by hand. Two things to weigh before adopting it. The gateway is a real piece of infrastructure sitting on your loopback interface at a fixed port, and it holds your provider credentials in whatever store it uses, so it belongs on a machine you trust. And the agent coverage is a snapshot: the table already lists agents with version-specific config paths like `~/.zcode/v2/config.json`, and those paths will drift as the agents change. The repository is young, with 1,540 stars, 93 forks, 9 open issues and no published releases at all, with the last push on 2026-09-28. Treat it as a well-built tool on an active branch rather than as a versioned dependency.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. yetone/magpie on GitHub