A developer of an AI app asked how to work with magpie and whether an app can
register itself after one confirmation. The page says what exists: the
gateway (find it via /api/hello and settings.json's port, the OpenAI,
Anthropic, Responses and Gemini endpoints, /v1/models' fields), how a key
magpie-<id> or the User-Agent's first word names the app in Usage, a row on
the Agents page by an adapter PR in internal/agent (config-edit, Cindy-style
own import link confirmed in the app, or a local API) with what the PR needs,
what plugins can and can't do, and what isn't there: no link or API registers
an app or installs a plugin, and magpie://import adds providers only. English
and Chinese pages, linked from every docs page's nav and footer.
TestThirdPartyAppIsCountedAsItself pins the attribution the page promises.
go vet and the gateway tests pass; site node tests pass; pages checked in
headless Chromium (no errors, TOC, no horizontal scroll at 390px).
Max output and its hint and error, the purpose filter and the copy-launch-command button get their German, so gui-de's parity test passes again; the site's download-size line follows the English (a 15 MB download on a Mac).
* Add German translation and harden paths against unset env vars
Add a German locale to the GUI, tray menu, usage alerts and website home page, and refuse to start when the home folder is unset or relative so nothing is written under the working folder; the pi plugin no longer adopts the user's PI_CODING_AGENT_DIR, and an inherited APPIMAGE no longer selects portable mode. Scripts refuse to run from the wrong folder or empty a shared out folder, and a new internal/testenv sandboxes every test package from the user's real files, which also fixes the Claude picker and Termux installer tests on Windows.
* Makefile: know magpie's folder by its go.mod, so paths with spaces work
The check compared $(CURDIR) with $(dir $(abspath …)), which make splits on spaces, so a checkout under 'My Projects' or 'John Doe' refused every target. It now reads go.mod relative to the working folder and wants magpie's module there: make -C and a symlinked Makefile work, make -f from another folder still stops before any recipe runs.
* i18n: German for the strings main added since, with a parity test
75 strings main added (group order, patterns, slow-start wait, usage caps, RTK savings …) get their German, and two that main dropped go. gui-de.test.cjs checks, as gui-ja does, that de has every zh string with its placeholders and tags, and that the window reads in German when picked or on a German system.
* appdir: ignore relative folder variables when reading, keep them for children
CheckEnv no longer unsets anything. magpie reads the XDG folders, APPDATA/LOCALAPPDATA and every agent's folder variable through appdir.Getenv/LookupEnv, which pass over a relative value; the environment stays as it is, so the agents magpie starts get the variable as the user set it. That covers what proc.UserPath lends from the login shell too, which is set after main's check and reached the desktop app unchecked. On Windows a path rooted on the current drive (\Users\x, Git Bash's /c/x) counts as usable, and magpie version and help answer without a home, before run makes any folder.
* Sandbox the tests main added since
internal/wslrun gets testenv's TestMain, and four tests main added that set HOME alone set their home with testenv.SetHome, so on Windows they don't read the runner's profile through USERPROFILE.
* agentenv: PI_CONFIG_DIR and OPENCODE_DB take relative names on purpose
omp puts $PI_CONFIG_DIR under the home and OpenCode a relative $OPENCODE_DB in its data folder, so neither depends on the working folder: appdir no longer passes them over.
* i18n: German for the Library's multi-select and System One's decision API
The 19 strings main added since (#791's skill multi-select, the decision API snippets) get their German; the one main replaced (four APIs → five APIs) goes.
* appdir: tidy the import into magpie's group; say what Go makes of /c/x
The appdir import joins the group of magpie's own imports where a file has one. rooted's comment now says that Go takes a Git Bash path like /c/x as \c\x on the current drive, not C:\x.
* agent: AtomCode is wired like its own CodingPlan sign-in — one provider account, one model table per catalog model
AtomCode (atomgit.com/atomgit_atomcode/atomcode, AtomGit's open Rust terminal agent) keeps its settings in ~/.atomcode/config.toml ($ATOMCODE_HOME). Its account schema, what its own CodingPlan sign-in writes, is one [provider_accounts."magpie"] table at the gateway's /v1 (protocol openai, gateway.TokenFor("atomcode") as the key, so a request is its agent's even when the UA is overridden) and one [models."magpie/<provider>/<model>"] table per catalog model: the model string goes to the gateway as it is to resolve, with the model's context window (AtomCode compacts as it nears it; a 128000 one is told when the model's isn't known, and an output above the told window is cut to it), its output limit, vision and reasoning_effort_levels; reasoning_effort rides on the table once the user picks one. Picking a model points default_provider and default_model at it — default_model wins when both are set, as atomcode reads it — and stashes the defaults the user had; stepping out puts them back. The picker offers the user's own model tables and the catalog via magpie; the Library gives AtomCode its ATOMCODE.md, its mcp.json (omp's shape) and skills/; its UA is atomcode/<version>.
Found against a real atomcode 5.2.1: the documented legacy [providers.*] tables work, but its own sign-in writes the account schema, so magpie writes that; reasoning_effort, max_tokens and supports_vision were verified to reach the request from the model table, and default_model to win over default_provider. Verified end to end on a real install: atomcode --provider "magpie/…" answered through the gateway, and the Agents page shows the tile, its picker and the Usage attribution. TestAtomcodeWiring, TestAtomcodeRestoresOwnDefaults and TestAtomcodeSync fail on the old code; TestDriftUnwiredEveryAgent and TestUnsetAgentsReadEmpty cover it from All(). go vet, builds (darwin, GOOS=linux, GOOS=windows) and go test -tags nogui -count=1 ./internal/agent ./internal/library ./internal/agentenv pass; the plugin-host and timing failures of the full ./... run fail on main without this change too.
* tweak
* agent: AtomCode's config is matched by its own spellings, and Sync keeps the effort — AtomCode rewrites its config through serde on every /model and /cd, and that writes the account header bare ([provider_accounts.magpie]) where magpie wrote it quoted, so after the first rewrite Check read the wiring as gone, Sync and every pick appended a second account table (edited TOML is invalid: table magpie already exists) and clearing left the unquoted table and its api_key behind. The account is now matched by exact name in its three spellings (quoted, bare, literal — magpie-2 stays out) and the model tables by their decoded keys (kimiModelKey, replacing atomcodeModelName), through a new SetTOMLTablesMatching that takes exact names beside prefixes; SetTOMLTables delegates with none, unchanged. Sync carries each magpie model table's reasoning_effort over when rewriting — it ran at every gateway start and catalog change and dropped both an effort picked in magpie and one picked with AtomCode's /effort, and picking another model cleared every table's. The effort Set validates against the levels AtomCode knows (low, medium, high, xhigh, max — its clamp_effort_to_levels drops none, minimal and ultra), a model without levels offers none now, and the low/medium/high fallback is gone with it. supports_vision is written explicitly false, where AtomCode otherwise guesses from the model name. The user's legacy [providers.*] entries join the picker, a stashed default_model naming one comes back on Disconnect, and picking one sets default_provider and takes default_model out, as the legacy shape reads. site docs (en, zh, ja) list AtomCode. TestAtomcodeSync rewrites the config into the bare and single-quoted spellings before Sync and again before clearing and fails on the old code (drift reported, effort dropped, unquoted table left behind); TestAtomcodeLegacyProvidersArePickableAndRestored and TestAtomcodeEffortLevelsMatchAgentSupport are new. Reported by yetone on #736. go vet, builds (darwin, GOOS=linux, GOOS=windows) and go test -tags nogui -count=1 ./internal/agent ./internal/edit pass.
* agent: TestAtomcodeWiring picks an effort through the field too — the write side of the validation the last commit added (a level AtomCode knows lands as reasoning_effort on the model table, one it does not know is refused) had no coverage left: the test only read back what AtomCode's own /effort had written. provider.SetModelEfforts gives fake/m1 levels to offer.
* agent: Disconnect puts AtomCode's default_provider back only where AtomCode still has it — the restore checked the stash's value was not magpie's but not that the table it names was still there, so a table the user had deleted in between came back as a dangling default (the account schema's default_provider names a model table, the legacy shape a [providers.*] one; own answers for both). The default_model branch checked already. TestAtomcodeRestoresOwnDefaults deletes the stashed provider's model table before clearing and fails on the old code.
* agent: AtomCode joins the CLI updates — npm @atomgit.com/atomcode, the brew cask atomcode, and the curl script's ~/.local/bin/atomcode updating itself with atomcode upgrade, so the Agents page shows its version and a newer one as the other agents' do (#736). TestHowInstalled covers the npm prefix, the cask and the self-updating installer.
* agent: AtomCode's self-updater waits for its install paths to be confirmed — the branch recognized a binary under ~/.local/bin as `atomcode upgrade`, on a docs page, while the README shows another path and the command has not been driven outside the help text; the reviewer asked for it removed until the standalone command and the script's real default are settled. npm and the brew cask stay, with their tests; a comment marks what is pending.
---------
Co-authored-by: googya <118465+googya@users.noreply.github.com>
Before, the site's magpie shots in Omarchy mode came in two sets only, tokyo-night and catppuccin-latte, picked once by light or dark, so a page following rose-pine, gruvbox or white still showed tokyo-night's magpie, and a theme switch afterwards left the shots as they were. Every shot (agents, usage, add, import, routing, providers, panel, picker, intent trace/rules/hit, nested routing; en and zh) is now shot in each of Omarchy 4's 22 themes, in /img/omarchy/<theme>/<name>[-zh].webp. The shots are magpie's own GUI under each theme's /api/omarchy payload in the omarchy VM, same scenes and sizes as before. They are lossless WebP, pixel-identical to the PNGs, 29 MB for all 462 where the PNGs came to 77 MB. The 42 flat -dark/-light PNGs are removed; only omarchy.js used them.
omarchy.js's shots() runs on every paint, not once. It takes the theme's own set when it is one of Omarchy's, else catppuccin-latte or tokyo-night by the theme's mode. A shot already swapped loads the next one off-screen and swaps when it is in, so nothing goes blank meanwhile.
Checked in the VM's Chromium on the site served from this tree, magpie's theme answered as rose-pine, white, gruvbox, then a theme of the reader's own (light). On / and /docs/zh/intent every visible shot came from that theme's folder, loaded, at its own ratio, and none was blank during a switch. The custom theme took catppuccin-latte.
VS Code Stable takes other vendors' models through its Custom Endpoint provider since 1.122 (customoai, the older OpenAI Compatible one, is Insiders only), signed in to GitHub or not. The provider groups live in chatLanguageModels.json beside settings.json in the default profile's User folder (~/Library/Application Support/Code/User, ~/.config/Code/User, %APPDATA%\Code\User), a JSONC array VS Code watches. magpie adds {"vendor":"customendpoint","name":"magpie","apiType":"chat-completions","models":[...]} with each catalog model at the gateway's /v1/chat/completions, toolCalling true (agent mode lists only tool-calling models), vision, contextWindow and maxOutputTokens (capped at a quarter of the window, as VS Code keeps the output budget out of the prompt's), and the model's efforts as supportsReasoningEffort. A group's apiKey is a secret property that VS Code reads from its secret storage only (languageModels.ts _resolveConfiguration), so it can't be written to the file; each model instead sends Authorization: Bearer magpie in requestHeaders, which CustomEndpointOAIEndpoint lets through and which stops it sending its own key header. The model a new chat starts on is chat.defaultModel in settings.json (matched by model id, so the catalog id); its old value is stashed and put back. The group is the agent's Joined: picking one of VS Code's own (auto) keeps magpie's models listed, and switching off (Unwire) takes the group out and puts chat.defaultModel back. Sync rewrites the group as the catalog changes, Check says when its url or header no longer reach the gateway, the Notice says where the models are and to reload the window if they don't show, and requests are credited to it by GitHubCopilotChat/<version>, a User-Agent a model's headers can't change.
internal/edit: SetJSONItem/GetJSONItem/DelJSONItem edit one element of a JSONC file's top-level array, found by its members, keeping comments, trailing commas and the other elements; SetJSON/DelJSON take a backslash-escaped dot as part of a key, as gjson does, for VS Code's flat "chat.defaultModel".
TestVSCode (connect keeps the user's settings and groups with their comments, the group's url/header/toolCalling/window and no apiKey or discovery url, Sync, Check, an own model keeping the group, disconnect back to the user's last own model), TestVSCodeRoundTrip (on and off leaves both files byte for byte; no files at all) and TestVSCodeUA; TestJSONItem, TestDelJSONItemAmongOthers and TestJSONEscapedDot. go vet ./internal/..., go build -tags nogui ./..., GOOS=windows and GOOS=linux builds pass; go test of internal/agent, edit, usage and gateway (each sandboxes HOME in TestMain) and internal/gui's page and agent connect tests pass; the full go test under a temp HOME was not run (the sandbox refused the HOME override). No GUI code changed (the generic connected wording fits), so no webkit test. VS Code itself is not installed here: not tried against a real VS Code.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Morph has no list of providers to add magpie to, so magpie takes llm over:
inference_provider openai_response_compatible (the Responses API, morph's
own default), endpoint the gateway's /v1 (morph adds no second /v1), api_key
magpie's token, model the catalog id, context_window_tokens the window magpie
knows (morph knows one only from its own list), and headers.User-Agent
mistermorph so the gateway credits its requests to morph. llm.provider is
left alone: morph derives it from inference_provider. What the user had under
those keys is stashed and put back when they pick a model of their own or
reset; comments, other headers and other keys stay. An effort field sets
llm.reasoning_effort. Found by ~/.morph, not by the morph command (a common
name). Also on WSL. In NO_PICKER, as morph's /models switches profiles, not
models.
TestMorph and TestMorphContextWindow. go vet, builds (GOOS=linux/darwin
-tags nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp
HOME pass, but for TestPluginProxy, TestPluginSOCKSProxy and
TestCodexArchivedSameSizeRewriteInvalidatesDiscovery, which fail on main too.
With the installed morph against a sandbox gateway and a mock vendor, morph
run's requests went to /v1/responses, were relayed as chat completions and
were credited to morph; magpie morph default restored the user's file. Not
run against a real model.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* termux: build natively and run plugins on Bun 1.4.2
Select nogui for Android builds, open browser and OAuth links with
termux-open-url, and write an executable Termux:Boot script that starts
the gateway with shell-quoted paths.
Bun 1.3 has no official Android build. Upgrade the default plugin runtime
to 1.4.2, add the official Android arm64 and amd64 download targets, and
update SHA-256 checksums for every supported platform.
Document Termux installation, startup and source updates.
Validation on Termux arm64:
- Native build and go vet pass.
- A fresh config downloads and verifies Android Bun 1.4.2 and loads a
test plugin.
- Boot startup can be enabled and disabled.
- The Web page, authenticated state API, unauthenticated API rejection,
gateway healthcheck and Web quit action work.
- Browser argument preservation, boot path quoting and permissions, and
plugin tests pass.
Co-authored-by: Amp <amp@ampcode.com>
Amp-Thread-ID: https://ampcode.com/threads/T-01a10014-56c1-73d3-b3ee-2ea569713989
* site: install Android builds in Termux
Detect Termux through TERMUX_VERSION or its PREFIX and select the Android
CLI asset instead of a Linux binary. Install into PREFIX/bin by default,
keep MAGPIE_BIN_DIR overrides, and suggest the Web or terminal interface
without Linux desktop setup instructions.
When the release has no Android asset, explain how to build from source.
Add android/arm64 to release-cli and stop the build loop on failure.
Document the installer and its release-asset requirement.
Shell syntax and all 11 site tests pass, covering platform selection,
custom paths, missing assets, checksum rejection and existing Linux
installation paths. The Android arm64 release build succeeds on Termux;
with a simulated release feed, the installer verifies and installs that
binary into PREFIX/bin and the installed command runs successfully.
Amp-Thread-ID: https://ampcode.com/threads/T-01a10014-56c1-73d3-b3ee-2ea569713989
Co-authored-by: Amp <amp@ampcode.com>
* ci: check Android releases and the installer
Build both linux/amd64 and android/arm64 through make release-cli in the
CLI test matrix. Run the site and installer tests in the Linux job with
Node 22, and check the installer's shell syntax.
The release workflow in yetone/magpie-releases already calls the source
Makefile's release-cli target, uploads dist/magpie-cli-*, and generates
checksums for every artifact. The Android target added to TARGETS is
therefore included without changing that workflow.
Replace the full Termux README section with a short platform note beside
the Linux and Windows installation requirements, removing duplicate
commands, the fork URL and temporary release availability details.
Both CLI release builds, all 11 site tests, shell syntax checks and
actionlint validation pass locally.
Amp-Thread-ID: https://ampcode.com/threads/T-01a10014-56c1-73d3-b3ee-2ea569713989
Co-authored-by: Amp <amp@ampcode.com>
---------
Co-authored-by: Amp <amp@ampcode.com>
* routing: Least used puts first the account with the most of its week left per hour until it renews — it ranked by the share used alone, so with two subscriptions, one 80% through its week and renewing in an hour, the other fresh and renewing in five days, every new conversation went to the fresh one and the first's remaining 20% was lost at its reset. Allowance.Pace: over the windows that count the model and run a day or longer (the five hours are a rate cap, not a budget; Kiro's month counts), (100 − used) / hours to reset — a week not started or not known runs its whole span from now, one whose reset has passed is full again, of several (Opus's own beside the general) the tightest; an account whose vendor tells the five hours alone (Claude's own usage command) counts as a week not started with their share used, so those go by what they have used, as they did. weigh's LeastUsed case: one at 98% or more last whatever its week, by how far; then pace, highest first, in bands alike within a tenth drawn from the top before sorting (a pairwise tenth isn't an order: three paces a twelfth apart go round in a circle); within a band the tokens sent lately, then their order, for the cache; an account not known counts as a fresh week (before, "used 0" put it first), a key follows the subscriptions. Renewing the same hour, pace is most-left-first, as before. Smart untouched. The trace carries pace; the Routing tab's story, the provider and group editors' hints and the docs' routing table (en, zh) say what the option goes by now. TestAllowancePace, TestLeastUsedPace (fails on the old weigh: "imminent renewal first: ab"). go vet ./internal/..., go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./internal/provider/ ./internal/gui/ pass; ./internal/gateway/ passes but TestPluginModelListThroughAccountProxy, which fails on main too (a concurrent Body.Read panic in its fixture).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* routing: weekly pace is its own option, "pace"; Least used keeps its meaning (yetone, #517 review) — a user who had picked Least used was being switched to another strategy under the same name. Weekly pace: the account with the most of its week left per hour until it renews goes first, the one with the most to lose at its reset; Least used is most-left-first again, Smart untouched; the CLI takes routing=pace (weekly-pace), the TUI cycles to it, the group and provider editors, the Routing tab, README and the docs' routing tables (en, zh) list it. Review points: the tiers are Smart's — one at 90% or more of any window that counts the model, the five hours too, waits behind the healthy ones, by share, one all but used up behind those (an account 95% through its five hours with a healthy week ranked ahead of a fresh one until 98%, and the allowance is read about once a minute, so it was sent into 429s); among the healthy, one not known that tells what it has left as it answers (a Claude account) goes first while it isn't known, as in Smart, else it would never answer and never be known; a window that says no span (a plugin may not) is a budget for as long as its reset says, else a week, where it fell among the five hours and made the week not started; the hours until a reset are never fewer than one, or a window thirty seconds from renewing paced at 6000; the trace carries due, the reset of the window the pace went by, and the Routing tab's story says the week's share left over the hours until that, not the first reset it finds; Routing's comment in provider.go and README's routing= line name the option. The bands of pace alike are drawn among the healthy known accounts alone: one running low would otherwise set a band's top and part two alike behind it. TestWeeklyPace (the tiers and their 90% edge, the probe and its end, the bands drawn without the low, keys by tokens and after subscriptions, the trace's pace and due, Least used unchanged), TestAllowancePace (due, the span-less budget at 48 h and at 90 min, a day the shortest budget, the hour floor, normalize keeps pace). go vet ./internal/... ., go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./internal/provider/ ./internal/gui/ ./internal/tui/ . pass, the two new tests 25 times over; ./internal/gateway/ passes but TestPluginModelListThroughAccountProxy, which fails on main too.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
* providers: qianfan personal, team and pay-as-you-go endpoints as its preset regions
* providers: qianfan review fixes — pay-as-you-go fetches /v2/models, enterprise naming, the plans' union models, a zh note
* providers: qianfan plans list nothing, pay as you go does — NoList scoped by region
* providers: qianfan review round two — old id maps to the new preset, the union models, IAM keys and a README section
* providers: qianfan key link follows the region — normalize takes it from the endpoints, the button from the plan picked
* providers: ParseImport takes a region key page
yetone