magpie

checkin_test.go

provider, gui: MiniMax Code's daily check-in (Hu9956, #811 ) — magpie claims each MiniMax Code (China) account's daily check-in credits once a Beijing day, as MiniMax Code's page does, the same way it does WorkBuddy's and Trae CN's. It asks GET agent.minimax.cn/minimax-cloud/api/v1/signin/status?timezone_id=Asia/Shanghai and, only while today's day is claimable (status 2), POST /claim with {}. Both go through the minimax-code plugin's fetch, which signs them in as the account. The page's x-timestamp and x-signature (md5 of ts + salt + body) go with them, though MiniMax doesn't check these now. Day status 3 (claimed) and claim_result 2 count as done; status 4 is not eligible; base_resp's code and message are the failure's reason, and an expired sign-in says sign in again. The streak is the week's day_no. Results are kept in minimax-checkin.json. The international site's check-in isn't known, so minimax-code-global accounts are left alone. The switch is in Settings › Usage › warm-up and check-in › MiniMax Code (minimaxCheckin, off by default) and on the usage card (Auto check-in, Check in now: POST /api/settings/minimax-checkin, /api/usage/minimax-checkin); the card row's vendor strings are now a table (CHECKINS). magpie checkin and the TUI also check it in. zh, ja and de strings. No real MiniMax account was at hand: TestMiniMaxCheckin and TestMiniMaxClaimAlready run against an httptest fake built from Hu9956's captured answers. The fake checks timezone_id, the signature, the GET without a body and {} on the claim. It covers claim, no second ask the same day, in already, disabled, a refusal with its reason, and expiry. They pass with -race. usage-checkin.test.cjs adds the MiniMax card (its own switch and press, Trae's untouched) and the Settings tab (WebKit, en and zh, 8/8). settings-sections, gui-ja, gui-de, click-scroll and usage-quota-head pass on WebKit. go vet, builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-05 03:05:14 +08:00

gateway_test.go

tui: magpie tui serves the gateway while it is open when no other magpie does, so agents it connected reach it in WSL (gnayiab on X)

2026-10-05 21:29:01 +08:00

gateway.go

tui: magpie tui serves the gateway while it is open when no other magpie does, so agents it connected reach it in WSL (gnayiab on X)

2026-10-05 21:29:01 +08:00

groupfast_test.go

routing: a group's member can be sent in its vendor's fast mode, beside its own reasoning (vs on Discord: a member "gpt-6.1 sol · high · fast") — a member's effort was already its own (#189 , "provider/model:effort") but there was no way to ask for speed, so a group could not hold "gpt-6.1-sol at high, priority" next to slower members. A group now lists in fast the members it sends fast, as Members spells them, kept beside Members rather than in their ids so an older version still routes to them, only not fast (checked: HEAD's build on the same providers.json sends the same members at their effort, no tier, and leaves the file as it was). When the gateway sends to such a member it asks in the upstream's own words, only where the model has a fast mode magpie can ask for (provider.CanFast): service_tier "priority" for a ChatGPT account's GPT models and an OpenAI key's GPT/o-series models on its Responses API, Cursor's -fast variant, and speed "fast" with the fast-mode-2026-02-01 beta for Claude Opus 4.8/5/5.5 on an Anthropic key (api.anthropic.com); a relay, Bedrock, a Claude subscription, a model without one, or a provider since moved off those hosts is sent untouched. It is applied in the agent's own API and carried through translation (parseAnthropic now reads speed), so Chat, Responses and Anthropic agents all get it. A translated request for OpenAI's Chat API is still told no tier (TestCursorPluginFast), hence the Responses requirement. The trace marks the try, the order and the group (fast), shown as "fast" beside the reasoning in Requests and the order. Typed, a member is provider/model[:effort]:fast: magpie group add/set models=… takes it, fast=<m1>,… sets them, models-= takes either spelling, and the group lists and shows members as typed with "· fast"; a model with no fast mode, or a group in the group, is refused. The GUI group editor shows a "Standard speed"/"Fast" toggle (标准速度/快速) beside a member's reasoning only for a model that has one, the card reads "· fast" after the reasoning, and fast follows a member's reasoning change and leaves with a removed member; the TUI's group view takes E to step a member's effort and F to toggle fast. Provider renames carry it. TestFastMemberOpenAI, TestFastMemberAnthropic, TestWithFastWire (gateway, per wire format, a fake vendor recording body and anthropic-beta), TestCanFast, TestSaveGroupFast, TestGroupMembersFast, TestGroupMemberEffortAndFast, TestGroupSaveFast and group-member-fast.test.cjs fail without the change. A sandbox magpie (own HOME, gateway on 3966) with providers at http://api.openai.com and http://api.anthropic.com through a local recording proxy sent priority+high to OpenAI and speed fast + the beta to Anthropic from Chat, Responses and Anthropic clients, and nothing extra for Sonnet or a non-fast member. go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./... pass; group-member-fast, click-scroll, old-webkit, routing-levels, routing-manual, routing-effort, settings-groups pass (Chromium, WebKit, en/zh).

