yetone
ea6a5f53e7
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
yetone
7dff31fc46
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
yetone
52b3ad3a9e
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
yetone
5f73e4f4fc
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
yetone
6e677aabb6
codex: a thread started with magpie as Codex's provider opens again, and Codex can be kept in its API state ( #129 ) — signed in to ChatGPT, a magpie model is routed with openai_base_url ( c3931c9), and moving there from magpie as the provider (an older magpie's wiring, or one made while the account had used its allowance up, bd5bf42) took [model_providers.magpie] away, so the Codex app, which resumes a thread on the provider it was started on, said "Model provider magpie not found" for every one of them and came back signed in to ChatGPT. The table now stays once written, a base-URL wiring writes it too, and a sync puts back one an older magpie took away. Codex gets a sign-in field (magpie codex login api, a small square beside its pickers): api keeps magpie as Codex's provider while it is signed in, the app in its API state with magpie's models only; ChatGPT, the default, is as before
2026-09-28 14:11:17 +08:00
yetone
4eead4d4e0
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
yetone
4cbd96a3e4
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
yetone
31169a17f6
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
yetone
6c9a0aa4d7
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
yetone
c76af6822f
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
yetone
b87a3ce360
agents: Qoder is known as Qoder, not Bun — Qoder CLI is a Bun single-file build whose requests carry Bun's User-Agent and nothing of Qoder's, so magpie's provider in Qoder (and Qoder CN) now carries the key magpie-qoder (magpie-qoder-cn), which the gateway knows an agent by before its User-Agent: usage, the routing view and the models it is shown say Qoder. A Qoder wired before with the key magpie is still magpie's and gets the new key on the next sync, as magpie starts
2026-09-27 20:59:38 +08:00
yetone
c025a927d7
library: DeepSeek Harness (dsh) gets the library — its MCP servers as marked inserts of the dsh-mcp-client plugin in every profile's cordis.patch.yml (id magpie-mcp-<name>), a row the user inserted read like any other agent's and one holding a !!js value left alone; AGENTS.md and skills in its folder. SSE servers and names dsh can't take are refused with a reason ( #107 )
2026-09-27 17:22:03 +08:00
yetone
1d4930dd8e
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
yetone
f7e38d0d2e
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
yetone
c1d38cc50f
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
smallnest
03a01a548d
agent: MiMo Code — Xiaomi's fork of OpenCode, sharing its config shape ( #98 )
...
* agent: MiMo Code — a terminal coding assistant that is Xiaomi's fork of OpenCode, whose config keeps OpenCode's shape: its own mimocode.json(c) under ~/.config/mimocode, its auth beside it, and a magpie provider block with npm/@ai-sdk/openai-compatible, model and small_model fields. opencode() becomes openCodeLike() for the two to share it, and magpieProviderJSON splits shape from the catalog id (magpieProviderJSONFor), so a visibility narrowed on mimocode (magpie visible mimocode …) narrows its list and leaves OpenCode's alone. The library gives it the same instructions, MCP servers (its mcp key) and skills as OpenCode, except the shared skills go into its own skills/ folder: it reads Claude Code's skills only behind a flag, though it reads its CLAUDE.md like OpenCode, and the page says so. Its requests are told by the mimocode/ User-Agent. Checked against XiaomiMiMo/MiMo-Code
* icon: MiMo Code's own favicon, from packages/ui/src/assets/favicon — its frame with the bottom bar, in the monochrome the app masks to the text colour
2026-09-27 08:42:44 +08:00
yetone
55afcdd4bb
agents: Qoder CN — qoderclicn, the China site's build of Qoder's CLI, is the same CLI with its own accounts and its settings in $QODERCN_CONFIG_DIR, ~/.qoder-cn by default; magpie wires it as it does Qoder, a magpie custom provider with every magpie model and model.name/model.reasoningEffort, as its own agent
2026-09-27 08:05:12 +08:00
yetone
84f001da08
agents: Cline lists every magpie model — its built-in openai-compatible provider knows only gpt-4o, so /model offered that alone and the rest had to be typed in one by one. magpie now puts its models in models.json beside providers.json, as the entry Cline's own migration writes for openai-compatible (provider name, baseUrl, defaultModelId, and the models with their context, output, images and reasoning), which takes the place of the built-in list; the user's entry there is stashed and put back when magpie steps out, and Sync keeps the list current. Tested live with Cline 3.0.65's TUI against a sandbox gateway: /model shows provider magpie with every magpie model, picking one runs the turn on it, and magpie reads the pick back
2026-09-27 07:30:59 +08:00
yetone
cae88f031c
agents: Qoder — magpie's models in Qoder's CLI (1.1) as a "magpie" custom provider in ~/.qoder/settings.json ($QODER_CONFIG_DIR): picking magpie/<model> or a routing group writes the provider, with every magpie model, its context, output, images and the efforts it takes, and makes it model.name; the effort is model.reasoningEffort. The comments and entries of the user's settings stay, and stepping out of magpie takes its provider away and puts back the model the user had. Qoder offers custom providers only to a signed-in account whose plan has BYOK. It asks every model for enable_thinking, which OpenAI's API refuses, so that is dropped for openai.com. Tested live: magpie → settings.json → qodercli -p → magpie's gateway → upstream, the reply streamed back
2026-09-27 06:28:14 +08:00
yetone
0f7e90b4f2
agents: Cline — its CLI's model and effort can be one of magpie's. A provider of Cline's own is refused when a session starts ( cline/cline#14180 ), so magpie takes Cline's built-in openai-compatible provider and makes it the one in use: the gateway, magpie's token, the model, a User-Agent that names Cline (its requests say only AI SDK), and the effort under reasoning.effort. What the user had there, and the provider in use, are stashed and put back when magpie steps out. Tested live with Cline 3.0.65 against a sandbox gateway: the turn comes back and the usage is Cline's
2026-09-27 06:08:58 +08:00
yetone
9b1641a493
opencode: a model chosen for OpenCode that a provider of the config's own already sends to magpie's gateway is named under that provider — a layout of one provider per family (magpie-relay, magpie-claude, …) is no longer doubled by magpie's flat provider with the same models, nor the default model moved onto it, by magpie opencode <model>
2026-09-27 02:26:12 +08:00
yetone
6694108bf2
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
yetone
47e12df418
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
yetone
c0b296b300
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
796dac8de9
agent(pi): a magpie model tells Pi how long a reply may be — maxTokens from the model's output limit, where Pi otherwise capped every reply at 16384 tokens ( #91 )
...
* agent(pi): a model through magpie tells Pi how long a reply may be — Pi's models.json got contextWindow but no maxTokens, so Pi capped every reply at its default 16384 tokens, Claude Opus and GPT groups that can write 128K included; each model now carries maxTokens when its output is known (a group's is the smallest of its members'), as DSH and OpenCode's limit.output already do
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
* drop internal/provider/devin/config.json, a file a provider test leaves behind
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com >
Co-authored-by: yetone <kumw95ya25@gmail.com >
2026-09-26 22:57:15 +08:00
yetone
ea5d089b4a
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
Zhizhen He and Claude Code
f2a30647d0
edit: a table's name is the parser's own key path, so [ a . b ] is the table a.b — space or tab around the dots of a header (both valid TOML) is not part of the name; a provider table a user wrote that way is reused in place, edited and taken away again as if magpie had written it, where before it was invisible and magpie appended a duplicate, refused as invalid TOML
...
Co-Authored-By: Claude Code <noreply@anthropic.com >
2026-09-26 21:12:32 +08:00
yetone
0f0b8fc87e
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
yetone
c4268e524f
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
yetone
7a3c434610
agents: Alma — magpie wires it through Alma's local API (localhost:23001, while Alma runs): choosing one of magpie's models for Alma adds a provider named magpie there (OpenAI type, the gateway's /v1, key magpie), offers magpie's models in it and makes the model Alma's default chat model, the rest of Alma's settings and its other providers left as they are; the list is kept current as magpie's catalog changes, and going back to Alma's own takes magpie's provider out. Asked on Discord
2026-09-26 19:18:51 +08:00
yetone
d05763a5dc
opencode: each model of magpie's carries its window (limit.context), a group's context= with it, so OpenCode compacts when the model needs it and not at its own guess; and magpie sync puts magpie's provider back into opencode.json when a model of magpie's is chosen there but the provider is gone. /v1/models says each model's window too (context_window, context_length, max_input_tokens, max_output_tokens). Asked on Discord
2026-09-26 18:50:04 +08:00
yetone
5dbd28c39e
zcode: what you choose in ZCode for magpie stays — the provider turned off stays off, its rule stays where you moved it, and a rule you removed isn't put back on the next sync. gateway: a model that always thinks (GLM-5.3 answers 1210 to thinking turned off) is asked again with thinking left to it, rather than failing. Asked on Discord
2026-09-26 18:45:49 +08:00
yetone
f0bd9fac87
cursor: its models have a context window — 1M for the ones Cursor names 1M, else 200K (less where the model's own is smaller), so Codex, Pi, OpenCode, Crush and the rest no longer take them for a small or unknown window; and Claude Code is given a 1M model as <id>[1m], its mark for one, so it no longer compacts at 200K (it drops the mark before asking, and magpie takes a value with it too). Asked on X
2026-09-26 17:49:06 +08:00
yetone
73be42eca8
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
Zhizhen He and Claude Code
f3d567e07e
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
...
Co-Authored-By: Claude Code <noreply@anthropic.com >
2026-09-26 13:46:03 +08:00
yetone
7174df1932
dsh: each magpie model says its context window, longest reply and whether it takes images — dsh otherwise takes a million tokens of context, 256K out and text only for every model, so a 128K model overflowed and a vision model was sent no images ( #81 ); the longest reply comes from the catalog's output limit, a group's is its members' least; older dsh ignores the fields it doesn't know
2026-09-26 12:42:11 +08:00
yetone
1de4bbc715
agent(zcode): magpie's models reach ZCode 3.14 — it moved its providers to ~/.zcode/v2/provider_config.json and reads config.json's only once, to import them, so a magpie provider set up since never showed in its picker; magpie now writes its provider rule (standard-personal, api-key access, anthropic-messages at the gateway) and a model rule per model (context window, images) there too, keeps every other rule and a model the user set by hand in ZCode, and leaves a provider turned off in ZCode off. Checked against ZCode's own schemas
2026-09-26 01:27:54 +08:00
yetone
a9aeb4d45f
agent(codex): a Codex that couldn't reach magpie says so — the Codex app writes no history.jsonl, so a Codex it started while magpie wasn't running (the gateway refused it, and it built its model list without magpie's) or before magpie set it up (its requests still went to chatgpt.com or an old port) looked fine; magpie now reads the newest model request Codex logged since it was set (logs_*.sqlite, read-only, a day at most) and shows Apply again with the time and why, and to quit and reopen Codex
2026-09-26 01:16:27 +08:00
yetone
1b5d1f87db
agent: every agent on a magpie model says when it was taken off magpie behind its back, not only Codex — each checks what magpie wired into it to reach the gateway (Claude Code's env base URL and token, and a managed-settings base URL that wins over them; Gemini CLI's .env and its auth type; OpenCode, Pi, Crush, Command Code, Hermes, omp and Grok Build's magpie provider; DeepSeek Harness's llm-deepseek entry and its key in .env), and one pointed elsewhere or gone shows Apply again with what is off in its tooltip; Claude Code, like Codex, is also said to be bypassed when it was used and nothing of it reached the gateway (its history.jsonl), and slash commands no longer count as use. A test takes every such agent off the gateway and back
2026-09-26 01:10:40 +08:00
yetone
04302b1e63
agent(codex): a Codex taken off magpie behind its back says so, with Apply again — something else rewriting config.toml (another switcher, an installer, a profile of its own) left the row showing a magpie model while Codex asked OpenAI for it, and the user blamed magpie; magpie now remembers what it set on each agent (applied.json) and tells three kinds of drift apart: the wiring gone (the provider table, catalog or base URL, or a profile overriding them), a magpie model replaced by one of Codex's own, and a Codex used since with none of its requests reaching the gateway (history.jsonl against when the gateway last saw it — an old process on an old config). A drifted row carries a coral Apply again pill on its name's line (a badge on the logo in the panel), the reason in its tooltip, Keep current settings in the row menu; the window asks /api/drift every 15s, so it shows without a reload
2026-09-26 01:05:19 +08:00
yetone
afd831980a
agent(zcode): the user-agent test knows ZCode's requests
2026-09-25 23:57:00 +08:00
yetone
c0cbf90eeb
agent(zcode): ZCode is an agent — its provider field puts every magpie model in ZCode's own model picker, as a provider named magpie in ~/.zcode/v2/config.json (kind anthropic, asked at the gateway's /v1/messages), kept in step with the catalog like OpenCode's list, and taken out again when cleared; its requests are known by the ZCode/ User-Agent ( #72 )
2026-09-25 23:53:59 +08:00
yetone
618f529fb5
agent(grok): Grok Build's terminal front end, grok-pager, is known by its User-Agent as Grok Build's shell is — its requests were drawn as an unknown client named grok-pager, with no logo
2026-09-25 21:22:22 +08:00
yetone
3173029853
agent: Grok Build starts on the model picked in magpie again — a signed-in grok takes xAI's remote campaign patches above config.toml, and the grok-4.7-launch campaign sets models.default to grok-4.7, so every new session started there whatever [models] default said (grok -p honoured it only without a sign-in). A default picked in magpie now writes [features] campaigns = false, a sync puts it back for a default already picked, and clearing the model removes it
2026-09-25 21:09:14 +08:00
yetone
f7112a9e9d
agents: Grok Build — xAI's grok CLI — is an agent: its model is set in ~/.grok/config.toml ($GROK_HOME), and a model through magpie adds the catalog there as [model."magpie/…"] tables pointed at the gateway with magpie's own key, so a request never carries the user's xAI sign-in and the catalog joins Grok's own models in /model; its effort is [models] default_reasoning_effort, its requests are known by grok-shell; the Grok subscription is called Grok Build too
2026-09-25 18:26:50 +08:00
herrkaefer
b5d47ca5e7
gateway: an image sent to a model that can't see is dealt with before it goes out, and one a tool returned no longer ends the chat ( #56 )
...
A model's image input is taken from models.dev and the provider's own list, and a group's from its members: only a model known to be text-only is refused an image — one whose support is unknown still gets it, and Codex, OpenCode and Pi are told which models take images. An image the user attaches for a text-only model answers 400 in the client's own format before the upstream is asked; an image earlier in the chat, or one a tool returned (Claude Code's Read, Codex's view_image, a Chat tool message), becomes a short text note, so a chat that met a picture carries on after a switch to a text-only model. Thanks @herrkaefer.
2026-09-25 15:39:56 +08:00
yetone
d6784bd114
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
yetone
e8b3be572c
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
yetone
09c635cf03
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
yetone
00744ca373
codex: subagents can be put on a magpie model of their own — Codex's spawn_agent tool lists only the first five models it knows, its own ahead of magpie's, so signed in a model spawning a subagent never saw a magpie model to pick; Codex gets a subagents field that writes [agents] default_subagent_model, the model a subagent starts on when none is asked for, offered once Codex runs through magpie and taken out again when it steps back to its own models
2026-09-25 09:23:33 +08:00
yetone