magpie

agent.go

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

agents.go

agents: Kimi Code, Moonshot's kimi CLI, is an agent magpie sets up (agent求个kimi code支持) — it keeps its settings in ~/.kimi/config.toml ($KIMI_SHARE_DIR's), its default_model a key of its [models."…"] tables, each naming a [providers.…] one. Picking a model through magpie adds the provider "magpie" (the gateway, as Kimi's own chat completions type, so the thinking goes out as reasoning_effort and comes back, and is sent back, as reasoning_content) and a table per catalog model keyed "magpie/<provider>/<model>", with its context (128K when not known) and thinking/image_in capabilities, so the catalog is in Kimi's /model picker and kept up to date as providers change; the Kimi Code sign-in's default is stashed and put back on reset, and the tables go in and out in the order Kimi's own check wants (a default or a provider it can't find makes it refuse the file). Its requests are Kimi Code's in usage (KimiCLI/…). The gateway also drops Kimi's thinking: {type: …} on a request relayed to api.openai.com, as it does Qwen's enable_thinking. Tested: the config in the shape a Kimi Code sign-in leaves it (set, sync, a moved base_url, reset, its own model, no config at all), and the real kimi 1.24.0 --print against a sandbox gateway and a fake upstream: reply and thinking shown, reasoning_effort high on a thinking model, reasoning_content sent back on the next turn, usage under Kimi Code; not with a real vendor behind it

2026-09-29 16:36:35 +08:00

alma_test.go

agents: Alma is known as Alma, not ai-sdk — its requests go out with the AI SDK's User-Agent and nothing of Alma's, so magpie's provider in Alma now carries the key magpie-alma and the gateway knows an agent by a magpie-<agent> key before its User-Agent (usage, the routing view, the models it is shown). An Alma wired before gets the key on the next sync, the key alone sent, as a baseURL would have Alma drop its models

2026-09-27 15:28:33 +08:00

alma.go

agents: Alma is known as Alma, not ai-sdk — its requests go out with the AI SDK's User-Agent and nothing of Alma's, so magpie's provider in Alma now carries the key magpie-alma and the gateway knows an agent by a magpie-<agent> key before its User-Agent (usage, the routing view, the models it is shown). An Alma wired before gets the key on the next sync, the key alone sent, as a baseURL would have Alma drop its models

2026-09-27 15:28:33 +08:00

applied_test.go

agent: Claude Desktop runs on magpie in its third-party mode (#156 : Claude Desktop 不会解锁 Claude Code 面板 — CC Switch 可以，咱这个支持吗？) — signed in with a Free account, Desktop's Code tab is only "Get Claude Code"; in its 3p deployment mode it needs no Anthropic sign-in and Code and Cowork run on the gateway. A Claude Desktop agent whose provider field switches it: on writes deploymentMode "3p" into Claude/ and Claude-3p/claude_desktop_config.json, a magpie profile in Claude-3p/configLibrary/<id>.json (inferenceProvider gateway, inferenceGatewayBaseUrl the gateway's address, inferenceGatewayApiKey magpie-claude-desktop, inferenceGatewayAuthScheme bearer; disableDeploymentModeChooser and coworkEgressAllowedHosts ["*"] only where unset) and its entry in _meta.json, applied — the keys and files CC Switch writes (claude_desktop_config.rs). No inferenceModels: Desktop lists /v1/models, which the gateway already gives it by ids it keeps. Off puts each deploymentMode back as it was (gone where there was none), the profile applied before applied again, magpie's profile and entry removed, and files and folders magpie made gone if nothing else went in; other keys and profiles are never touched. Folders as CC Switch finds them: ~/Library/Application Support, %LOCALAPPDATA% (a Claude… folder there if not Claude itself), $XDG_CONFIG_HOME. Desktop reads them at start-up, which the picker and notice say. The Library keeps giving Desktop's MCP servers to %APPDATA%'s file on Windows, listed once. Tested in a sandbox home: fresh, with the user's settings and 3p profiles (off restores every byte), on twice, on → off → on, drift, odd files refused, each system's folders; and against Claude Desktop 2.9939.2 on Windows 11 (winget): on, it started in 3P mode (provider gateway, apiHost the gateway) with the Code tab and no sign-in, and asked the gateway's /v1/models; off, it went back to claude.ai

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

applied.go

agents: a magpie on a port of its own (magpie-dev, a sandbox) takes an agent wired to the installed magpie's gateway (127.0.0.1:3425) for that one's, not drift — the two took turns flagging Codex with Apply again, each rewiring it to itself

2026-09-27 14:54:35 +08:00

cindy_test.go

agent: Cindy's global build is found too (Magpie在Cindy里面显示的图标不对) — its data is in CindyGlobal, one cindy-<account>.db per signed-in account, where magpie only looked in Cindy/cindy-local-v1.db, so the row said Magpie wasn't added when it was; both folders are looked in and every account's database read, read-only as before. The icon itself is Cindy's: it takes no icon on import and draws its own logos only for providers it knows by id or host, a first-letter badge for any other

2026-09-28 18:23:09 +08:00

cindy.go

agent: Cindy's global build is found too (Magpie在Cindy里面显示的图标不对) — its data is in CindyGlobal, one cindy-<account>.db per signed-in account, where magpie only looked in Cindy/cindy-local-v1.db, so the row said Magpie wasn't added when it was; both folders are looked in and every account's database read, read-only as before. The icon itself is Cindy's: it takes no icon on import and draws its own logos only for providers it knows by id or host, a first-letter badge for any other

2026-09-28 18:23:09 +08:00

claude_test.go

effort: Claude Code can start at max — settings.json's effortLevel keeps up to xhigh (/effort max lasts a session), so magpie keeps max as CLAUDE_CODE_EFFORT_LEVEL in its env, which every session asks for (tested: Claude Code then sends output_config.effort max), and another level takes it away. A model whose reasoning levels aren't known (one models.dev doesn't list, a custom provider's) can be given some of none…max on the Providers page or with magpie model efforts, which the lists agents get and the gateway then take it to have: a request's effort is fitted to them, max sent as max

2026-09-27 11:05:47 +08:00

claude.go

gateway: a model Claude Code names that magpie doesn't serve goes to the one it is set to use for that tier — claude-haiku-4-5-… for a title or a small task goes to its haiku tier's model, opus and sonnet to theirs, a name of no tier to its main model, rather than to some provider that happens to list the name and wasn't picked for it. Other agents, and ids magpie shows, are sent as asked

2026-09-28 13:25:25 +08:00

claudedesktop_test.go

agent: Claude Desktop runs on magpie in its third-party mode (#156 : Claude Desktop 不会解锁 Claude Code 面板 — CC Switch 可以，咱这个支持吗？) — signed in with a Free account, Desktop's Code tab is only "Get Claude Code"; in its 3p deployment mode it needs no Anthropic sign-in and Code and Cowork run on the gateway. A Claude Desktop agent whose provider field switches it: on writes deploymentMode "3p" into Claude/ and Claude-3p/claude_desktop_config.json, a magpie profile in Claude-3p/configLibrary/<id>.json (inferenceProvider gateway, inferenceGatewayBaseUrl the gateway's address, inferenceGatewayApiKey magpie-claude-desktop, inferenceGatewayAuthScheme bearer; disableDeploymentModeChooser and coworkEgressAllowedHosts ["*"] only where unset) and its entry in _meta.json, applied — the keys and files CC Switch writes (claude_desktop_config.rs). No inferenceModels: Desktop lists /v1/models, which the gateway already gives it by ids it keeps. Off puts each deploymentMode back as it was (gone where there was none), the profile applied before applied again, magpie's profile and entry removed, and files and folders magpie made gone if nothing else went in; other keys and profiles are never touched. Folders as CC Switch finds them: ~/Library/Application Support, %LOCALAPPDATA% (a Claude… folder there if not Claude itself), $XDG_CONFIG_HOME. Desktop reads them at start-up, which the picker and notice say. The Library keeps giving Desktop's MCP servers to %APPDATA%'s file on Windows, listed once. Tested in a sandbox home: fresh, with the user's settings and 3p profiles (off restores every byte), on twice, on → off → on, drift, odd files refused, each system's folders; and against Claude Desktop 2.9939.2 on Windows 11 (winget): on, it started in 3P mode (provider gateway, apiHost the gateway) with the Code tab and no sign-in, and asked the gateway's /v1/models; off, it went back to claude.ai

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

claudedesktop.go

agent: Claude Desktop runs on magpie in its third-party mode (#156 : Claude Desktop 不会解锁 Claude Code 面板 — CC Switch 可以，咱这个支持吗？) — signed in with a Free account, Desktop's Code tab is only "Get Claude Code"; in its 3p deployment mode it needs no Anthropic sign-in and Code and Cowork run on the gateway. A Claude Desktop agent whose provider field switches it: on writes deploymentMode "3p" into Claude/ and Claude-3p/claude_desktop_config.json, a magpie profile in Claude-3p/configLibrary/<id>.json (inferenceProvider gateway, inferenceGatewayBaseUrl the gateway's address, inferenceGatewayApiKey magpie-claude-desktop, inferenceGatewayAuthScheme bearer; disableDeploymentModeChooser and coworkEgressAllowedHosts ["*"] only where unset) and its entry in _meta.json, applied — the keys and files CC Switch writes (claude_desktop_config.rs). No inferenceModels: Desktop lists /v1/models, which the gateway already gives it by ids it keeps. Off puts each deploymentMode back as it was (gone where there was none), the profile applied before applied again, magpie's profile and entry removed, and files and folders magpie made gone if nothing else went in; other keys and profiles are never touched. Folders as CC Switch finds them: ~/Library/Application Support, %LOCALAPPDATA% (a Claude… folder there if not Claude itself), $XDG_CONFIG_HOME. Desktop reads them at start-up, which the picker and notice say. The Library keeps giving Desktop's MCP servers to %APPDATA%'s file on Windows, listed once. Tested in a sandbox home: fresh, with the user's settings and 3p profiles (off restores every byte), on twice, on → off → on, drift, odd files refused, each system's folders; and against Claude Desktop 2.9939.2 on Windows 11 (winget): on, it started in 3P mode (provider gateway, apiHost the gateway) with the Code tab and no sign-in, and asked the gateway's /v1/models; off, it went back to claude.ai

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

cline_test.go

agents: the effort picked for Cline and Qoder is the one they use — Cline's reasoning is written {enabled:true,effort} ({enabled:false} for none), as its own pickers leave an enabled false that drops an effort beside it, and such a one reads as none; Cline's VS Code extension (4.x), which takes its provider, model, base URL and key from globalState.json and secrets.json before providers.json, has those set too where they are, stashed and put back on the way out, and $CLINE_DATA_DIR is honoured. Qoder (1.1.6x) keeps each model's effort in model.preferences and moves model.reasoningEffort there once: magpie sets the model's preference (a model id with dots too), carries the effort in use to a model with none of its own, and keeps reasoningEffort for older Qoders. Cline's desktop app keeps its composer's model and effort in its web view's storage, which magpie leaves alone; its notice says to pick there

2026-09-28 13:41:31 +08:00

cline.go

agents: the effort picked for Cline and Qoder is the one they use — Cline's reasoning is written {enabled:true,effort} ({enabled:false} for none), as its own pickers leave an enabled false that drops an effort beside it, and such a one reads as none; Cline's VS Code extension (4.x), which takes its provider, model, base URL and key from globalState.json and secrets.json before providers.json, has those set too where they are, stashed and put back on the way out, and $CLINE_DATA_DIR is honoured. Qoder (1.1.6x) keeps each model's effort in model.preferences and moves model.reasoningEffort there once: magpie sets the model's preference (a model id with dots too), carries the effort in use to a model with none of its own, and keeps reasoningEffort for older Qoders. Cline's desktop app keeps its composer's model and effort in its web view's storage, which magpie leaves alone; its notice says to pick there

2026-09-28 13:41:31 +08:00

codex_effort_test.go

codex: a model a custom provider serves takes the reasoning levels models.dev gives it from the others serving it, so the Codex app offers an effort for it (a Volcengine endpoint's glm-5.3-flash showed 中 with nothing to pick, and magpie's effort control a "none" Codex never used) — levels were only taken from models.dev's entry for the vendor itself, and a vendor it doesn't list (a custom provider, a proxy) had none, so Codex's catalog carried no supported_reasoning_levels; a model models.dev doesn't list for its vendor now takes, by bare id as the context window is found, the levels most of the providers giving any give it (glm-5.3-flash: low, high, max, default high), one no one gives levels for keeps none. Codex's effort is settled on one the model takes when a model is picked and when the catalog is synced, magpie shows the catalog's default where none is set, and the gateway sends a Chat vendor reasoning_effort at the model's nearest level (Codex's medium goes to glm-5.3-flash as high), as asked where the model's are not known

2026-09-25 14:54:47 +08:00

codex_failover_test.go

gateway: Codex on one of its own models moves on to the next ChatGPT account when the one it is signed in to has used its allowance up — with more of Codex's accounts on in magpie, Codex's requests go through magpie even for its own models (openai_base_url kept, and put back or taken out as accounts are switched on or off) and are served as the codex subscription's, which fails over as its other models do; the account out of allowance rests until ChatGPT says it resets (resets_at), up to an hour at a time. Asked on Discord

2026-09-26 21:11:42 +08:00

codex_own_test.go

models: each agent can be shown only some of them — a provider or group gets a family (magpie provider set relay-x family=relay), and magpie visible zcode relay shows zcode only that family's models (or named providers and groups): in the files magpie writes for it and in what /v1/models answers it, told apart by its User-Agent; magpie models zcode lists what it is shown and what is kept from it, and magpie visible zcode all shows it everything again. A model kept from an agent is still served when asked for by name. Asked for on Discord

2026-09-26 16:02:29 +08:00

codex_route_test.go

agent: Claude Desktop runs on magpie in its third-party mode (#156 : Claude Desktop 不会解锁 Claude Code 面板 — CC Switch 可以，咱这个支持吗？) — signed in with a Free account, Desktop's Code tab is only "Get Claude Code"; in its 3p deployment mode it needs no Anthropic sign-in and Code and Cowork run on the gateway. A Claude Desktop agent whose provider field switches it: on writes deploymentMode "3p" into Claude/ and Claude-3p/claude_desktop_config.json, a magpie profile in Claude-3p/configLibrary/<id>.json (inferenceProvider gateway, inferenceGatewayBaseUrl the gateway's address, inferenceGatewayApiKey magpie-claude-desktop, inferenceGatewayAuthScheme bearer; disableDeploymentModeChooser and coworkEgressAllowedHosts ["*"] only where unset) and its entry in _meta.json, applied — the keys and files CC Switch writes (claude_desktop_config.rs). No inferenceModels: Desktop lists /v1/models, which the gateway already gives it by ids it keeps. Off puts each deploymentMode back as it was (gone where there was none), the profile applied before applied again, magpie's profile and entry removed, and files and folders magpie made gone if nothing else went in; other keys and profiles are never touched. Folders as CC Switch finds them: ~/Library/Application Support, %LOCALAPPDATA% (a Claude… folder there if not Claude itself), $XDG_CONFIG_HOME. Desktop reads them at start-up, which the picker and notice say. The Library keeps giving Desktop's MCP servers to %APPDATA%'s file on Windows, listed once. Tested in a sandbox home: fresh, with the user's settings and 3p profiles (off restores every byte), on twice, on → off → on, drift, odd files refused, each system's folders; and against Claude Desktop 2.9939.2 on Windows 11 (winget): on, it started in 3P mode (provider gateway, apiHost the gateway) with the Code tab and no sign-in, and asked the gateway's /v1/models; off, it went back to claude.ai

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

codex.go

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

commandcode_test.go

agent: Command Code — its model picked in magpie like any agent's; a model through magpie adds magpie as a keyless provider in ~/.commandcode/providers.json with the catalog as its models, and sets settings.json's model to magpie/<provider>/<model>; its own models stay as they are, and default takes magpie's entry out; Command Code still wants its own sign-in (#32 )

2026-09-24 21:44:09 +08:00

commandcode.go

agent: an agent whose own config keeps the reasoning effort its sessions start with gets an effort field, as Codex, Grok and Pi have — Claude Code's effortLevel (low to xhigh; max lasts a session only), Hermes's agent.reasoning_effort, omp's defaultThinkingLevel, Goose's GOOSE_THINKING_EFFORT, Copilot's effortLevel (the model's levels when its list says), Crush's large model reasoning_effort, Command Code's reasoningEffort for the current model (it keeps one per model) and dsh's llm-deepseek reasoningEffort (off, high or max, kept when the model changes or the catalog syncs); OpenCode, Gemini CLI, Cursor, ZCode, Devin and Alma keep none of their own in a file, so they get none. Asked on Discord

2026-09-26 23:29:40 +08:00

devin_test.go

devin: fast runs are one model with an effort, and the Devin agent's own picker is families + effort too (蓝猫 on Discord: Fast 模型还是存在同样的问题，给 Agent 选择模型的时候还是同样显示) — v0.1.371 made each family one model with its efforts, but a variant with a tier after its effort (claude-opus-5-5-high-fast, gpt-6-sol-high-priority) still stood alone, one per level, and the Devin agent's model field still listed every variant flat. Now a family's fast (and priority) variants are one model, claude-opus-5-5-fast, whose effort the gateway turns into the variant at it (nearest level; the family's default with none asked), and ids ending -none join their family at none. The Devin agent offers the same families with an effort field beside the model; Devin's config has only agent.model, so the pair is written as the variant at the effort (the family's own id with none, so it keeps following the family) and read back apart. Ids an agent was set to before, and one typed in, go to Devin as they are; with Devin's list unreadable the id is read and written as it is. Checked against the real devin models list (85 models, the Opus fast runs low–max) and with tests of the agent's get/set on a temp config

2026-09-29 13:55:56 +08:00

devin.go

devin: fast runs are one model with an effort, and the Devin agent's own picker is families + effort too (蓝猫 on Discord: Fast 模型还是存在同样的问题，给 Agent 选择模型的时候还是同样显示) — v0.1.371 made each family one model with its efforts, but a variant with a tier after its effort (claude-opus-5-5-high-fast, gpt-6-sol-high-priority) still stood alone, one per level, and the Devin agent's model field still listed every variant flat. Now a family's fast (and priority) variants are one model, claude-opus-5-5-fast, whose effort the gateway turns into the variant at it (nearest level; the family's default with none asked), and ids ending -none join their family at none. The Devin agent offers the same families with an effort field beside the model; Devin's config has only agent.model, so the pair is written as the variant at the effort (the family's own id with none, so it keeps following the family) and read back apart. Ids an agent was set to before, and one typed in, go to Devin as they are; with Devin's list unreadable the id is read and written as it is. Checked against the real devin models list (85 models, the Opus fast runs low–max) and with tests of the agent's get/set on a temp config

