magpie

agent

agent: Pi asks a Responses-native model on Responses (Leo: 同协议优先) — every magpie model in Pi's models.json went out as openai-completions, so a ChatGPT sign-in's models, a Responses-only provider's, and GPT on OpenAI's API or Copilot's were asked on Chat and translated to Responses by the gateway. Now each such model carries "api": "openai-responses" (Pi takes a model's own api over its provider's, and posts it to baseUrl/responses), so the gateway relays what Pi sent as it is: reasoning effort and summary, its encrypted reasoning, images, tools, prompt_cache_key; a ChatGPT sign-in's still made into Codex CLI's request. Which API is a model's is provider.Native — what the provider serves it on itself, Responses first for an OpenAI model where the gateway already put it first (ResponsesFirst, moved from the gateway). Chat providers, groups, Cursor/Devin/Kiro/Claude Code sign-ins and Anthropic-API models stay on openai-completions: Pi's anthropic-messages picks thinking by the Claude ids it knows and asks a newer Claude for a thinking budget it refuses, which magpie's translation doesn't. Tested with Pi 0.73.1 and @earendil-works/pi-coding-agent 0.87.1 against a sandbox gateway and a fake Responses upstream: /v1/responses relayed with effort high, xhigh, none (thinking off); a Chat model still on /v1/chat/completions

2026-09-28 20:18:37 +08:00

autostart

autostart: on Windows, Open at login switched off in Task Manager's Startup apps reads as off, and switching it on in magpie switches it on there again

2026-09-27 12:53:16 +08:00

backup

agent: on Windows, Codex installed in a WSL distro is an agent of its own, codex@wsl:<distro> ("Codex · WSL Ubuntu") — the distros are listed with wsl.exe -l -q (UTF-16LE, or UTF-8 under WSL_UTF8), each asked once through proc for its $HOME, its ~/.codex, a codex on its PATH and its default route, and shown only where Codex is; its files are Codex's own reading and writing (codexIn, at a place rather than a home) through \\wsl.localhost\<distro> (\\wsl$ before that), with the catalog path written in as the distro spells it and what was there stashed under the distro's agent; the gateway written in is 127.0.0.1 when .wslconfig has networkingMode=mirrored and otherwise the Windows host by the distro's default route, with a notice that NAT needs the gateway beyond loopback and through Windows' firewall and that mirrored is the way; its requests stay counted as Codex's, and a profile key is split at its last dot for distro names like Ubuntu-24.04. Nothing runs off Windows. Kimi CLI isn't an agent magpie has yet, so there is no Kimi in WSL. Tested on a Windows box under NAT with a throwaway Alpine distro: detected (the real distros without Codex left out), a magpie model set and reset from the CLI and a test binary, the catalog read inside WSL at /root/.codex; mirrored networking tested only in unit tests

2026-09-28 17:22:30 +08:00

catalog