2026-10-01 17:13:34 +08:00

library.go

tui: the routing page (3, was groups) does what the app's Routing view does — an open group lists its rules under its models, one list: n adds a rule typed as magpie group rule add takes it (use=<model> tokens=200k images effort=… agents=… intent="…" classifier=<model> at=<n>), ↵ types one again in place, J/K moves it, d twice removes it; c picks the classifier, s how long a conversation stays, x the context agents are told, R renames the group (the page follows it); a found group that was removed is listed last and u brings it back; smart routing is shown as smart, not in order, and o goes round all four. The library page adds too: a adds an MCP server (a URL, or a command) or skills from a GitHub repository or a folder, e changes a server (its env, headers and agents kept), u fetches a skill from GitHub again, s syncs the library into the agents. The rule parsing moves to provider (ParseRule, RuleWords, Rule.Line) and a typed server to library (ServerOf), for the CLI and the TUI alike. Asked on Discord

2026-09-26 23:08:58 +08:00

list_error_test.go

tui, cli: a plugin's account whose model list failed says why on the Providers page and in magpie providers (gnayiab on X) — v0.1.1001 had the app's editor say why Cursor's plugin account listed Auto alone, but gnayiab runs magpie's TUI in WSL, where the Providers page still showed "1 models" and nothing else (only m, asking again, said why). Each provider's row now ends in "couldn't list its models: <why>" (red, as other faults there) when provider.ListError has one, and magpie providers says the same in amber after the row. TestProvidersSayWhyAListFellBack fails without the change. go vet, go test -tags nogui ./internal/tui . under a temp HOME, and go build (GOOS=linux nogui, GOOS=windows) pass.

2026-10-05 18:44:12 +08:00

main_test.go

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

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

pages.go

tui, cli: a plugin's account whose model list failed says why on the Providers page and in magpie providers (gnayiab on X) — v0.1.1001 had the app's editor say why Cursor's plugin account listed Auto alone, but gnayiab runs magpie's TUI in WSL, where the Providers page still showed "1 models" and nothing else (only m, asking again, said why). Each provider's row now ends in "couldn't list its models: <why>" (red, as other faults there) when provider.ListError has one, and magpie providers says the same in amber after the row. TestProvidersSayWhyAListFellBack fails without the change. go vet, go test -tags nogui ./internal/tui . under a temp HOME, and go build (GOOS=linux nogui, GOOS=windows) pass.

2026-10-05 18:44:12 +08:00

remote_magpie_test.go

tui, cli: adding a provider says how many models its list had, or why it had none, and m (magpie provider refresh <id>) fetches the list again (akic404 on Discord: 还是tui cli问题，没有获取上游模型功能，新建之后模型数是0)

2026-10-04 01:24:47 +08:00

routing.go