2026-09-29 13:55:56 +08:00

dsh_test.go

agent: an agent whose own config keeps the reasoning effort its sessions start with gets an effort field, as Codex, Grok and Pi have — Claude Code's effortLevel (low to xhigh; max lasts a session only), Hermes's agent.reasoning_effort, omp's defaultThinkingLevel, Goose's GOOSE_THINKING_EFFORT, Copilot's effortLevel (the model's levels when its list says), Crush's large model reasoning_effort, Command Code's reasoningEffort for the current model (it keeps one per model) and dsh's llm-deepseek reasoningEffort (off, high or max, kept when the model changes or the catalog syncs); OpenCode, Gemini CLI, Cursor, ZCode, Devin and Alma keep none of their own in a file, so they get none. Asked on Discord

2026-09-26 23:29:40 +08:00

dsh.go

ui: a subscription's windows side by side put every count under its name once one's doesn't fit beside it, not one up by its name and the next a line below (#90 ); a provider's models can be picked all at once (those the filter shows) or none, and their list scrolls on its own, not the editor with it (#115 ); DeepSeek Harness's own models are listed under its name, apart from magpie's DeepSeek provider, which read as DeepSeek twice (#115 ); Hide emails says when it is on — a struck eye, 邮箱已打码 and the accent, an open eye while emails show

2026-09-27 21:38:25 +08:00

effort_test.go

agents: OpenHanako — magpie is a provider there, chat completions at the gateway's /v1 under the key magpie-hanako with every model it serves, their windows, output, images and reasoning said; picking one makes it the primary agent's chat model, and default puts back the one it had and removes the provider, marked deleted as OpenHanako marks one it removes. While OpenHanako runs it goes through its local API (server-info.json's port and token), which reloads at once; otherwise into provider-catalog.json and agents/<id>/config.yaml for its next start. Asked on Discord; checked with OpenHanako's own provider registry and model manager, which list magpie's models and resolve the chat model to the gateway

2026-09-28 01:12:46 +08:00

fx_test.go

agent: fx (fx.sh, Vercel Labs' coding agent) — its model picked in magpie like any agent's; a model through magpie adds magpie to ~/.fx/settings.json as a keyless provider of fx's own (openai-chat-completions at the gateway, auth none) with the catalog as its model_metadata, the model in use first so fx's 256-model limit never cuts it, and sets provider magpie and models.magpie; its own models stay as they are, and default takes magpie's entry out. fx sends no effort to such a provider, so there is none to pick. Tested live from a sandbox: fx 0.0.11 listed magpie's models and read and wrote files through several tool rounds on DeepSeek

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

fx.go

agent: fx (fx.sh, Vercel Labs' coding agent) — its model picked in magpie like any agent's; a model through magpie adds magpie to ~/.fx/settings.json as a keyless provider of fx's own (openai-chat-completions at the gateway, auth none) with the catalog as its model_metadata, the model in use first so fx's 256-model limit never cuts it, and sets provider magpie and models.magpie; its own models stay as they are, and default takes magpie's entry out. fx sends no effort to such a provider, so there is none to pick. Tested live from a sandbox: fx 0.0.11 listed magpie's models and read and wrote files through several tool rounds on DeepSeek

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

gemini.go

models: each agent can be shown only some of them — a provider or group gets a family (magpie provider set relay-x family=relay), and magpie visible zcode relay shows zcode only that family's models (or named providers and groups): in the files magpie writes for it and in what /v1/models answers it, told apart by its User-Agent; magpie models zcode lists what it is shown and what is kept from it, and magpie visible zcode all shows it everything again. A model kept from an agent is still served when asked for by name. Asked for on Discord

2026-09-26 16:02:29 +08:00

goose_test.go

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

grok_test.go

agent: TOML tables magpie edits end where the parser says — a table no longer swallows the [[skills.config]] blocks that follow it. A write that would leave an invalid config is refused with its file, line and column

2026-09-26 13:46:03 +08:00

grok.go

models: each agent can be shown only some of them — a provider or group gets a family (magpie provider set relay-x family=relay), and magpie visible zcode relay shows zcode only that family's models (or named providers and groups): in the files magpie writes for it and in what /v1/models answers it, told apart by its User-Agent; magpie models zcode lists what it is shown and what is kept from it, and magpie visible zcode all shows it everything again. A model kept from an agent is still served when asked for by name. Asked for on Discord

2026-09-26 16:02:29 +08:00

hanako_test.go

agents: OpenHanako — magpie is a provider there, chat completions at the gateway's /v1 under the key magpie-hanako with every model it serves, their windows, output, images and reasoning said; picking one makes it the primary agent's chat model, and default puts back the one it had and removes the provider, marked deleted as OpenHanako marks one it removes. While OpenHanako runs it goes through its local API (server-info.json's port and token), which reloads at once; otherwise into provider-catalog.json and agents/<id>/config.yaml for its next start. Asked on Discord; checked with OpenHanako's own provider registry and model manager, which list magpie's models and resolve the chat model to the gateway

2026-09-28 01:12:46 +08:00

hanako.go

agents: OpenHanako — magpie is a provider there, chat completions at the gateway's /v1 under the key magpie-hanako with every model it serves, their windows, output, images and reasoning said; picking one makes it the primary agent's chat model, and default puts back the one it had and removes the provider, marked deleted as OpenHanako marks one it removes. While OpenHanako runs it goes through its local API (server-info.json's port and token), which reloads at once; otherwise into provider-catalog.json and agents/<id>/config.yaml for its next start. Asked on Discord; checked with OpenHanako's own provider registry and model manager, which list magpie's models and resolve the chat model to the gateway

2026-09-28 01:12:46 +08:00

hermes_test.go

agent: add Hermes Agent (#49 ) — magpie adds itself to ~/.hermes/config.yaml ($HERMES_HOME) as the provider "magpie" under providers (the gateway as chat completions, the catalog as its models) and points model.provider at it, with the model in model.default; the provider and model the user had are stashed and put back when they pick one of Hermes's own or go back to the default. Hermes sends its own User-Agent only from a recent release on, so the entry sets it for the gateway's usage view

2026-09-25 09:08:08 +08:00

hermes.go

agent: an agent whose own config keeps the reasoning effort its sessions start with gets an effort field, as Codex, Grok and Pi have — Claude Code's effortLevel (low to xhigh; max lasts a session only), Hermes's agent.reasoning_effort, omp's defaultThinkingLevel, Goose's GOOSE_THINKING_EFFORT, Copilot's effortLevel (the model's levels when its list says), Crush's large model reasoning_effort, Command Code's reasoningEffort for the current model (it keeps one per model) and dsh's llm-deepseek reasoningEffort (off, high or max, kept when the model changes or the catalog syncs); OpenCode, Gemini CLI, Cursor, ZCode, Devin and Alma keep none of their own in a file, so they get none. Asked on Discord

2026-09-26 23:29:40 +08:00

icons.go

agent(picker): a provider an agent is signed in to on its own is named and shown as itself — "GitHub Copilot" with Copilot's logo in OpenCode's picker rather than "github-copilot" under the first model's Claude logo, "Anthropic" rather than "anthropic"

2026-09-25 04:48:12 +08:00

image_input_test.go

models: each agent can be shown only some of them — a provider or group gets a family (magpie provider set relay-x family=relay), and magpie visible zcode relay shows zcode only that family's models (or named providers and groups): in the files magpie writes for it and in what /v1/models answers it, told apart by its User-Agent; magpie models zcode lists what it is shown and what is kept from it, and magpie visible zcode all shows it everything again. A model kept from an agent is still served when asked for by name. Asked for on Discord

2026-09-26 16:02:29 +08:00

kimi_test.go

agents: Kimi Code, Moonshot's kimi CLI, is an agent magpie sets up (agent求个kimi code支持) — it keeps its settings in ~/.kimi/config.toml ($KIMI_SHARE_DIR's), its default_model a key of its [models."…"] tables, each naming a [providers.…] one. Picking a model through magpie adds the provider "magpie" (the gateway, as Kimi's own chat completions type, so the thinking goes out as reasoning_effort and comes back, and is sent back, as reasoning_content) and a table per catalog model keyed "magpie/<provider>/<model>", with its context (128K when not known) and thinking/image_in capabilities, so the catalog is in Kimi's /model picker and kept up to date as providers change; the Kimi Code sign-in's default is stashed and put back on reset, and the tables go in and out in the order Kimi's own check wants (a default or a provider it can't find makes it refuse the file). Its requests are Kimi Code's in usage (KimiCLI/…). The gateway also drops Kimi's thinking: {type: …} on a request relayed to api.openai.com, as it does Qwen's enable_thinking. Tested: the config in the shape a Kimi Code sign-in leaves it (set, sync, a moved base_url, reset, its own model, no config at all), and the real kimi 1.24.0 --print against a sandbox gateway and a fake upstream: reply and thinking shown, reasoning_effort high on a thinking model, reasoning_content sent back on the next turn, usage under Kimi Code; not with a real vendor behind it

2026-09-29 16:36:35 +08:00

kimi.go

agents: Kimi Code, Moonshot's kimi CLI, is an agent magpie sets up (agent求个kimi code支持) — it keeps its settings in ~/.kimi/config.toml ($KIMI_SHARE_DIR's), its default_model a key of its [models."…"] tables, each naming a [providers.…] one. Picking a model through magpie adds the provider "magpie" (the gateway, as Kimi's own chat completions type, so the thinking goes out as reasoning_effort and comes back, and is sent back, as reasoning_content) and a table per catalog model keyed "magpie/<provider>/<model>", with its context (128K when not known) and thinking/image_in capabilities, so the catalog is in Kimi's /model picker and kept up to date as providers change; the Kimi Code sign-in's default is stashed and put back on reset, and the tables go in and out in the order Kimi's own check wants (a default or a provider it can't find makes it refuse the file). Its requests are Kimi Code's in usage (KimiCLI/…). The gateway also drops Kimi's thinking: {type: …} on a request relayed to api.openai.com, as it does Qwen's enable_thinking. Tested: the config in the shape a Kimi Code sign-in leaves it (set, sync, a moved base_url, reset, its own model, no config at all), and the real kimi 1.24.0 --print against a sandbox gateway and a fake upstream: reply and thinking shown, reasoning_effort high on a thinking model, reasoning_content sent back on the next turn, usage under Kimi Code; not with a real vendor behind it

2026-09-29 16:36:35 +08:00

legacy_test.go

provider: Cursor's per-effort picks become the model with efforts (Leo: Cursor 旧模型清单没有迁移) — a Cursor model list picked before each family was one model still named grok-4.7-low … -xhigh and the -fast ones, so /v1/models and the model lists written for agents (Pi's models.json) kept those ids with no reasoning, and Pi never sent reasoning_effort. Now each saved pick that is one of Cursor's ids at an effort is the family magpie offers for it (grok-4.7, grok-4.7-fast), in the order picked, once; ids of a family of one stay. An agent set to such an id (magpie/cursor/grok-4.7-low) is moved at start-up to the family, spelled its way, and to the effort the id was at when its own is unset and it has that one; a model the picker doesn't offer is left. A request naming one of Cursor's own ids with a reasoning_effort goes at that effort where Cursor has the id (grok-4.7-low at high is grok-4.7-high), else as named; and Chat Completions' service_tier: priority asks for the fast id as Responses' does. Tested with sandbox HOME/cache: legacy picks → grok-4.7|low,medium,xhigh, grok-4.7-fast; a sandbox Pi moved to curs/grok-4.7 at low

2026-09-28 19:59:08 +08:00

legacy.go

provider: Antigravity's models at several levels are one model with those levels (#150 : 统一 Antigravity 模型变体与客户端推理档位的映射) — Antigravity lists gemini-3.7-flash-low, -medium and -high as three models, "Gemini 3.7 Flash (Low)" …, so a client picked a level twice: once in the model, once as its reasoning effort, with no telling which won. Now ids that are one id with an effort word after it (-low, -medium, -high, -extra-low, -minimal, -xhigh) are one model, gemini-3.7-flash "Gemini 3.7 Flash", declaring only the levels there are (low,medium,high; Gemini 3.1 Pro low,high), so Codex, Pi and the rest get reasoning levels for it. The level a variant is at is what Antigravity's name says where each name says a different one (gemini-3.5-flash-extra-low is "(Low)", gemini-3.5-flash-low "(Medium)"), else its id's word; a model only named like another (gemini-3-flash-agent, "Gemini 3.5 Flash (High)"; gemini-pro-agent) or with no sibling (gpt-oss-120b-medium) stays as listed. A request asks for the variant the effort picks, an effort it lacks at the nearest level (xhigh is high; medium on low/high is high); with none asked, the id without a level if Antigravity has one, else high — what Gemini 3 does unasked — else the highest. A variant's request carries no thinkingLevel, so the id and the level can't disagree. An old variant id still works: as named with no effort, and moved to the effort asked for. Saved picks and agents set to a variant (antigravity/gemini-3.7-flash-high) are moved to the family, at that level where the agent's own is unset, as Cursor's are. For Gemini 3 models without variants, medium now goes as medium to Flash (which takes minimal/low/medium/high) and still as high to Pro (low/high). Tested against the list an account's fetchAvailableModels gave (sandbox cache)

2026-09-28 20:10:00 +08:00

modelprefs_test.go

models: a provider's model can go by a name of the user's, and offer only some of its reasoning levels — Claude Opus 5.5 · Claude Code can be Opus 5.5, and a model with six levels can offer just low, medium and high. Both are kept in settings.json by provider/model (modelNames, modelEfforts), apart from the vendor's list, so a Refresh, a restart or an upgrade leaves them, and the same model from another provider keeps its own; a provider renamed takes them along. They are applied where the catalog is made, so the gateway's /v1/models, the lists magpie writes into the agents (Codex's model catalog, ZCode, Pi, OpenCode, OMP …) and magpie's own pages all show them, and a change rewrites the agents' lists as any other change of the catalog does. Only what is shown changes: the id, where requests go, and the levels the vendor is asked at stay as they were; a found routing group keeps the model's own name. The provider's editor has Names & levels under its models — a name typed in place, a tick per level, Restore default — and the terminal has magpie model name <provider/model> <name>|--reset and magpie model efforts <provider/model> low,medium,high|--reset. Issue #92

2026-09-26 23:23:45 +08:00

omp_test.go

agent: omp (oh-my-pi) — its model picked in magpie like any agent's; a model through magpie adds magpie as a keyless provider in ~/.omp/agent/models.yml with the catalog as its models, and sets config.yml's modelRoles.default to magpie/<provider>/<model>; its other roles and the rest of both files stay as they are, comments too, and default takes magpie's entry out unless another role still uses it (#34 )

2026-09-24 22:36:15 +08:00

omp.go

agent: an agent whose own config keeps the reasoning effort its sessions start with gets an effort field, as Codex, Grok and Pi have — Claude Code's effortLevel (low to xhigh; max lasts a session only), Hermes's agent.reasoning_effort, omp's defaultThinkingLevel, Goose's GOOSE_THINKING_EFFORT, Copilot's effortLevel (the model's levels when its list says), Crush's large model reasoning_effort, Command Code's reasoningEffort for the current model (it keeps one per model) and dsh's llm-deepseek reasoningEffort (off, high or max, kept when the model changes or the catalog syncs); OpenCode, Gemini CLI, Cursor, ZCode, Devin and Alma keep none of their own in a file, so they get none. Asked on Discord

2026-09-26 23:29:40 +08:00

opencode_variants_test.go

agent: OpenCode's magpie models name the reasoning levels each really has as variants ({level: {reasoningEffort: level}}, an empty set for a model without any) — OpenCode 2 otherwise makes low, medium and high of its own for every openai-compatible model (packages/core/src/variant.ts), so a model with none/high/max or none at all was offered levels it doesn't take; OpenCode 1 merges the same variants as before (kkgg)

2026-09-28 16:36:01 +08:00

pi_api_test.go

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

pi_scope_test.go

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

pi_test.go

agent: Pi offers xhigh and max for models that have them

2026-09-24 11:15:59 +08:00

pi.go

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

qoder_test.go

agents: the effort picked for Cline and Qoder is the one they use — Cline's reasoning is written {enabled:true,effort} ({enabled:false} for none), as its own pickers leave an enabled false that drops an effort beside it, and such a one reads as none; Cline's VS Code extension (4.x), which takes its provider, model, base URL and key from globalState.json and secrets.json before providers.json, has those set too where they are, stashed and put back on the way out, and $CLINE_DATA_DIR is honoured. Qoder (1.1.6x) keeps each model's effort in model.preferences and moves model.reasoningEffort there once: magpie sets the model's preference (a model id with dots too), carries the effort in use to a model with none of its own, and keeps reasoningEffort for older Qoders. Cline's desktop app keeps its composer's model and effort in its web view's storage, which magpie leaves alone; its notice says to pick there

2026-09-28 13:41:31 +08:00

qoder.go

agents: the effort picked for Cline and Qoder is the one they use — Cline's reasoning is written {enabled:true,effort} ({enabled:false} for none), as its own pickers leave an enabled false that drops an effort beside it, and such a one reads as none; Cline's VS Code extension (4.x), which takes its provider, model, base URL and key from globalState.json and secrets.json before providers.json, has those set too where they are, stashed and put back on the way out, and $CLINE_DATA_DIR is honoured. Qoder (1.1.6x) keeps each model's effort in model.preferences and moves model.reasoningEffort there once: magpie sets the model's preference (a model id with dots too), carries the effort in use to a model with none of its own, and keeps reasoningEffort for older Qoders. Cline's desktop app keeps its composer's model and effort in its web view's storage, which magpie leaves alone; its notice says to pick there

2026-09-28 13:41:31 +08:00

rename.go

providers: a provider's id can change — its editor has an ID field (magpie provider set <id> id=<new> in the CLI), and renaming it moves what named it by the old one: the agents on its models (each spelled its own way, recorded as magpie's), the routing groups' members, rules and classifier, other providers' fallbacks, which agents are shown it, and the vendor's fetched list. The old id stays with it, so an agent still running on the old config reaches it, a profile saved before applies to the new id, and its usage so far is counted under the new one. Asked on Discord

2026-09-26 20:22:30 +08:00

route.go

cursor: a model's name no longer says its context, a grey 1M beside it does (Leo on Discord: Cursor 模型的展示名仍保留上游文本中的 1M) — Cursor names its large models "Claude Opus 5.5 1M", and magpie showed that as the name while it already kept the 1M as the model's context. The name now leaves it out ("(1M)" too); a name that would then be another model's ("GPT-5.5 Mini (1M)" beside "GPT-5.5 Mini") keeps it, as that is what tells them apart. Ids, efforts and the Cursor id each request goes to are unchanged, and a name the user gave still wins. So the context still shows, a model holding a million tokens or more has a small grey 1M by its name in the provider's models, the gateway's list and the model picker. Tested with a fake Cursor list in a sandbox magpie web, dark and light

2026-09-29 13:26:16 +08:00

spell_test.go

cli: a model typed as another agent spells it is put the way this one does — magpie/copilot/gpt-6 for Codex, which names catalog models copilot/gpt-6, and copilot/gpt-6 for Pi, which names them magpie/copilot/gpt-6 — rather than written as it is, where Codex took it for one of OpenAI's own and asked OpenAI for it; a magpie/… model the catalog doesn't have is refused, and a model the agent's picker doesn't list is still taken as it is

2026-09-25 05:34:44 +08:00

standin_test.go

gateway: a model Claude Code names that magpie doesn't serve goes to the one it is set to use for that tier — claude-haiku-4-5-… for a title or a small task goes to its haiku tier's model, opus and sonnet to theirs, a name of no tier to its main model, rather than to some provider that happens to list the name and wasn't picked for it. Other agents, and ids magpie shows, are sent as asked

2026-09-28 13:25:25 +08:00

stash.go

Rename dial to magpie, with a magpie for a logo

2026-09-23 23:55:11 +08:00

sync_test.go

agents: OpenHanako — magpie is a provider there, chat completions at the gateway's /v1 under the key magpie-hanako with every model it serves, their windows, output, images and reasoning said; picking one makes it the primary agent's chat model, and default puts back the one it had and removes the provider, marked deleted as OpenHanako marks one it removes. While OpenHanako runs it goes through its local API (server-info.json's port and token), which reloads at once; otherwise into provider-catalog.json and agents/<id>/config.yaml for its next start. Asked on Discord; checked with OpenHanako's own provider registry and model manager, which list magpie's models and resolve the chat model to the gateway

2026-09-28 01:12:46 +08:00

sync.go

agents: a model through magpie tells Pi, Crush, omp and Codex how much it holds, and a provider added, edited or removed reaches the model lists agents keep in files of their own — the catalog carried no context window, so Pi took every model through magpie for a 128K one (a CLIProxyAPI's gpt-5.5 holds 922K) and Crush for a 200K one; each model now carries models.dev's input limit, else its context, looked up by bare id as most of the providers serving it give it (a proxy's "openai/gpt-5.4", "gpt-5.4(high)", "glm-4.6:free" find it too; a group holds the least of its members'). And those lists were written only when a model was picked: Codex's magpie-models.json, Pi's models.json, OpenCode's, Crush's, Command Code's, omp's and Hermes' provider blocks and dsh's llm-deepseek entry kept the catalog as it was then, so a provider added later never showed. Saving a provider, a vendor's list fetched anew or models.dev synced now rewrites each one magpie wrote, where it differs, and the app does once at start-up; a Codex signed in to ChatGPT, which asks the gateway, kept its cached list under the backend's ETag, which a change of magpie's never changed — the ETag (and a reply's X-Models-Etag) now carries a tag of magpie's models, and a cache from before a change is aged so the next Codex asks again

2026-09-25 12:32:14 +08:00

useragent_test.go

agents: OpenHanako — magpie is a provider there, chat completions at the gateway's /v1 under the key magpie-hanako with every model it serves, their windows, output, images and reasoning said; picking one makes it the primary agent's chat model, and default puts back the one it had and removes the provider, marked deleted as OpenHanako marks one it removes. While OpenHanako runs it goes through its local API (server-info.json's port and token), which reloads at once; otherwise into provider-catalog.json and agents/<id>/config.yaml for its next start. Asked on Discord; checked with OpenHanako's own provider registry and model manager, which list magpie's models and resolve the chat model to the gateway

2026-09-28 01:12:46 +08:00

workbuddy_test.go

agent: WorkBuddy takes magpie's models (能否作为Agent的支持WorkBuddy) — a WorkBuddy agent whose provider field puts every magpie model into WorkBuddy's picker: entries in ~/.workbuddy/models.json ($WORKBUDDY_CONFIG_DIR), the custom-model list WorkBuddy reads and watches (no restart), as OpenAI chat-completions models at the gateway's /v1/chat/completions under magpie-workbuddy, with each model's context, output, images and reasoning levels (reasoning.supportedEfforts, canDisableThinking where it can think off). WorkBuddy's own entries (its local models) and the CLI's {models, availableModels} form are kept; a magpie model turned off in WorkBuddy stays off; off takes only magpie's out. Its requests say CLI/<ver> WorkBuddy/<ver>, so they're known by the key. Tested with WorkBuddy 5.5.6's own CLI against a sandbox gateway: deepseek/deepseek-v4-pro answered, reasoning_effort sent, usage under WorkBuddy

2026-09-28 19:24:40 +08:00

workbuddy.go

agent: WorkBuddy takes magpie's models (能否作为Agent的支持WorkBuddy) — a WorkBuddy agent whose provider field puts every magpie model into WorkBuddy's picker: entries in ~/.workbuddy/models.json ($WORKBUDDY_CONFIG_DIR), the custom-model list WorkBuddy reads and watches (no restart), as OpenAI chat-completions models at the gateway's /v1/chat/completions under magpie-workbuddy, with each model's context, output, images and reasoning levels (reasoning.supportedEfforts, canDisableThinking where it can think off). WorkBuddy's own entries (its local models) and the CLI's {models, availableModels} form are kept; a magpie model turned off in WorkBuddy stays off; off takes only magpie's out. Its requests say CLI/<ver> WorkBuddy/<ver>, so they're known by the key. Tested with WorkBuddy 5.5.6's own CLI against a sandbox gateway: deepseek/deepseek-v4-pro answered, reasoning_effort sent, usage under WorkBuddy

2026-09-28 19:24:40 +08:00

wsl_test.go

agent: a WSL distro that isn't running is never started to be looked at — any access to its files through \\wsl.localhost starts it — so only running distros (wsl.exe -l --running -q) are probed, once each, and those Codex is in are kept in wsl.json beside magpie's settings (not the stash, which profiles and backups carry) with their fields as last read; a stopped one stays listed as magpie last saw it, with a notice saying so, no path, and nothing checked, synced or migrated, so the minute's list, Detected and Current never open it; picking a value is the user asking, so it starts the distro with wsl.exe -d <distro> -e true first (opening a stopped distro's files is aborted rather than waited for) and then writes, keeping what it wrote at once; a distro no longer installed is forgotten, and one without Codex isn't kept. Tested on the Windows box with a throwaway Alpine distro: listed while running, then after wsl --terminate listed with its last model and effort by magpie ls and magpie codex@wsl:<distro> with wsl -l -v still showing it Stopped, then a model set on it started it, wrote its config and updated wsl.json

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

wsl_windows_test.go

agent: the Windows-only WSL test builds again — wslList returns the names and whether wsl.exe answered, and the test took it as the names alone

2026-09-28 17:43:10 +08:00

wsl.go

agent: a WSL distro that isn't running is never started to be looked at — any access to its files through \\wsl.localhost starts it — so only running distros (wsl.exe -l --running -q) are probed, once each, and those Codex is in are kept in wsl.json beside magpie's settings (not the stash, which profiles and backups carry) with their fields as last read; a stopped one stays listed as magpie last saw it, with a notice saying so, no path, and nothing checked, synced or migrated, so the minute's list, Detected and Current never open it; picking a value is the user asking, so it starts the distro with wsl.exe -d <distro> -e true first (opening a stopped distro's files is aborted rather than waited for) and then writes, keeping what it wrote at once; a distro no longer installed is forgotten, and one without Codex isn't kept. Tested on the Windows box with a throwaway Alpine distro: listed while running, then after wsl --terminate listed with its last model and effort by magpie ls and magpie codex@wsl:<distro> with wsl -l -v still showing it Stopped, then a model set on it started it, wrote its config and updated wsl.json

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

zcode_test.go

agent(zcode): a magpie model tells ZCode how long a reply may be and how hard it can think — ZCode's model dialog showed 32000 max output tokens and thinking only on or off for every magpie model. config.json's models now carry limit.output and reasoning {enabled, variants, defaultVariant} (medium where the model has it, else its middle level; none is ZCode's disabled), and provider_config.json's rules, which ZCode 3.14 reads, carry optionSpecs {maxOutputTokens.max, reasoningLevel.values}, as ZCode's own rules do. An output over 128000 is capped: some vendors report their window there (grok's 500000). Asked on Discord

2026-09-26 23:04:38 +08:00

zcode.go

agent(zcode): a magpie model tells ZCode how long a reply may be and how hard it can think — ZCode's model dialog showed 32000 max output tokens and thinking only on or off for every magpie model. config.json's models now carry limit.output and reasoning {enabled, variants, defaultVariant} (medium where the model has it, else its middle level; none is ZCode's disabled), and provider_config.json's rules, which ZCode 3.14 reads, carry optionSpecs {maxOutputTokens.max, reasoningLevel.values}, as ZCode's own rules do. An output over 128000 is capped: some vendors report their window there (grok's 500000). Asked on Discord

2026-09-26 23:04:38 +08:00