Will's routing group keeps cursor/grok-4.7. Cursor's plugin (0.2.2/0.2.3)
lists Grok 4.7 only at its context sizes, grok-4.7@256k and
grok-4.7@500k, and its usage() builds the Cursor Models window's models
and Other Models' notModels from those ids. quotaOfPlugin matched a model
against those lists by the whole string, so bare grok-4.7 (which the
plugin still runs, at its default size) fell into Other Models: used up,
so the Routing page showed it 0% left and weighRouted ranked it last,
while composer-2.5 showed ~84%.
The window's lists are now an idSet: a bare id is in it when one of its
id@size is, and an id@size when its bare id is. Only the trailing @size
is taken off, so distinct models stay apart: another @size of a model,
another family member (grok-4), and other suffixes (ZCode's -Trial) still
match by the whole id. Every route that asks a plugin window whether it
counts a model goes through w.matches -> Limit.applies (routing's For,
Pace, Count, Renewal, fallback's Pooled, CapHeld, QuotaWindow.Counts for
the usage page's holds), so the one change reaches them all. host.js's
contract comment says so for plugin authors.
The plugin's own lists are also fixed in magpie-community/plugins (cursor
0.2.4 adds each listed id's bare name to its pool), for magpie versions
before this one.
Verified:
- TestPluginPoolCountsBareIDOfSizes (the reporter's literal ids) fails on
the old code: "grok-4.7: used 100, want 16", "the usage page's holds
count grok-4.7 in Other Models", "grok-4.8@1m: used 100, want 16";
passes with the change.
- gofmt -l clean; go vet, GOOS=linux and GOOS=windows go vet -tags nogui
on internal/provider and internal/plugin; go build for darwin, linux,
windows.
- go test -tags nogui ./... green but TestNoCommandBypassesProc, red on
main since 2da8fbe4 and fixed by b934d64a, which this is rebased on.
Not verified: against Will's real Cursor account.
A magpie serving only other magpies (`magpie serve` in a container) has nobody on its Usage page, so GET /v1/magpie/quotas/cards, answered by CachedCards from the page's caches (subscriptionUsageCache, planQuotaCache, keyBalanceCache), said "nothing read on that magpie yet" while its Codex account's usage was read every few minutes behind the requests: those readings land in loginUsageCache (and a key's in keyAllowances), which CachedCards never looked at; after a restart even a page-read card was gone until the page was opened, though quotas.json held it.
CachedCards still asks nobody. It now lays each account's latest LoginUsage reading over its card when it is newer by readSeq (perLogin's cards are that same reading, so the page's own later read stands), adds a card for an account read that way and never on the page, named and drawn as the page names it (accountCard: perLogin now takes that face), and falls back to the reading kept on disk, dated (AsOf). Keys the same way: routing's KeyAllowance reading now keeps what was read with the windows (plan, balance, parts, readSeq) and is laid over the key's plan or balance card, or makes one; with no card read since start, the plan and balance cards kept in quotas.json are told. Cursor (known by asking its CLI), Grok (read by home) and a Kiro key keep the page's cards only. The local Usage page is unchanged.
Not fixed here: the quota history (/v1/magpie/quotas/history) is still written only by the page's reads.
Red before: with CachedCards as on origin/main and everything else in place, TestRemoteMagpieShowsBackgroundReadings (gateway, through lanGuard(New().Handler()) and a remote-magpie provider: CodexUsedUp, then RemoteCards) fails with the reporter's card ("nothing read on that magpie yet; refresh to have it read"), and TestCachedCardsTellBackgroundReadings, TestCachedCardsKeepALaterPageRead and TestCachedCardsTellKeyReadings fail; all pass with it. ForgetKeptCardsForTest is called from the gateway's fresh() so TestRemoteMagpieQuotas's "nothing read" holds under -count.
Run (Docker golang:1.26.8, the Mac's syspolicyd pegged): go test -tags nogui ./internal/... (internal/agent as uid 1000), go test -race ./internal/provider ./internal/gateway, go test -count=2 -run TestRemoteMagpie ./internal/gateway; go vet -tags nogui for darwin, linux and windows on internal/provider and internal/gateway; gofmt -l. No app.js change.
TestPluginFailover failed about 1 run in 90 at "a refused isn't marked".
With notePluginLapse logged, a failing run read: a background reading of
a's allowance (loginReading, after the "stream" round's StaleAllowance)
began at 31.985; the upstream answered a's request 401 at 32.001 and
notePluginSaid marked a lapsed at 32.003; the reading ended clean at
32.011 and notePluginLapse(200) took the mark off; the test read the
logins at 32.042. Users meet the same: a reading of the Usage page or of
routing's allowances that is out when a request is refused clears the
mark the refusal left, and routing goes on trying the refused account;
one that ends refused marks an account a request has just gone through
on.
What plugin accounts' sign-ins are told of is now counted under
loginsMu (pluginSignInTold, pluginSignInSaid). A request's answer, a
sign-in and the plugin's own signIn events are told now and apply as
before. pluginLoginQuota takes the count before plugin.AccountUsage, and
what its reading found applies only when nothing was told of that
account since (notePluginLapseSince), as Allowances leaves out an
account renewed while it read. A count rather than a time: Windows'
clock moves in ticks of up to 15.6ms, and a reading begun just after an
answer would read as begun with it.
TestPluginUsageReadOlderThanAnswer holds the fake plugin's usage on an
httptest server ($FAKE_USAGE, whose 401 the fake now reads as an expired
sign-in) while a request's answer is noted, both ways, and checks that
readings begun afterwards still mark and clear. Each direction fails
without the fix. TestPluginFailover now reads the allowances the
"stream" round left stale before the "gone" round: the fake's usage
doesn't ask the upstream that refuses, so a reading that asks after the
401 finds the sign-in good and rightly takes the mark off. A review
reproduced that with a delay injected before the count is taken.
Left as it is: a reading whose own renewal of the token tells "renewed"
before it asks skips the "expired" it then finds; the next 401 marks the
account. Not tried with a real plugin account.
Under a temp HOME with Go's caches pinned and bun 1.4.2: gofmt, go vet
-tags nogui ./..., builds for darwin, GOOS=linux -tags nogui and
GOOS=windows (and windows vet of provider and gateway) pass; go test
-tags nogui ./... passes; the changed provider tests and
TestPluginSaysSignIn/TestPluginFailover pass with -race -count=20; the
report's `go test -tags nogui -race -cpu 1,2,4 -count=30 -run
'^TestPluginFailover$' ./internal/gateway/` passed 3 rounds (270 runs),
where it failed 3 of about 54 runs before the fix on the same loaded
machine.
Moody-Sin: the Routing page showed a WorkBuddy account as "已用 71%" only, which for a plan counted in credits says little. A quota window now carries its own count when the vendor counts in amounts — amount of limit, in unit (QuotaWindow, QuotaSpan for quota --json and /v1/magpie/quotas, and the routing trace's Weighed, from the window its share is of: Allowance.Count). WorkBuddy's built-in fills it from the resource summary, and @magpie-community/opencode-workbuddy-auth 0.1.8 tells it from auth.usage (amount / limit / unit, passed through host.js); the workbuddy mover's min is 0.1.8. The Routing page's stage and its list of what each account did, the Usage page's meter, the menu bar's tooltip and the TUI say "3,550 / 5,000 credits · 71% used", or "1,450 / 5,000 credits · 29% left" with Left on (积分 in Chinese); a window counted in shares alone reads as before.
quota-credits.test.cjs (WebKit, en/zh, used/left, Routing and Usage pages) fails on the old assets and passes; TestQuotaWindowCount, TestAllowanceCount, TestTraceTellsTheCount, TestPluginUsage (the count through the host) and TestWorkBuddyAccounts cover the Go side. Tried with the real WorkBuddy and WorkBuddy AI accounts in a sandbox magpie: moved onto the local plugin, /api/usage/quotas gives 33.29 / 3900 and 13.47 / 2250 credits and the Usage page reads "33.29 / 3,900 积分 · 已用 0.9%", "3,866.71 / 3,900 积分 · 剩余 99.1%" after a click on the count; not moved, the built-in gives the same for WorkBuddy. The Routing page with two real accounts of one provider wasn't tried (one account each). go vet, builds (darwin, GOOS=linux, GOOS=windows) and go test -tags nogui -count=1 ./... under a temp HOME pass.
yetone