gateway, gui: a provider's keys can be routed by weight, a key weighing 3 taking three requests for every one a key weighing 1 takes (dengtongcai, #841 ) — Routing already spread requests over a provider's keys in order, in turn, least used first or by pace, but never in a set proportion: two team keys meant to split 75/25 could only go evenly or one after the other. Routing now has By weight (routing "weight") for a provider with keys: each key that's on shows its weight and its share beside it in the editor (Weight 3 · 75%), a click edits it in place and posts keys/weight (provider.SetKeyWeight, 1 to 1000; none or 0 counts as 1, kept out of the file), and providers.json takes it as "weight" on each of keys (keyWeight for the first). The gateway picks as NGINX's smooth weighted round robin does (weighted.go): 3, 1 and 4 go round in every 8 requests in that ratio, never bunched; the others follow in their order for failover. A key resting after a failure is left out of the round while it rests, the others taking its share by their weights, and goes last. A conversation still stays with its key as Stays says (cache-warm across turns by default, within a turn always), and a request kept so is counted against the key that took it, not the one the round picked, so new conversations make up the share; Stays Off gives the ratio request by request. The weight goes with its key through Make first, the editor's Save, backups and WebDAV sync. The Routing page offers By weight for key pools and explains a pick by it; sink (Goes to the back) is off for it as for In turn. zh, ja, de strings. TestWeightedKeys (3:1:4 exact in each of 50 rounds of 8 through perKey and route; with one resting the other two 75/25 and the resting one last; a kept request made up by the next picks) and TestSetKeyWeight fail on the old code (no Weighted); key-weight.test.cjs (WebKit, en and zh: By weight shows the weights and shares, a click sets one and the shares redraw, Smart hides them, no scroll) fails on the old code (no By weight). key-import, panel-routing, routing-save, rate-limited-sink, routing-reset-deadline, account-arrange, gui-ja, gui-de and click-scroll pass on WebKit. go vet, builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-05 08:50:57 +08:00

sessions_test.go

