yetone
ea6f8f89f8
routing: a group under the pointer stays where it is as requests come in (cwfox67 on X: picking a manual group's model meant fighting the page, which shook as it live-updated) — the Routing page keeps the groups in place on the screen only while they're in the upper half of the view or a field in them has the focus, else it keeps the requests list's place; at the page's foot the groups sit low in the view, so the list kept its place, grew with each request, and pushed a manual group's card down from under the pointer about to click it. Now the groups are also the part kept while the pointer is on them, and the pointer coming onto them or leaving them takes where the reader is again (readerLeaves), as their own scroll would. No new strings. Tested with a new internal/gui/tests/routing-pointer-pin.test.cjs in Chromium and WebKit at 420 and 1100 wide: wheeled down to the groups, pointer on the manual group's card, 8 requests streamed in (start, prompt read, done each): the card stays within 1.5 px on the screen. On origin/main it fails in both engines at 1100 (588 → 702 px). All routing-* GUI tests (199) and click-scroll pass in both engines. The wheel over the requests list still scrolls the list first (the browser's own scroll chaining); not changed. Not tried in the real window with a live gateway.
2026-10-09 04:03:39 +08:00
..
2026-10-07 14:34:36 +08:00
2026-10-09 00:02:40 +08:00
2026-10-08 20:33:11 +08:00
2026-10-07 18:13:01 +08:00
2026-10-09 01:10:25 +08:00
2026-10-08 02:15:01 +08:00
2026-10-08 14:52:11 +08:00
2026-10-08 12:47:48 +08:00
2026-10-08 11:52:20 +08:00
2026-10-09 01:29:46 +08:00
routing: a group under the pointer stays where it is as requests come in (cwfox67 on X: picking a manual group's model meant fighting the page, which shook as it live-updated) — the Routing page keeps the groups in place on the screen only while they're in the upper half of the view or a field in them has the focus, else it keeps the requests list's place; at the page's foot the groups sit low in the view, so the list kept its place, grew with each request, and pushed a manual group's card down from under the pointer about to click it. Now the groups are also the part kept while the pointer is on them, and the pointer coming onto them or leaving them takes where the reader is again (readerLeaves), as their own scroll would. No new strings. Tested with a new internal/gui/tests/routing-pointer-pin.test.cjs in Chromium and WebKit at 420 and 1100 wide: wheeled down to the groups, pointer on the manual group's card, 8 requests streamed in (start, prompt read, done each): the card stays within 1.5 px on the screen. On origin/main it fails in both engines at 1100 (588 → 702 px). All routing-* GUI tests (199) and click-scroll pass in both engines. The wheel over the requests list still scrolls the list first (the browser's own scroll chaining); not changed. Not tried in the real window with a live gateway.
2026-10-09 04:03:39 +08:00
2026-10-08 23:58:22 +08:00
2026-10-09 01:02:51 +08:00
2026-10-08 18:18:15 +08:00
2026-10-09 02:20:30 +08:00
2026-10-08 23:43:20 +08:00
stats: the day's event says which agents, providers and models magpie is used with, by magpie's own ids (a provider of the user's own, and its models, only "custom"), with how many of each and of routing groups: one "magpie uses" event per id in the same PostHog batch, so unique users break down by agent, provider and model. Settings → Privacy → Share the agents, providers and models I use turns it off (on by default; gone while Count me as a user is off); no names, URLs, accounts, keys or usage. go test ./internal/stats (payload, off switch, labels), the Privacy switch in Chromium and WebKit (en, zh), go test -tags nogui ./... in a temp HOME, go vet, GOOS=linux/windows builds pass; read against the real config: 9 agents, 24 providers, 25 groups in 0.75 s
2026-10-08 19:26:13 +08:00
2026-10-09 01:40:02 +08:00
2026-10-07 06:17:56 +08:00
2026-10-09 01:45:43 +08:00
2026-10-09 02:48:29 +08:00
2026-10-08 16:57:39 +08:00