magpie

agent

agent: a goose on PATH that is pressly's migration tool isn't taken for Goose (Discord: Jun, Goose listed with no ~/.config/goose) — any goose on PATH counted as the agent, and the Go database migration tool of that name is common among Go developers. Now a goose on PATH counts only when it isn't a Go program (Block's goose is Rust); goose's config dir still counts as before

2026-09-29 14:04:32 +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: an image model's Test models draws one small picture on the images API, as the gateway draws with it (mamba: 图像模型点测试模型是不是发送的请求不对啊，总是提示响应异常) — every model picked was sent a chat completion ("hi", max_tokens 16), so gpt-image, flux, seedream and the like, which a vendor serves only at /images/generations, were turned away and always showed as not answering. Now a model the gateway draws with on an images API (catalog.ImagesAPI, the list viaFor used, shared) is asked there for one picture of "a dot", n=1, at gpt-image's low quality and the vendor's default size, waiting up to two minutes (the request up to three); a 404 or 405 there is tried in chat as the gateway does. Chat models and gemini-*-image / gpt-5-image (which draw in chat) are asked as before, and the vendor-wide Test asks a chat model ahead of one that draws. Tested with a fake vendor that serves images only at /images/generations and chat only at /chat/completions

2026-09-29 14:37:09 +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

providers: an image model's Test models draws one small picture on the images API, as the gateway draws with it (mamba: 图像模型点测试模型是不是发送的请求不对啊，总是提示响应异常) — every model picked was sent a chat completion ("hi", max_tokens 16), so gpt-image, flux, seedream and the like, which a vendor serves only at /images/generations, were turned away and always showed as not answering. Now a model the gateway draws with on an images API (catalog.ImagesAPI, the list viaFor used, shared) is asked there for one picture of "a dot", n=1, at gpt-image's low quality and the vendor's default size, waiting up to two minutes (the request up to three); a 404 or 405 there is tried in chat as the gateway does. Chat models and gemini-*-image / gpt-5-image (which draw in chat) are asked as before, and the vendor-wide Test asks a chat model ahead of one that draws. Tested with a fake vendor that serves images only at /images/generations and chat only at /chat/completions

2026-09-29 14:37:09 +08:00

gui

providers: an image model's Test models draws one small picture on the images API, as the gateway draws with it (mamba: 图像模型点测试模型是不是发送的请求不对啊，总是提示响应异常) — every model picked was sent a chat completion ("hi", max_tokens 16), so gpt-image, flux, seedream and the like, which a vendor serves only at /images/generations, were turned away and always showed as not answering. Now a model the gateway draws with on an images API (catalog.ImagesAPI, the list viaFor used, shared) is asked there for one picture of "a dot", n=1, at gpt-image's low quality and the vendor's default size, waiting up to two minutes (the request up to three); a 404 or 405 there is tried in chat as the gateway does. Chat models and gemini-*-image / gpt-5-image (which draw in chat) are asked as before, and the vendor-wide Test asks a chat model ahead of one that draws. Tested with a fake vendor that serves images only at /images/generations and chat only at /chat/completions

2026-09-29 14:37:09 +08:00

imagemcp

