okooooooo/magpie
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2,515 Commits 1 Branch 0 Tags
main
Commit Graph
8 Commits
Author SHA1 Message Date
yetone d9bf7c1ccf zcode: the API format the user picks for magpie's provider in ZCode's settings stays theirs; a sync no longer puts Anthropic Messages back on every start (杰多夫 on Discord) 
What changed: zcodeRules wrote api.type "anthropic-messages" into
provider_config.json, and zcodeProviderJSON wrote kind "anthropic" into
config.json, on every sync (magpie's start, any catalog change). A user who
switched the provider to OpenAI Chat Completions or Responses in ZCode had it
switched back the next time magpie started. zcodeFormat now reads the format
already there and keeps it, in both files: provider_config.json's api.type
(ZCode 3.14 on) or config.json's kind (older ZCode), the one written last
where they differ, mapped as ZCode maps them (anthropic-messages/anthropic,
openai-chat-completions/openai-compatible, openai-responses/openai). A new
provider, or a format ZCode doesn't have, is Anthropic Messages as before.

Why it's safe: magpie's gateway answers all three at the same base address.
Checked with ZCode 0.16.9's own agent CLI (glm/zcode.cjs -p, run from a
copy under a sandbox HOME, never ~/.zcode) against a sandbox gateway with
the DeepSeek provider: anthropic-messages asks /v1/messages,
openai-chat-completions /chat/completions, openai-responses /responses, and
a tool-using turn (Read a.txt) answered 200 on each, to deepseek-flash.

What was run:
- TestZCodeKeepsUserFormat (new): a format picked in provider_config.json,
  for each of the three, survives two syncs and is carried to config.json's
  kind; one picked in config.json is carried to provider_config.json; an
  unknown one isn't kept. On the old zcode.go it fails: "picked
  openai-chat-completions: kind "anthropic", api "anthropic-messages"".
- Sandbox, real binaries: provider_config.json set to openai-responses,
  then `magpie zcode magpie`: the old build wrote anthropic-messages back,
  this one kept openai-responses (config.json kind openai). Then
  openai-chat-completions, resynced, and the real ZCode CLI ran a turn on the
  file magpie wrote, served over /chat/completions.
- gofmt -l; GOOS=linux and GOOS=windows go vet -tags nogui ./internal/agent;
  go test -tags nogui ./internal/agent under a temp HOME: ok.

The "bcww: Field required" 400 on Anthropic Messages is not part of this
commit: ZCode's real requests (captured from its CLI, plain and with web
search) to deepseek/deepseek-flash through magpie returned 200, and DeepSeek
answers schema errors in serde's words, not "Field required".
 2026-10-10 09:58:30 +08:00
yetone 63f83bf1e1 agent: a ZCode pointed at another machine's magpie in either of its files stays there in both (悠悠哥 on Discord: ZCode wired to the magpie on a NAS kept being switched back to the local one) — v0.1.812 kept a remote address per file only, but ZCode's own settings write provider_config.json alone, so a sync rewrote config.json to this machine's gateway and ZCode could take the provider back from it. A sync now reads magpie's provider in both files (zcodeKept): an address on another machine in either one is written to both, with its key; otherwise the gateway's. TestZCodeKeepsRemoteAddress edits each file alone to a NAS address and syncs; it fails on the old code (config http://127.0.0.1:3425, rules the NAS). Check chain under a temp HOME passes. 2026-10-05 00:52:06 +08:00
yetone 04d4bae323 agent: ZCode's magpie provider pointed at a magpie on another machine keeps that address and key when magpie syncs its models (Discord, 悠悠哥: ZCode connected in a local magpie for its model list, then its base URL and API key changed by hand in ZCode to a magpie deployed on a NAS, kept going back to the local gateway's, they guessed on each update) — ZCode's Sync, which runs whenever magpie's models change and brings the provider in ~/.zcode/v2/config.json and the rule in provider_config.json up to date, wrote options.baseURL/apiKey and config.api.baseUrl/access.apiKey as gateway.URL() and gateway.Token every time. A sync now keeps an address the provider holds whose host isn't this machine's loopback (onAnotherMachine: an http(s) URL with a host other than localhost, a loopback or unspecified IP), with its key (magpie's token where it has none), and refreshes only the models; one on loopback still follows the gateway, so a magpie on another port keeps rewiring it. Picking magpie in the agent's provider field (Set) points it at this magpie as before. TestZCodeKeepsRemoteAddress: a NAS address kept by a sync in both files while a new model arrives, a loopback one moved to the gateway, connecting in magpie resets a NAS one, and onAnotherMachine's cases. go vet, builds (darwin, GOOS=linux, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass. Not tried in ZCode itself with the reporter's NAS; the models listed are this magpie's, so one the NAS's magpie doesn't serve is refused there. 2026-10-04 11:45:08 +08:00
yetone 0361189f9e test: every package's tests pass on Windows, and none writes outside its sandbox (the user: 把 Windows 上那几个失败的测试修掉) — on a Windows box the suite failed in most packages, and the root package hung for 25 minutes. Tests set HOME, which os.UserHomeDir ignores on Windows (it reads USERPROFILE), so they read and wrote the runner's own home; each now sets USERPROFILE beside HOME, and Devin's, Goose's, Crush's and Claude Desktop's tests set APPDATA/LOCALAPPDATA, where those keep their files there. said() read the command's output only once it returned, and a pipe holds a few KB on Windows, so magpie model --help blocked forever; it reads while the command writes. Unix permission bits (the gateway key store's 0600 too), exec bits and symlinks Windows lacks are checked only off Windows; TOML strings hold Windows paths as literal strings, JSON as marshalled ones; a URL's path is compared as one. The provider and usage packages run in a home of their own (TestMain, as the gateway's already does), since a CLI's identity kept by a refresh still going when its test ended landed in the runner's ~/.config/magpie — and on a Mac in the user's own. Two product fixes came out of it: imagemcp took a file:///C:/… root or image for the path /C:/…, which doesn't exist on Windows, and now makes a Windows path of it (a host for a UNC share); and session discovery could keep a new Cowork session hidden on Linux, where a folder's mtime is a kernel tick and its size doesn't change, so an entry added within the tick of the last listing left both as they were — a listing made within 2s of its folder's last change is read again, as git does for racy files. TestFilePath and TestRacyDirectoryListedAgain fail without the change. On Windows 11 every package passes (32 of 32) and a run of each package in a fresh home leaves nothing in home, APPDATA or LOCALAPPDATA; on Linux (WSL) and macOS go test -tags nogui ./... passes. go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build pass. 2026-10-01 23:15:07 +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
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 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 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