providers: the context window field offers its usual sizes under it, one click each — 128K, 200K, 256K, 1M — and, where models take more than they are said to, each one's own most: Codex's GPT-6 and GPT-5.6 are said to hold 272K and take 872K when asked, a size nobody remembers, so one chip sets it for every such model (#120 ). The most is read from max_context_window in the list ChatGPT gives and in Codex CLI's cache

2026-09-28 01:53:08 +08:00

claudebridge

gateway: a Grok subscription (SuperGrok, X Premium+) works like a Cursor one — magpie runs the signed-in Grok Build CLI in a home of its own (none of the user's hooks, skills, rules or MCP servers; only search_tool/use_tool, reaching magpie's MCP tools), borrowing the user's token through magpie grok-token without touching their sign-in; the add sheet has a Grok tile that signs in with grok login's device code

2026-09-24 17:35:36 +08:00

codexcat

codex: /fast works on a routing group too — a group with a ChatGPT account's GPT model in it is listed to Codex with the Fast tier, and the service_tier Codex then sends is kept through the group's routing and passed on to OpenAI's own backends (a ChatGPT account, api.openai.com) only; before, the request was rebuilt without it and Fast did nothing

2026-09-27 17:51:38 +08:00

davsync

cli: 新增 magpie webdav，在终端里开启、修改和触发 WebDAV 同步 / add magpie webdav to turn on, change and run WebDAV sync from the terminal (#127 )

2026-09-28 14:54:04 +08:00

edit

gui: the Agents and Providers pages open at once again — the Providers page worked out each agent's model and routing group again for every provider (every provider's models read again each time, Alma asked over HTTP each time), so it took 25s with many providers; now once per page. What is parsed from a file is kept until the file changes (Codex's models cache, the vendors' model lists, ~/.claude.json's account, and an agent's TOML config — Codex's can run to megabytes of trusted projects, and was parsed again for every field); and what Alma answers when magpie only shows what it is on is reused for five seconds, as its providers take most of a second each time, while a change and what it reads first still ask Alma. /api/providers 25s → 0.02s, /api/state 7s → 0.1s

2026-09-26 22:25:28 +08:00

filememo

gui: the Agents and Providers pages open at once again — the Providers page worked out each agent's model and routing group again for every provider (every provider's models read again each time, Alma asked over HTTP each time), so it took 25s with many providers; now once per page. What is parsed from a file is kept until the file changes (Codex's models cache, the vendors' model lists, ~/.claude.json's account, and an agent's TOML config — Codex's can run to megabytes of trusted projects, and was parsed again for every field); and what Alma answers when magpie only shows what it is on is reused for five seconds, as its providers take most of a second each time, while a change and what it reads first still ask Alma. /api/providers 25s → 0.02s, /api/state 7s → 0.1s

2026-09-26 22:25:28 +08:00

gateway

gateway: a 429 that is a per-minute rate limit rests a minute, not a quarter of an hour (found reviewing #153 ) — usedUpWords took "Rate limit exceeded" and "Rate limit reached … tokens per min" for a used-up plan, and as magpie words an upstream error ("rate_limit_error" its type) exceeded.*limit matched every such 429 whatever the vendor said, so a provider rate-limited for a minute sat out 15 as out of quota (an OpenRouter free model's free-models-per-min, OpenAI's TPM, Anthropic's per-minute limit). Now a 429 in rate words (rate limit, too many requests, per second/minute, RPM/TPM) is a rate limit unless it also says the plan's allowance is used (quota, usage limit, per day/week/month, daily…), and a 429 saying that is out of quota, as a day's free requests are. Tested: those bodies as vendors and magpie word them, and a group through the gateway whose first member answers OpenRouter's free-models-per-min — it rests rate for 1m where main rested quota for 15m

2026-09-28 21:37:46 +08:00

gui

gateway: an Antigravity account Google wants verified says so, and rests (marsxxl: Antigravity 返回「Verify your account to continue」403) — Cloud Code Assist refuses such an account with a 403 whose details say VALIDATION_REQUIRED, a validation_url in their metadata (as pi-ai's google-validation reads it); magpie passed on only the message, and every reconnect went back to the account Google had stopped. Now provider.Verification knows the refusal (the reason, or its words) and APIError adds what to do: open the link, when it's https, in a browser signed in to that account, or else the Antigravity app (or Gemini CLI), then try again. The account rests half an hour as failVerify ("needs verification", 账号需验证) — the last one left too, which rested never — and for a minute the agent's retries get the same error from magpie without asking Google. The Routing page shows the rest with a Verify link and "It's verified — try it again", which lifts it (POST /api/gateway/unrest, Server.Unrest); an answer lifts it as before. Tested with fake upstreams in a sandbox HOME: with a link and without, held retries not sent on, a group falling back past it; the exact body marsxxl got isn't known

2026-09-28 20:56:33 +08:00

library

library: a skill whose folder is gone can be removed (#151 ) — its folder was moved aside with the backups on removal, and with no folder the move failed (rename …: The system cannot find the file specified), so a skill marked as no longer in the library stayed listed for good. Now only its entry is taken out when its folder isn't there

2026-09-28 20:01:48 +08:00

netproxy

windows: the desktop app no longer opens a console window for every command it runs (#54 ) — it is linked as a GUI program and has no console, so each console CLI it started (devin auth status and models list, devin acp for every Devin turn, claude, codex, cursor-agent and grok probes and runs, grok login) was given a new console by Windows, and a Windows Terminal window with it, some every few seconds while the app sat idle. Every command magpie runs is now made through internal/proc, which starts it with CREATE_NO_WINDOW when magpie has no console of its own: the child gets a console without a window, and its output, which magpie always pipes back, arrives as before. A magpie run in a terminal (magpie serve, the TUI, the desktop app started from one with a command) has one, and its children share it as they did, so Ctrl+C there still reaches them. The relaunch after an update keeps its DETACHED_PROCESS, added to rather than replacing the flags it was made with, and a test fails on any command made with os/exec directly, so a new one can't bring the windows back

2026-09-25 14:04:44 +08:00

proc

accounts: a slow or hanging agent CLI no longer holds the providers page (#123 ) — its timeout now ends the call (a CLI that is a script running node left node holding the output, and the call waited for it however long, the 10s timeouts notwithstanding: a CLI's pipes are closed 2s after); a CLI never answered before is waited for 3s, once, then served as nobody signed in until its answer comes behind; and a CLI saying nobody is signed in is kept like any answer, where before it wasn't and every start waited for it again. Tried with cursor-agent and devin hanging 20s and the network black-holed: the first providers call went from 40.6s to 6s on a first start, and to 13ms on the next

2026-09-28 11:20:14 +08:00

profile

agent: on Windows, Codex installed in a WSL distro is an agent of its own, codex@wsl:<distro> ("Codex · WSL Ubuntu") — the distros are listed with wsl.exe -l -q (UTF-16LE, or UTF-8 under WSL_UTF8), each asked once through proc for its $HOME, its ~/.codex, a codex on its PATH and its default route, and shown only where Codex is; its files are Codex's own reading and writing (codexIn, at a place rather than a home) through \\wsl.localhost\<distro> (\\wsl$ before that), with the catalog path written in as the distro spells it and what was there stashed under the distro's agent; the gateway written in is 127.0.0.1 when .wslconfig has networkingMode=mirrored and otherwise the Windows host by the distro's default route, with a notice that NAT needs the gateway beyond loopback and through Windows' firewall and that mirrored is the way; its requests stay counted as Codex's, and a profile key is split at its last dot for distro names like Ubuntu-24.04. Nothing runs off Windows. Kimi CLI isn't an agent magpie has yet, so there is no Kimi in WSL. Tested on a Windows box under NAT with a throwaway Alpine distro: detected (the real distros without Codex left out), a magpie model set and reset from the CLI and a test binary, the catalog read inside WSL at /root/.codex; mirrored networking tested only in unit tests

2026-09-28 17:22:30 +08:00

provider

provider: Cursor stays listed when cursor-agent can't say who is signed in (cataglyphis: 供应商选型中间歇无法显示 cursor，导致路由里不能正常路由到 cursor 的模型) — who Cursor's account is comes from cursor-agent about --format json, asked again behind the served answer every minute, and any about that failed, ran past its 10s (it asks Cursor's servers), or printed something besides its JSON was taken for nobody signed in: Cursor dropped out of the Providers page and of routing (All() lists the accounts for both), and that was kept on disk, until an ask a minute or more on came back. Now an ask that couldn't tell leaves what was served, on disk too, and is asked again in a minute (cliIdentity's ask returns an error for that); Cursor is taken as signed out only when about says so in its JSON or cursor-agent keeps no token. About's JSON after a line of its own (an update notice) is read too. Devin's ask is as before. Tested with fake cursor-agent scripts in a temp HOME (signed in, update notice, says nobody, fails, no JSON, fails with the token gone) and the cache through a failed ask and a sure sign-out; not tested against a real cursor-agent, and what made reporter's about fail isn't known

2026-09-28 21:02:48 +08:00

redact

gateway: count_tokens counts the masked prompt, and a count that cannot be had is told apart — the count Claude Code asks for before every turn went to the vendor as the conversation was written, so Mask secrets was defeated on every one; it now goes masked, the same prompt the turn it counts sends. An endpoint that doesn't implement counting (404/405/501, or a 400 that says so, in English or Chinese) falls back to the local estimate as before; a limited key or a broken connection yields to the next checked key and rests the one that failed, as a generation would, while a client's own cancellation rests nothing; and a real error — a wrong key, a prompt past the model's context, an image it won't take — reaches the agent. The gateway tests are isolated from the machine now (a temp HOME, inert stubs for the sign-in CLIs and the keychain) so a cache that outlives a test can't reach a real login, and the redaction tests' cold starts run in parallel. (#103 )

2026-09-27 18:58:23 +08:00

sessions

sessions: OpenCode's and Pi's sessions are listed too (貌似没有opencode和pi的session，能支持一下么) — Usage → Sessions, magpie sessions and the TUI read OpenCode's opencode.db (or $OPENCODE_DB) read-only, or its older storage/ JSON files when there is no database, under $XDG_DATA_HOME/opencode or ~/.local/share/opencode, a subagent's session counted under the one that started it; and Pi's JSONL sessions under $PI_CODING_AGENT_DIR or ~/.pi/agent, plus $PI_CODING_AGENT_SESSION_DIR or settings.json's sessionDir, a forked session not counting again what it copied from its parent. Each gets its title, folder, times, tokens per model with cache reads and writes, cost, and a resume command (opencode --session <id>, pi --session <id>); the folders note names only the agents that are there

2026-09-28 18:45:07 +08:00

settings

warm-up: the 5-hour windows can start at a time of day (预热是重置之后发，时间不一定是我想要的…早上六点发送一个请求，这样就可以做到一天三个五小时) — Settings has "Codex daily warm-up" and "Claude Code daily warm-up" under the warm-ups, Off or On with a time field (06:00 to begin with, local time, codexWarmAt / claudeWarmAt); each day at that time every signed-in account of that kind whose 5-hour window isn't running is sent the warm-up's one tiny request, once a day an account, the day kept in codex-warmup.json / claude-warmup.json so a restart doesn't send it again; a machine asleep then sends it on waking up to an hour late and leaves the day be after that; a failed one is tried again within the hour. It works with the reset warm-up off, weekly or on; with "Weekly and 5-hour" a window that would still be running at the time isn't started on its reset, so the windows follow one another from it (06, 11, 16, 21, then 06 again) instead of drifting round the clock. The warm-up loop looks at the wall clock every minute, running as before every 5 and at once when the time comes

2026-09-28 18:47:30 +08:00

stats

stats: magpie counts its users — once a day a running app or magpie serve sends PostHog (the Magpie project) one "magpie active" event under a random id made up on this computer (~/.config/magpie/install-id), with the version, the system and the architecture and nothing else, no person profile kept; off in Settings → Privacy → Count me as a user, or with DO_NOT_TRACK=1 or MAGPIE_NO_STATS=1, and never from a build from source; the README says what goes

2026-09-28 17:23:41 +08:00

tui

tui: the Sessions page lists the sessions (Kumo31: tui sessions里能看到统计信息，但没有列出具体session) — it opens on the sessions active in the range, the latest first, under the model and folder picked, as the app and magpie sessions list them: when, agent, folder, tokens, cost and title, as many as fit around the one picked with how many more above and below. ↑↓ pick one and enter resumes it in this terminal (its resume command, shown under the list, through sh or PowerShell; back on the page when the agent quits), or says its folder is gone rather than a shell's exit status; s (or tab) goes to the stats — totals, chart, top models and folders — and back

2026-09-28 20:40:44 +08:00

update

web: magpie web knows its version and updates itself as the app does — the badge's restart puts the new version in and runs it in the old one's place with the same arguments and key, so the open page reloads onto it (#111 ); routing: a gateway served by magpie serve, which has no window, is told apart from another magpie's window, and the routing view says to stop it so this magpie serves the gateway and shows routing live (#110 )

2026-09-27 19:39:45 +08:00

usage

routing: a request shows the reasoning its model was actually sent at (显示意图路由实际的推理强度 #144 ) — the trace keeps the effort the agent asked for and, on each try, the one sent upstream after the turn's pick and fitting to the model's levels (picked marks the turn's pick), so the Routing list reads "Fake · m-big · high", its tooltip says what the agent asked for, and the request's story adds "The turn's pick replaced the medium Codex asked for."; usage.jsonl records the sent effort too, and the Usage session list shows where magpie routed a session's calls and at what reasoning ("→ m-big · high +1", with a Routed line per model and effort in its detail)

2026-09-28 18:11:58 +08:00