images: agents can generate and edit images with a model set in Magpie (让Magpie支持配置图像识别模型以及生图模型, part 2) — the gateway answers /v1/images/generations and /v1/images/edits for any model that draws: an images-API model (gpt-image-1, dall-e, imagen, a relay's) is sent the vendor's own images request (an edit as multipart, image[] per reference); a chat model that answers with images (OpenRouter's Nano Banana and GPT-5 Image, gpt-5-image) is asked with modalities ["image","text"], the size given as an aspect ratio, once per image asked for; Gemini's own image models over generateContent. Either way the answer is the images API's (b64_json with its mime_type, the model's text, usage), recorded in usage like any request. The model is Settings → Images → Image generation: Automatic (a model that draws among the providers set up, from the catalog's image-output models), Off, or any model; a request that names none is drawn by it, and with it Off is refused saying where to set one. Subscriptions draw nothing yet. magpie mcp image is a stdio MCP server with one tool, generate_image (prompt, size, n, path, reference_images): it asks the agent for its roots, saves each image in the project (assets/ by default, a name from the prompt, never over a file, the extension of what came back — a JPEG asked for as hero.png is hero.jpg), and says where; reference images are read from the project and sent as an edit. Its requests carry the agent's own name (claude-code/… magpie-image/1) so usage says which agent drew. Library → MCP servers → Discover has it as Magpie Image, opt-in: no agent is given it until picked, since every image costs what the model charges. Checked in a sandbox HOME against real vendors: OpenRouter's gemini-3.1-flash-lite-image drew a 3:2 magpie over MCP as Claude Code and edited it from the saved file as Codex (usage: claude, codex), AIHubMix's gpt-image-1 answered /v1/images/generations with a 1024² PNG; the Settings row and picker in light and dark, the Library card and its opt-in sheet

2026-09-29 01:52:53 +08:00

library

images: agents can generate and edit images with a model set in Magpie (让Magpie支持配置图像识别模型以及生图模型, part 2) — the gateway answers /v1/images/generations and /v1/images/edits for any model that draws: an images-API model (gpt-image-1, dall-e, imagen, a relay's) is sent the vendor's own images request (an edit as multipart, image[] per reference); a chat model that answers with images (OpenRouter's Nano Banana and GPT-5 Image, gpt-5-image) is asked with modalities ["image","text"], the size given as an aspect ratio, once per image asked for; Gemini's own image models over generateContent. Either way the answer is the images API's (b64_json with its mime_type, the model's text, usage), recorded in usage like any request. The model is Settings → Images → Image generation: Automatic (a model that draws among the providers set up, from the catalog's image-output models), Off, or any model; a request that names none is drawn by it, and with it Off is refused saying where to set one. Subscriptions draw nothing yet. magpie mcp image is a stdio MCP server with one tool, generate_image (prompt, size, n, path, reference_images): it asks the agent for its roots, saves each image in the project (assets/ by default, a name from the prompt, never over a file, the extension of what came back — a JPEG asked for as hero.png is hero.jpg), and says where; reference images are read from the project and sent as an edit. Its requests carry the agent's own name (claude-code/… magpie-image/1) so usage says which agent drew. Library → MCP servers → Discover has it as Magpie Image, opt-in: no agent is given it until picked, since every image costs what the model charges. Checked in a sandbox HOME against real vendors: OpenRouter's gemini-3.1-flash-lite-image drew a 3:2 magpie over MCP as Claude Code and edited it from the saved file as Codex (usage: claude, codex), AIHubMix's gpt-image-1 answered /v1/images/generations with a 1024² PNG; the Settings row and picker in light and dark, the Library card and its opt-in sheet

2026-09-29 01:52:53 +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: after a Codex switch, magpie says when Codex's background service is still on the account before, and restarts it when asked (vincentzhang on Discord) — Codex CLI can keep an app-server running (codex app-server --managed-daemon) that reads the sign-in once, when it starts, so sessions opened after a switch still ran on the account before. When a switch changes the account while such a daemon runs, Codex's account list shows that it is still signed in as the one before, with Later and Restart; Restart runs codex app-server daemon restart for the Codex home magpie signs in through, which ends the Codex sessions on it, so magpie never does it unasked. magpie accounts switch codex prints the same hint and the command. The notice goes when the daemon restarts or stops, or Codex is switched back. Only a codex program's app-server with --managed-daemon counts: the ChatGPT app's codex and other apps' app-servers don't. Tested with a fake codex and a fake daemon in a sandbox magpie web; the real codex 0.155 has the restart command

2026-09-29 11:59:57 +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

providers: an image model's Test models draws one small picture on the images API, as the gateway draws with it (mamba: 图像模型点测试模型是不是发送的请求不对啊，总是提示响应异常) — every model picked was sent a chat completion ("hi", max_tokens 16), so gpt-image, flux, seedream and the like, which a vendor serves only at /images/generations, were turned away and always showed as not answering. Now a model the gateway draws with on an images API (catalog.ImagesAPI, the list viaFor used, shared) is asked there for one picture of "a dot", n=1, at gpt-image's low quality and the vendor's default size, waiting up to two minutes (the request up to three); a 404 or 405 there is tried in chat as the gateway does. Chat models and gemini-*-image / gpt-5-image (which draw in chat) are asked as before, and the vendor-wide Test asks a chat model ahead of one that draws. Tested with a fake vendor that serves images only at /images/generations and chat only at /chat/completions

2026-09-29 14:37:09 +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 v2's sessions are read (Kumo31: opencode v2的session改写到新表里了) — OpenCode 2 (v2.0.x, checked against v2.0.18's source) keeps sessions in the same opencode.db but in tables of its own (packages/core/src/session/sql.ts): session_v2 (the session row as before — directory, parent_id, a title that may now be null, time_created/updated, model {id, providerID, variant}, session totals) and session_message (id, session_id, type, seq, time_created/updated, data), not "sessionmessage". A message's kind is its type column (user, assistant, synthetic, system, compaction, idle, …); a user message's data is its prompt {text, files, …} with no part rows; an assistant's has model {id, providerID, variant}, content (text/reasoning/tool), cost, tokens {input, output, reasoning, cache {read, write}} and time {created, completed} (packages/schema/src/session-message.ts, token-usage.ts), counted as before: input without the cache, output without the reasoning (core/src/session/usage.ts). A compaction carries its own tokens, counted on its model, else the one last replied with. On first start OpenCode 2 copies every old session over (core/src/database/v1-migration.bun.ts), leaving session/message/part unwritten and recording kv migration.v1-v2 {"phase":"completed"}; so with session_v2 present only it is read once that is recorded (or no old table is left, as for the pre-split v2 databases it renamed in place), and while the copy is under way an old session not yet in session_v2 is read from the old tables — never both, so nothing counts twice and a session deleted in v2 doesn't come back. Resume stays opencode --session <ses…> (cli/src/commands/commands.ts). Tested with a v2 fixture made in the test from SQL beside stale old tables; the old-table and JSON-file tests still pass.

2026-09-29 00:38:10 +08:00

settings

accounts: WorkBuddy's daily check-in (签到) done for each WorkBuddy (China) account, when Settings says to (zhanglolo on Discord: 能不能加个 WorkBuddy 自动签到) — while WorkBuddy's check-in event runs, an account is given credits a day for pressing 签到 in the app. Settings has Check in to WorkBuddy daily (off by default, shown while a WorkBuddy China account is signed in): the gateway asks the event's status for each account and claims when it runs and today's isn't in, once a Beijing day; an answer holds for the day (claimed, already in, not eligible, the event over), no answer is tried again after 30 minutes. What came of it is kept by site and account id in workbuddy-checkin.json and shown under the setting. magpie accounts checkin [--json] does it now. WorkBuddy AI (international) has no event and is left alone. Tested with a fake WorkBuddy API; checked the row in a sandbox magpie web

2026-09-29 09:56:46 +08:00

shortcut

app: Magpie is in the Start menu on Windows (#158 : Windows 便携版首次运行后，无法在开始菜单 / 系统搜索中找到 Magpie — @Aimer779) — the Windows build is one portable exe with no installer, so nothing put it anywhere Windows search looks. Each start of the desktop app (not the CLI, TUI or serve) now makes sure %APPDATA%\Microsoft\Windows\Start Menu\Programs\Magpie.lnk (the Programs known folder) opens the exe it runs as, symlinks resolved, in its folder, with its icon and "Magpie" as its description; one that already does is left be, one for where the exe was before it was moved is pointed here again. It is the shell's own link, made through WScript.Shell with go-ole (already in the build through Wails, now a direct require), in the background beside the magpie:// registration, and a failure is only logged. An update replaces the exe in place, so the shortcut stays good; a magpie left running from magpie.exe.old(-N) (or .new) points it at magpie.exe, never at what was moved aside. HKCU App Paths\magpie.exe is set to the exe (and its folder) so Win+R magpie opens it too. No uninstall entry, nothing copied. MAGPIE_NO_SHORTCUT=1 skips it (tests, sandboxes); other systems do nothing. Tested with the Windows test built here and run on Windows 11: a shortcut made, left as it was on a second start, pointed at the moved exe. Run on Windows 11 as the desktop app: the shortcut made with the exe's folder and icon, pointed anew after the exe moved, left as it was on a start with nothing changed; App Paths set

2026-09-28 22:44:36 +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

routing: a group's intent classifier can be a routing group, failing over as any request to it does (lantern2077 on Discord: 意图分类模型能否也选择路由组？现在只能选择单个模型，缺乏回退保障) — the classifier was one model, and when it was down no intent matched. It can now be group/<id>, asked through magpie as before, so its first model failing the next is asked. A group can't be its own classifier, one that classifies for another can't be removed until that one chooses another, a rename carries over, and a classifier's own call asks no classifier in turn, so two groups classifying with each other don't loop. The GUI and TUI pickers list the other groups. Tested: the classifier group's first model 500s and the next answers and the rule matches; two groups set to classify with each other finish at once; checked in a sandbox magpie web that the picker lists Cls and not the group being edited, and via the CLI that self-classifying and removing a classifier group are refused

2026-09-29 10:25:41 +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