usage: the cache hit rate is of the whole prompt, what was written to the cache in it too (Chapin on Discord: with Claude Code started anew at every AmpCode tool round, writing its prompt to the cache again each time, the Usage page still showed a hit rate near 100%) — the Usage page's Overview divided cache_read by input + cache_read, as did the Sessions tab's totals, the TUI's Sessions page and magpie sessions' hitRate; input is what was neither read from the cache nor written to it (the gateway's Usage.prompt() is input + cache_read + cache_write, and the sessions readers subtract both, as alma's and cline's do), so a prompt mostly re-written showed as mostly read. Each now divides by input + cache_read + cache_write, as the tray panel's Usage tab and the Requests tab's strip and rows already did. number-units.test.cjs checks the Overview's rate on its fake ledger (2B read of 1B + 2B + 30M written: 66%, where the old formula said 67%; fails on the old code), TestHitRateCountsCacheWrites checks hitRate (20% of 10 + 20 + 70), and the TUI Sessions page's fixture, which has writes, now says 67% where it said 69%. GUI: number-units, panel-usage, usage-ledger-chart, usage-refresh and mobile-web pass on WebKit; go vet, builds (darwin, GOOS=linux, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

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

sessions.go

usage: the cache hit rate is of the whole prompt, what was written to the cache in it too (Chapin on Discord: with Claude Code started anew at every AmpCode tool round, writing its prompt to the cache again each time, the Usage page still showed a hit rate near 100%) — the Usage page's Overview divided cache_read by input + cache_read, as did the Sessions tab's totals, the TUI's Sessions page and magpie sessions' hitRate; input is what was neither read from the cache nor written to it (the gateway's Usage.prompt() is input + cache_read + cache_write, and the sessions readers subtract both, as alma's and cline's do), so a prompt mostly re-written showed as mostly read. Each now divides by input + cache_read + cache_write, as the tray panel's Usage tab and the Requests tab's strip and rows already did. number-units.test.cjs checks the Overview's rate on its fake ledger (2B read of 1B + 2B + 30M written: 66%, where the old formula said 67%; fails on the old code), TestHitRateCountsCacheWrites checks hitRate (20% of 10 + 20 + 70), and the TUI Sessions page's fixture, which has writes, now says 67% where it said 69%. GUI: number-units, panel-usage, usage-ledger-chart, usage-refresh and mobile-web pass on WebKit; go vet, builds (darwin, GOOS=linux, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

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

tui_test.go

test: one list of the agent folders a sandbox clears, so no sandbox misses an agent (yetone, on #522 : A shared list of env vars for the other sandboxes would be a welcome follow-up) — every sandbox kept its own list of the variables that point at an agent's folder, and each had drifted: the gateway's cleared 5 of the 32 magpie reads, the provider package's 2, the tui's 10, the library's 20. A sandbox clearing 2 meets whatever Grok, Kimi, Hermes, MiniMax, Qoder or ZCode the developer has installed, which is how #522 came about — Qoder's two were in the library's list and in none of the four that failed. internal/agentenv is now the one list, and the 21 sandboxes that fake an environment with no agent in it clear it, each keeping beside it the variables that are not an agent's: APPDATA and LOCALAPPDATA, which a sandbox sets to a folder of its own rather than clearing, VISUAL and EDITOR. A name in the list is one magpie reads, and TestVarsAreRead walks the sources to say so, which is how two names a sandbox had been clearing turned out to be read by nothing at all — GEMINI_CLI_HOME and OPENCODE_CONFIG in internal/backup's, while OPENCODE_CONFIG_DIR, the one internal/agent reads (agents.go:545), was not in it. Where a sandbox set an agent's folder to a fixture of its own, the clearing now comes first, since a list of 32 wipes what a list of 5 left standing. Not converted: the omp tests' four variables, which are the ones omp's own lookup consults (a Pi fork) rather than every agent's, and the warm-up's Claude Code traffic flags, which are not folders — CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC stays out of the list for that reason too, its one test setting it on purpose. On Windows 11 the whole suite answers as it did before the change: 31 packages pass, and the same 15 tests in internal/library, internal/gateway and internal/agent fail for what they failed for before (symlinks this machine has no privilege for, and TestSuffixModesReachAgentFiles). go vet ./..., go build -tags nogui (windows, GOOS=linux, GOOS=darwin), and go vet -tags nogui for linux and darwin over every package touched pass. (#543 )

2026-10-02 17:22:16 +08:00

tui.go

tui: magpie tui serves the gateway while it is open when no other magpie does, so agents it connected reach it in WSL (gnayiab on X)

2026-10-05 21:29:01 +08:00

usage_test.go

usage: magpie usage and the TUI's Usage page show the agents' own calls, read from their session files, beside the gateway's, and a Codex-based client's calls aren't counted twice (Kumo31 on Discord: Codex used directly, not through magpie, was on the window's Usage tab but not in magpie usage) — magpie usage and the TUI only ever summed the gateway's log (usage.Summarize); the calls the agents' session files record that the gateway never saw (Codex on the user's own ChatGPT sign-in, Claude Code, Claude Desktop…) were merged only into the ledger the window's Requests tab and the tray panel read (#239 ). usage.Direct sums those rows of the ledger (Source "log", this computer's, rejected ones left out) by agent, model, account and session, priced as the ledger prices them, and magpie usage prints them after the gateway's tables under "not through magpie · the agents' own requests, read from their session files" (a model whose provider the file doesn't tell reads "local session/<model>"); the TUI's Usage page shows the same block under the gateway's, each with its totals and agents' and models' tables. The two parts are separate, so nothing is counted in both; a period with only the agents' own calls shows them under "no calls through magpie". All of magpie usage's output now goes to the writer it is given. Checking it against the owner's real data showed the ledger counted a Codex-based client's calls twice: miyi-helper's requests through the gateway are logged under its own name while its Codex session file names Codex, and the gateway/session-file matcher keyed on the agent, so they never matched; the matcher now keys on the session, tokens and time alone (a session id names one conversation), which also corrects the Requests tab. With read-only copies of the owner's ~/.config/magpie and four days of ~/.codex/sessions in a sandbox HOME: magpie usage week printed 177 calls not through magpie, in 1.3M, out 52.4K, cache read 3.9M, gpt-6-astra 154 and gpt-6-sol 23 — the same rows, to the token, as usage.LedgerOf (what /api/usage/requests serves) gave for the period; before the matcher fix, today's 7 miyi-helper calls showed in both parts. TestDirectCountsOnlySessionFileCalls (the miyi-helper case included), TestUsageShowsCallsNotThroughMagpie and TestUsagePageShowsCallsNotThroughMagpie fail on the old code. go vet, builds (darwin, GOOS=linux nogui, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.

2026-10-04 23:03:15 +08:00