magpie

docs

docs, site: Integrating your app or agent with magpie, at docs/integrating.md and usemagpie.ai/docs/integrate (#918 , Magixyne)

2026-10-05 22:46:35 +08:00

icons

agent: AtomCode support — one provider account, one model table per catalog model, as its own sign-in writes (#736 )

2026-10-04 14:11:14 +08:00

img

site: the Japanese docs show magpie in Japanese (the owner: 日文文档也要有日文截图) — the ja pages of Getting started, Intent routing and Import showed the English window. Each of their nine shots is taken again with the GUI in Japanese (v0.1.851): once in magpie's own dark and light look (/img/<name>-ja-dark|light.png, drawn by Chromium on the Mac like the en and zh ones) and once for every one of the 22 Omarchy themes (/img/omarchy/<theme>/<name>-ja.webp, lossless, in the VM's Omarchy). omarchy.js takes -ja as it takes -zh, with the sizes of the Japanese shots that differ. Alt texts name the tabs as the Japanese UI does. Locally, with the light look and three Omarchy themes, all nine images on the three pages are the Japanese ones, loaded, at their own ratio.

2026-10-04 20:51:05 +08:00

docs.css

site: docs in Japanese (/docs/ja), and contents that work on a phone (owner: 文档也要支持日语，另外，文档要有友好的目录，在手机端也要有友好的目录) — /docs/ja/{start,intent,plugins,import} translate the English pages; every docs page gets the home page's language menu (English / 中文 / 日本語, the lang cookie) and a ja hreflang, /docs/ja opens the guide, and /ja/'s docs links go to the Japanese pages. docs.js (shared, replacing each page's inline scrollspy) builds the contents: every docs page, the current one's sections under it, the section being read marked with a pill (no left border); the list is sticky and scrolls on its own. Under 900px, where the contents were simply hidden (and under 600px the nav links too, so a phone had no way around the docs), a bar under the nav names the section being read and opens the contents as a menu that closes on a pick, a tap outside or Escape. The nav links give way to the contents under 1000px, long inline code wraps under 1100px, and .doc keeps .wrap's side padding (601-1168px ran the text to the screen's edge). node --test worker.test.mjs passes (/docs/ja redirect added); WebKit at 320-1280, light and dark, en/zh/ja: nothing scrolls sideways, the menu opens, jumps and closes, the bar follows the reading position.

2026-10-03 11:26:23 +08:00

docs.js

site: docs in Japanese (/docs/ja), and contents that work on a phone (owner: 文档也要支持日语，另外，文档要有友好的目录，在手机端也要有友好的目录) — /docs/ja/{start,intent,plugins,import} translate the English pages; every docs page gets the home page's language menu (English / 中文 / 日本語, the lang cookie) and a ja hreflang, /docs/ja opens the guide, and /ja/'s docs links go to the Japanese pages. docs.js (shared, replacing each page's inline scrollspy) builds the contents: every docs page, the current one's sections under it, the section being read marked with a pill (no left border); the list is sticky and scrolls on its own. Under 900px, where the contents were simply hidden (and under 600px the nav links too, so a phone had no way around the docs), a bar under the nav names the section being read and opens the contents as a menu that closes on a pick, a tap outside or Escape. The nav links give way to the contents under 1000px, long inline code wraps under 1100px, and .doc keeps .wrap's side padding (601-1168px ran the text to the screen's edge). node --test worker.test.mjs passes (/docs/ja redirect added); WebKit at 320-1280, light and dark, en/zh/ja: nothing scrolls sideways, the menu opens, jumps and closes, the bar follows the reading position.

2026-10-03 11:26:23 +08:00

favicon.png

usemagpie.ai, and a magpie that updates itself

2026-09-24 01:57:50 +08:00

import.html

providers: Tencent Cloud is one preset, its regions Plan · China, Pay as you go · China and Pay as you go · Global (Discord, Jorben: Tencent Cloud's Token Plan, TokenHub and TokenHub China were three tiles of one vendor) — tencent-token-plan, tencent-tokenhub-cn and tencent-tokenhub become tencent-cloud's regions plan, cn and intl, as Xiaomi MiMo's are, each made as its own preset made it: the plan's /plan endpoints with no Responses, its own models and no catalog; TokenHub's hosts with Responses, models.dev's tencent-tokenhub and its own keys page and docs. A region now carries its Website, Catalog and Models, and a saved provider's region is found by its endpoints (regionOf, by exact URL before path, since TokenHub China and global share their paths): normalize gives it that region's keys page, docs and catalog (a catalog the user picked is kept), and planModels its models. The old ids are aliases, as qianfan-token-plan is of baidu-qianfan: Preset and FromPreset take them, FromPreset builds at their region, normalize rewrites a saved provider's preset to tencent-cloud, and a provider's own id never changes, so its key, models, routing groups, usage and prices stay where they were; magpie://import links by an old id land at its region, and region= now also gives a region's docs and catalog. Imports from other apps match a region's endpoints. The editor's docs link follows the region picked with the segmented control, en and zh ("按量 · 中国", "按量 · 国际"); the add sheet has one Tencent Cloud tile; the site's import docs list tencent-cloud with its regions and import.html still names the old ids. TestTencentCloud (each region, old ids, FromPreset, imports, import links) and TestTencentCloudOldPresetsKeepWorking (a providers.json saved by an older magpie under all three old presets, with a routing group over them, read, re-saved as the editor saves and switched between regions) fail on the old code; TestTencentTokenHubRoutes routes through old ids and tencent-cloud alike. tencent-cloud.test.cjs (WebKit en and zh: one tile, the three regions, no select, the docs and Get a key links following the region, an old id's provider opening at its region and saved under its id) fails on the old app.js; add-sheet, zhipu-team, system-one, strip-scrollbar and click-scroll pass (Chromium doesn't launch in this sandbox). Not tried with a Tencent account. go vet, builds (darwin, GOOS=linux, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-04 19:38:14 +08:00

index.html

Add German translation; harden paths against unset env vars (#770 )

2026-10-04 23:30:56 +08:00

install.sh

Add German translation; harden paths against unset env vars (#770 )

2026-10-04 23:30:56 +08:00

omarchy.css

site, omarchy: the site in Omarchy's style follows a theme set in Omarchy without a reload (owner: 现在系统换完主题后网页需要手动刷新一下才能切换到对应主题) — a browser that hasn't let usemagpie.ai reach this computer (Chromium's local network access, which nothing on the page asked for) left the page on Omarchy's default for light or dark, chosen from prefers-color-scheme once at load, and a page that had been let through could lose magpie for 30 s when one answer was slow. Now: while not let through, the page repaints as prefers-color-scheme turns (omarchy-theme-set turns GNOME's color-scheme, so Chromium's), and a "Follow my Omarchy theme" / 跟随 Omarchy 主题 button beside the chip asks the browser in one click; a permission turned to granted (the prompt, site settings) starts following at once, denied stops it; once magpie has answered, one failed or slow answer (5 s, was 3 s) keeps the page following and it asks again in 3 s (two in a row mark it absent, still asked every 3 s), and two permissions turning together poll once. The gateway's /v1/magpie/omarchy no longer asks omarchy-font-current and hyprctl again on every theme change, only when the font's or Hyprland's own files change, since a theme set reloads Hyprland and hyprctl asked meanwhile can stall (2 s timeouts each); TestCurrent checks a theme switch keeps the font without asking and fonts.conf changing asks again (fails on the old code). Tried in the Omarchy VM's Chromium with the new omarchy.js/css: not let through, the page went tokyo-night ↔ catppuccin-latte with the desktop; the button raised Chromium's "Access other apps and services on this device" prompt and the page went live on vantablack once granted, no reload; with access allowed, catppuccin-latte, tokyo-night, rose-pine and vantablack came through within 1.5–3 s each, no failed request. go vet, builds (darwin, GOOS=linux -tags nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass. The prompt's Allow itself wasn't pressed (granted through the profile and CDP instead).

2026-10-04 04:17:42 +08:00

omarchy.js

site, omarchy: a reload shows the theme the page showed, not one magpie told before the desktop turned (owner: 在 Omarchy 下网页的确可以自动识别 Omarchy 主题切换事件了，但是一刷新又变回了默认的 Omarchy 主题) — with magpie not answering (here the VM had restarted and nothing served 127.0.0.1:3425), the page follows Omarchy only by light/dark: rose-pine set turned it to catppuccin-latte, but localStorage still held miasma, the theme magpie had last told, and a reload painted that. Now when the desktop turns to the other mode while magpie isn't answering, that stale theme is forgotten, so a reload paints what the page showed. Tried in the Omarchy VM in Chromium 152 on a copy of the owner's own profile (its loopback-network grant and storage), omarchy.js served from this change: magpie down, miasma → rose-pine turned the page to catppuccin-latte and a reload kept catppuccin-latte (it went back to miasma before); magpie up, rose-pine came through live and a reload kept rose-pine.

2026-10-05 02:24:44 +08:00