magpie

agent

agent: Pi starts on the model magpie picks, and asks a Messages-only provider's models on Messages (#160 Aimer779; Cleary on Discord)

2026-09-29 00:09:06 +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: AIHubMix's GPT Image 2 and 2.5 can be picked to draw (我记得AI Hub Mix是有GPT Image 2以及GPT Image 2.5模型的，为什么选不到呢？) — AIHubMix's /v1/models, asked with a key, lists only its Gemini image models, though the same key draws with gpt-image-1/2/2.5 and the rest; its public catalog (aihubmix.com/api/v1/models) lists them all. Now when an AIHubMix provider's list is fetched, the image models of that catalog join it as drawing (Settings → Images, never offered to agents to chat with); Ideogram's V_2, DESCRIBE and UPSCALE are left out. Checked in a sandbox HOME against the real AIHubMix: after a refresh the picker has aihubmix/gpt-image-2, gpt-image-2.5-flare and 2.5-sunburst among 46 of its image models, and gpt-image-2 and gpt-image-2.5-flare each drew a 1024² PNG through the gateway

2026-09-29 02:37:58 +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: an empty reasoning_content is left out of a relayed Chat stream, so Qoder reads a WorkBuddy reply as one message, not a word to a line (lml on Discord: 在Qoder CN里面使用Workbuddy里面的模型的话，它这个输出不对) — WorkBuddy's endpoint (copilot.tencent.com/v2) goes on sending "reasoning_content": "" in every delta once the model has done thinking. Its own CLI ignores an empty one after the thinking is over (codebuddy.js: !(this.thinkingBlockCompleted&&""===ec.reasoning_content)), and Cline copes, but Qoder CN 1.1.64 takes each for the thinking starting again and each piece of text after it for a new message, so "hi" was answered one word to a line. A Chat stream magpie relays as it is now has an empty reasoning_content taken out of each delta; it says nothing, and any other line goes on byte for byte, split reads put back into whole lines first. Tested with a scripted Chat upstream streaming WorkBuddy's shape: the agent gets the thinking, the text, finish_reason and usage, and no empty reasoning_content (the test fails without the change); lines split every 7 bytes come out whole

2026-09-29 02:35:51 +08:00

gui

gui: the image model pickers keep routing groups in one group, as an agent's picker does (重大bug，这里为什么都是重复的icon？) — Settings → Images put each routing group in a group named after itself, so the picker's rail had a button for every one of them, each with its first member's icon: with 31 groups, rows of the same OpenRouter, AIHubMix, Claude Code, Codex and Copilot icons. A model without a provider of its own (a routing group) is now under Routing groups, one rail button with the fan, then one per provider. Automatic and Off, the picker's own choices, stay above the routing groups, which every model picker puts first. Checked with the live Settings' 31 groups and their providers: the rail is All, Favorites, Routing groups, OpenRouter, DeepSeek, 鱼鱼连线, AiHubMix, Claude Code, Codex, Copilot… once each, in light and dark

2026-09-29 02:34:01 +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: 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

providers: AIHubMix's GPT Image 2 and 2.5 can be picked to draw (我记得AI Hub Mix是有GPT Image 2以及GPT Image 2.5模型的，为什么选不到呢？) — AIHubMix's /v1/models, asked with a key, lists only its Gemini image models, though the same key draws with gpt-image-1/2/2.5 and the rest; its public catalog (aihubmix.com/api/v1/models) lists them all. Now when an AIHubMix provider's list is fetched, the image models of that catalog join it as drawing (Settings → Images, never offered to agents to chat with); Ideogram's V_2, DESCRIBE and UPSCALE are left out. Checked in a sandbox HOME against the real AIHubMix: after a refresh the picker has aihubmix/gpt-image-2, gpt-image-2.5-flare and 2.5-sunburst among 46 of its image models, and gpt-image-2 and gpt-image-2.5-flare each drew a 1024² PNG through the gateway

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

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

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

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