The app's own partner counts only come from users who leave the stats on,
so a sponsor's reach and clicks are now also counted where the server sees
them. /api/partners hands out each partner's website and keysUrl (and a
region's) as usemagpie.ai/go/<id>/site|keys[/<region>]; /go sends a
"magpie partner go" event to PostHog (partner, link, region, country) and
302s to partners.js's own URL. One in ten list fetches sends "magpie
partners fetch" with weight 10 while someone is listed. Events carry a
random id each, no install id or address. Ended entries leave the list but
/go still resolves them, since added providers keep the links. Privacy text
updated in README (en, zh), docs/reference.md and the site docs (en, zh, ja).
Run: node --test site/*.test.mjs (27 pass); a scratch copy with a fake
partner served rewritten links, 302'd /go to the real URLs and posted both
events; PostHog's /i/v0/e/ answered 200 to the payload shape.
Snow CLI (npm snow-ai, MIT, MayDay-wpf/snow-cli) keeps one profile per
file under ~/.snow/profiles (or $SNOW_CONFIG_DIR), names the active one
in active-profile.json, and copies it over config.json at every start,
headless `snow --ask` included. Each profile is the whole snowcfg: base
URL, key, request method and models. Snow App (MayDay-wpf/snow-app)
reads ~/.snow/profiles/*.json when "Sync Snow CLI API config" is pressed.
magpie writes profiles/magpie.json from the profile the user was on
(their settings kept, Snow's OAuth sign-in left out): baseUrlMode base
at the gateway's /v1, requestMethod chat, the agent's key, the model as
advancedModel and basicModel, and the catalog's window and output
(200000 and 64000 when not known, the output cut to the window). It
makes that profile active and copies it to config.json. The profile the
user was on, whether there was an active-profile.json at all, and a
magpie.json of their own are stashed; Disconnect, `magpie snow
default`, or picking a model of one of the user's profiles puts those
back. A Snow from before profiles (config.json alone) gets the
default.json Snow itself would make, so its next start doesn't take
magpie's config for the user's. Check reports a base URL, key or request
method moved off magpie's; Sync rewrites the profile on a port move. A
WSL distro's ~/.snow is found and written the same way.
Registered: agents.go, the WSL kinds, SNOW_CONFIG_DIR in agentenv, the
npm update spec (snow-ai), the icon (Snow App's own, trimmed to 96px),
README, docs/reference.md, docs/subsystems/agent-wiring.md, the site's
agent list and start.html (en, zh, ja).
Run:
- go test -tags nogui ./... in a scratch HOME: 44 packages ok.
New: TestSnow, TestSnowOwnProfile, TestSnowNoProfiles,
TestSnowUsersMagpieProfile, TestSnowCheckSync, TestAgentSnowDefault;
snow added to TestOwnProviderNamedAsMagpies, the WSL more-agents tests
and TestMaxTokensWithinContextWindow. All fail before this commit
(no agent "snow").
- go vet -tags nogui for darwin, linux and windows; gofmt -l clean.
- Real Snow CLI 0.9.2 in a sandbox HOME against a sandbox magpie
(`magpie serve` on 127.0.0.1:3571, a fake OpenAI upstream on 3561):
`magpie snow fake/pro` made the magpie profile active, `snow --ask`
answered through the gateway (POST /v1/chat/completions, model pro,
logged as agent snow), and `magpie snow default` left profiles,
active-profile.json and config.json byte-identical to before.
- GUI: agent-layout, agent-connect, agent-models-picker,
agent-field-names and models-add-and-icons in Chromium and WebKit;
a Snow CLI row checked at 520-960px in en, zh, zh-TW, ja and de in
both engines. No new GUI strings.
Until now, both were only in docs/reference.md. The new pages are at
/docs/docker, /docs/remote and their zh/ and ja/ versions.
- docker: the image, its tags, ports, the /config volume and the nonroot
user. How to run it with the browser UI (`web --addr 0.0.0.0:3430
--no-open`, MAGPIE_WEB_KEY, the ?k= cookie). Signing in through the
Callback URL paste or `docker exec ... magpie accounts add`. What
/config keeps, the env vars, sharing with gateway keys, and a Compose
file for a NAS. Healthcheck and updates.
- remote: sharing the main magpie, then adding it as a Remote magpie
from the app, the TUI (a/w/m) or `magpie provider add remote-magpie
<key> url=... id=office`. What comes over (models, groups, APIs,
images, System One, embeddings, prices, quotas) and the errors magpie
shows, quoted from remote_quotas.go and lan.go.
The facts were checked against the code, not reference.md:
- the Dockerfile ENV, VOLUME, HEALTHCHECK and EXPOSE;
- docker.yml's tags;
- web_cli.go;
- the lanGuard in internal/gateway/lan.go;
- the remote-magpie preset.
The Docker page's warning says a Docker gateway answers anyone until
sharing is on, because MAGPIE_ADDR is 0.0.0.0 there.
The new links in the top nav bar carry a toc-only class:
- docs.js still lists them in the contents;
- the bar keeps today's width, since nine links overflowed it at
1024-1280px.
`.steps li` gets min-width: 0, so a long inline code no longer widens
the grid past a phone's width, where `overflow: hidden` clipped the
text.
Run:
- Real containers from ghcr.io/yetone/magpie:latest (v0.1.1150):
- the documented `docker run ... web` came up healthy, and its log
output is what the page shows;
- with "lan": true, `Bearer magpie` got 401 and a gateway key got 200;
- a second container ran `provider add remote-magpie <key>
url=http://<a>:3425 id=office` and listed office/test-relay/... models.
- `node --test site/*.test.mjs`: 23 pass.
- Playwright, in Chromium and WebKit, at 1280, 1024 and 390, light and
dark:
- no horizontal scroll and no nav overflow on all 20 docs pages;
- every internal link and #anchor resolves. /zh/ and /ja/ are routed
by the worker and return 200 live.
Saving a profile (＋ Save current, magpie save, the TUI) now keeps, beside
every detected agent's fields and the library, the agent's model list as
the Agents page's Pick sets it: the models taken out one by one
(hiddenModels), or "only the models I pick" and those picks
(pickedModels), the order put on them (orderedModels), and the
visibility `magpie visible` narrows it to (visible). It is kept under the
id the lists are kept by (agent.ListsFor), in profiles.json under a
"models" key beside "library". Applying a profile puts each list back
exactly (provider.SetModelLists: one settings write, renamed providers'
ids followed), then the fields, so the model is set last over the list;
the lists are written once through catalog.Touched, the same path a pick
made by hand takes, so Codex's magpie-models.json and the other agents'
model files are rewritten. A list that changed counts in "N settings
changed".
Left out on purpose: fastPicks (how a model is sent, not whether it is
listed, and it stays with the model) and agentEfforts (Cursor Private
Inference's effort is already an agent field a profile keeps).
A profile saved before this has no "models": it is read with none, leaves
every agent's list as it is (unknown, not empty), and is written back
byte for byte. An agent a new profile doesn't name keeps its list too.
A profile's details show a Model list line per agent: "8 hidden", "only
the 3 picked" or "every model shown", in all five languages.
Verified:
- internal/profile TestProfileSwitchesModelList: three profiles (two
hidden; all shown with an order; only-picked), each applied rewrites
settings and Codex's magpie-models.json to that list. Fails with Apply's
list step removed ("applying home changed nothing", the hidden list
not restored) and with catalog.Touched taken out of SetModelLists
(Codex's file keeps the old list).
- TestOldProfileKeepsModelList: an old profile keeps codex's hidden and
claude's only-picked, writes back unchanged; one naming only codex's
list leaves claude's. Fails when a missing "models" is read as empty.
- The built nogui binary in a sandbox HOME (env -i): magpie save home /
save work / use home / use work switched Codex's magpie-models.json
between m1 and m1-m3.
- profile-details.test.cjs (en, zh window and panel, zh-TW, ja, de) in
Chromium and WebKit; fails without the app.js line. With
profile-confirm, panel-profiles, gui-ja, gui-de, gui-zh-tw, i18n-keys
and click-scroll: 38/38 in each engine.
- gofmt -l clean; go vet (darwin), GOOS=linux go vet -tags nogui,
GOOS=windows go vet on profile, provider, gui; go build, linux nogui
and windows builds; go test -tags nogui ./... under a temp HOME, all ok.
Not tried in the real window with a live gateway.
7d663a27 began sending, with the daily stats, each listed partner's
counts of times shown, opened, its key page opened and added. f9a1ca03's
Privacy section, written 40 minutes before, listed only the id, version,
system and the agents, providers and models, and said no usage is sent.
Docs/reference.md had the counts; the summaries didn't. They now name
them, as counts only, and the site's switch text says "Share the agents,
providers and models I use" leaves them out too (partnerCounting reads
NoUsageStats).
Ran: node --test site/*.test.mjs (23 pass).
The old README was the whole manual in one file. Someone who opened the
repo saw a wall of config paths before seeing the app. The new one leads
with the app: a hero screenshot, six highlights, then a section for each
part (picking models, providers, routing groups and intent routing,
subscriptions and plugins, usage, sharing, the library), with the site's
light and dark screenshots in <picture> tags. A supported-agents list, a
three-step quick start and a CLI sample follow. README.zh-CN.md is the
same page in Chinese, with the Chinese screenshots where the site has
them.
The full manual moves, word for word, to docs/reference.md, with its two
relative links fixed. Both READMEs link to it, so no detail is lost.
yetone