 yetone
|
fa9daa6945
|
docs: every built-in subscription a plugin serves once moved says so in its code, and AGENTS.md says where a fix for it goes (user: 对内置的订阅 provider 在代码层面和文档层面加上注释，防止又有别的 agent 在改内置订阅 provider 的代码而不知道生效的其实是对应的插件代码) — a moved Cursor, Devin, Grok, Command Code plan, Kiro, Zed, Qoder, Factory, Xiaomi MiMo, ZCode or WorkBuddy (provider.Moved; since v0.1.642 also the default for a new sign-in, provider.Adopt) is signed in, listed, requested and metered by its @magpie-community plugin, and none of the built-in's code in internal/provider/<name>*.go, internal/gateway/<name>.go, internal/zed or internal/qoder serves it; a fix made there alone never reaches those users. Each of those files now opens with a PLUGIN-SERVED notice naming the subscription's id, its plugin package, where the plugin lives (magpie-community/plugins, packages/<name>) and the mover whose min to raise so moved users get the fixed plugin (keepMovedCurrent); Qoder's adds that Qoder CN isn't moved and still runs there. AGENTS.md (CLAUDE.md imports it) lists the moved built-ins with their packages and movers, how to tell whether a user's is moved (move.state "plugin", onPlugins), the order a fix goes in (the plugin, publish, raise min, the built-in only for those not moved), the magpie code that does run for a moved one (internal/plugin, plugins.go, plugin_usage.go, pluginsignin.go, migrate*.go, app.js's subOf/pluginSubs/startPluginSignIn), and the parity tests. movers in migrate.go and SUBS in app.js point there too. TestMovedBuiltinsSayTheirPlugin fails for a mover whose code carries no PLUGIN-SERVED notice naming its id and package (it failed while a wrapped package name was split). Comments and docs only, no behaviour changed. go vet ./internal/..., go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui -count=1 ./... under a temp HOME pass (TestProvidersAnswerWhileListsComeIn and TestClaudeSignedOut failed once on their timing under load, pass alone; untouched).
|
2026-10-02 19:37:02 +08:00 |
|
|
yetone
|
cb761abdd1
|
commandcode: a reply is asked for within Command Code's 200000 tokens, and the agents are told no more (Discord: every Command Code model, free or paid, failed with "Too big: expected number to be <=200000 at params.max_tokens") — magpie passed the client's max_tokens to /alpha/generate as it came, and told the agents each Command Code model's reply limit as models.dev gives it: DeepSeek V4's 384000, MiniMax M3's 512000, Space Bunny Alpha's 524288, Kimi K2.x's 262144, so an agent asking for what it was told had the whole request refused. params.max_tokens is now the asked number within the model's own limit as models.dev gives it and within 200000; less is sent as it was, and none asked is still the CLI's 64000. The Command Code subscription's models are listed to the agents (their configs, /v1/models) with a reply limit of at most 200000, a user's own limit included. Prompts and headers are unchanged. TestCommandCodeGoMaxTokens and TestCommandCodeOutputCapped fail without the change. go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./... pass.
|
2026-10-02 06:58:18 +08:00 |
|
|
yetone
|
38f184ae0e
|
signin: Grok and Command Code sign in from magpie in Docker (xugui on Discord: docker版登不上grok和command code) — Grok's sign-in first installs Grok Build with its installer, curl … | bash, and the image has neither bash nor curl, so it stopped at "installing Grok Build failed (exec: "bash": executable file not found)"; the community Grok plugin, beside the built-in rather than moved onto, wasn't given the CLI at all and said "install Grok Build first". Where no shell and curl/wget can run, Grok Build is now installed as its installer does, from the same x.ai/cli (then its storage bucket) address: the stable version, its binary for the platform, checked with --version, linked as ~/.grok/bin/grok and agent, installer = "internal" noted in its config.toml; the plugin's sign-in installs it first too. The device sign-in itself needs nothing back from the browser and was fine. Command Code's Studio posts the key to magpie's 127.0.0.1 port in the background, which a browser outside the container can't reach and no address carries; while it waits, its sign-in now takes an API key made on commandcode.ai/settings/keys and pasted (as Command Code's own CLI offers), checked with whoami and its plan as Studio's was, and a plugin's browser sign-in offers "Use an API key instead", its own api way (the Command Code plugin has one). No identity, header or prompt changes. TestGrokInstallsWithoutShell, TestCommandCodeSignInPastedKey and TestGrokPluginSignInInstallsCLI fail without the change, signin-paste-key.test.cjs too. go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./... pass; signin-paste-key, signin-paste-codex, plugin-signin, signin-callback, commandcode-risk, plugin-key-hint, signin-link, click-scroll, old-webkit pass.
|
2026-10-01 22:25:39 +08:00 |
|
|
yetone
|
4af01cd742
|
providers: Command Code's free models are marked free, and providers switched off fold below the ones on (01huadalang on Discord: Space Bunny Alpha 在 Command Code 里是 FREE，magpie 只给 Ling 3.1 Flash 标了免费；已关闭的供应商还占着位置) — magpie marked a model free when the plan said so (m.free) or its id or name said "free"; Command Code's /provider/v1/models says nothing of it, so only ids like inclusionai/ling-3.1-flash:free got 免费. Its CLI (1.73.2) badges eleven models free in its own table (badge:"free"), Space Bunny Alpha and Pixel Canary among them; those are now marked Free on the Go table, on Go's fetched list and on a keyed plan's, so the chips say 免费 with "doesn't use the plan's credits". Neither the CLI nor the API says a discount (no "-99%" anywhere), so none is shown. On the Providers page the providers switched off now sit below the list under a "Turned off (N)" fold (已关闭的供应商), folded at first and remembered per viewer; a click on it moves nothing, and a provider switched off moves under it. TestCommandCodeFreeModels and providers-off-fold.test.cjs fail without the change. go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./... pass (TestClaudeRunEndsWhenTheClientLeaves a load flake, passes alone); providers-off-fold, click-scroll, old-webkit, provider-search, provider-remove, add-sheet, nokey-editor, plain-names, model-test-one pass.
|
2026-10-01 17:13:34 +08:00 |
|
|
yetone
|
b00387f9db
|
provider: a Command Code Go account lists the models Command Code has for Go, not ten (01huadalang on Discord: command 账号登录只有十个模型，正确的应该是几十个) — for Go, magpie never asked for a list and showed a table of 10, on the word that Command Code has none; its Provider API's list answers without a key (86 models), and its CLI (1.73.0) offers Go every model its picker shows but the premium ones and those it blocks for Go. A Go account now fetches that list without its key, less the 30 refused, and saves it (56 today); the table, the CLI's whole Go set (57), stands in until then or when the fetch fails. Requests still go to /alpha/generate. TestCommandCodeGoModels fails without the change (10 models). go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./internal/provider pass.
|
2026-10-01 06:15:04 +08:00 |
|
|
yetone
|
f5f10bda4d
|
plugins: a plugin's accounts show their allowance as the built-ins' do (the user: 所有插件要完整支持显示额度！跟内置一模一样！) — a plugin's auth.usage now tells plan, user, until, renew, balance, resets (count, until, by window, five hours, weekly) and windows (used past 100 when overspent, resets at/in, display, span, the models a window counts or leaves out, aside), and magpie shows them on the usage page, in the menu bar, beside each account and to the gateway, which passes over an account used up for the model asked; a built-in moved onto its plugin keeps its card's name and icon. Also: Command Code's subscription endpoint answering 200 {"success":false} was read as "No plan" by the built-in (and the plugin), it is now unread; a moved Devin was listed twice, the built-in still finding the Devin CLI's own sign-in; and moving back left the plugin's rows in logins.json, listed as empty accounts. Checked in a sandbox HOME with real Command Code and Devin accounts moved onto the community plugins (0.1.1): GOAT, its period, 5 hours / Weekly / Credits for Command Code, Teams, balance and Daily/Weekly for Devin, the same on the built-in after moving back, no plugin rows left. TestPluginUsage, TestCommandCodeSubscriptionUnread and TestMove (the plugin's rows after moving back) fail without the change. go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./... pass (TestClaudeSignedOut and TestUserPath timed out once at load 22, pass alone).
|
2026-09-30 22:58:56 +08:00 |
|
|
yetone
|
a08b061b2f
|
commandcode: a Command Code Go-plan account is served through the gateway in the CLI's own format, at /alpha/generate (Discord #general, Mikan: 有计划支持command code的go plan吗，走他们的私有格式) — Go has no Provider API access, so magpie's Command Code Plan subscription, which asks api.commandcode.ai/provider, could not serve a Go account. Read from command-code 1.72.2's bundle: the CLI asks POST /alpha/generate for the models Command Code hosts, with {config, memory:null, taste:null, skills:null, permissionMode, params:{model, messages, tools, system, max_tokens, stream, temperature?, reasoning_effort?}} (createModelClient, toWireMessages: text / tool-call / reasoning parts, tool results as role "tool" tool-result parts, images as data URLs), the headers of buildCommandAuthHeaders (User-Agent cli, x-command-code-version, x-cli-environment production, x-project-slug, x-taste-learning, x-session-id, Bearer key), and reads newline-delimited JSON back (text-delta, reasoning-delta, tool-call, finish with totalUsage, error, abort). Its plan table lets individual-go / individual-go-v1 use the "opensource" models less a blocked list. Now: an account's plan is read from /alpha/billing/subscriptions and kept 10 minutes per key (the Usage page's read refreshes it; a failed read falls back to the sign-in's plan and is retried after a minute; GOAT is not taken for Go). A Go account is asked at /alpha/generate, translated to and from Anthropic Messages, OpenAI chat and Responses, streamed or not, tool calls included, and lists Go's models from the CLI's table (GPT-6 Luna, GPT-5.6 Luna, DeepSeek V4 Pro/Flash, Kimi K3, GLM-5.3, MiniMax M3, Qwen 3.8 Max/Flash, MiMo V2.6 Pro); MODEL_NOT_IN_PLAN is a 403 and exhausted credits a 402, so routing moves on; token counts are estimated locally. Pro, Max, Ultra, GOAT and Teams accounts go on the Provider API as before. Tested with internal/gateway/commandcode_test.go and internal/provider/commandcode_go_test.go against a fake Command Code in a temp HOME: a Go account routed to /alpha/generate and a Pro one to /provider/v1/messages, the request body and headers, streamed Anthropic, chat and Responses (streamed and not) with text, reasoning, a tool call and usage, MODEL_NOT_IN_PLAN over HTTP and in the stream, credits run out, a stream error, a reply cut short, the plan cached, re-read and falling back; also under -race. They fail with the routing off. go vet, go build -tags nogui (and GOOS=linux, GOOS=windows) and go test -tags nogui ./... pass. Not tried with a real Go account: which models Go allows today, whether the server checks config, project slug or session id, the usage arithmetic with cache tokens, real errors' codes, and pause_turn (ended rather than resent).
|
2026-09-30 08:37:57 +08:00 |
|
|
yetone
|
6546033109
|
kiro: removing kiro-cli's or the Kiro IDE's own sign-in hides it in magpie, and it shows again when Kiro signs in anew (Discord 碳碳双键: 本机没安装 kiro，但旧的 Kiro 数据还在，magpie 列出一个"Kiro account"（登录已失效，请重新添加此账号），添加新账号并设为首位后，旧的数据无法移除) — magpie reads Kiro's own sign-in from kiro-cli's database or ~/.aws/sso/cache and lists it among the accounts it signed in; Remove on it said "that is kiro-cli's or the Kiro IDE's own sign-in; run kiro-cli logout or sign out in the IDE", which with neither installed left a dead account there for good. The same refusal was shared by every agent whose own sign-in magpie only reads (forgetSideLogin: Kiro, Devin, Grok, Copilot, ZCode, WorkBuddy and WorkBuddy AI, Command Code, Gemini CLI, Antigravity). Now Remove on the agent's own sign-in hides it: logins.json's entry for it keeps a Hidden mark, and it is left out of the account list and so of the gateway's tries (the first and the ones behind it both come from that list); the agent's files are never deleted or written. It shows again when that sign-in changes: for Kiro, by a mark that is a digest of where the sign-in is (kiro-cli's row or the IDE's file) and its refresh token (never the token itself), so a new kiro-cli login or IDE sign-in, to any account, brings it back; for the others, which have no such mark, when it is another account. Removing it while it is first is allowed now, the next account being put first (saved, so it stays first when the own one comes back); removed when it was the only one, the agent has no account left. One of magpie's own accounts is removed with its home as before, and still can't be while it is first. The error and its per-agent sign-out hints are gone. Logins carry own, and the accounts list shows Remove on the agent's own sign-in also while it is first, its title "magpie stops showing and using Kiro's own sign-in; its files are left as they are, and it shows again when Kiro signs in anew" (magpie 不再显示和使用 Kiro 自己的登录；它的文件保持原样，Kiro 重新登录后会再次出现). Tested with a new internal/provider/side_logins_hide_test.go in a sandbox HOME: an expired kiro-cli sign-in ("Kiro account") behind a Google one magpie signed in is removed, stays gone across reads, isn't the account used nor among AlsoOn, kiro-cli's database byte-for-byte and mtime as it was, the refresh token nowhere in magpie's files; a new kiro-cli sign-in brings it back behind the one first; put first and removed, the next is first; one of magpie's removed takes its home and leaves the other's; the only account removed leaves Kiro with none; Grok's CLI sign-in hidden with auth.json untouched, back once it is another account. The agents' tests that expected the refusal (Command Code, Copilot, Devin, Grok, WorkBuddy, ZCode) no longer do. A new internal/gui/tests/own-signin-remove.test.cjs in Chromium and WebKit, en and zh: kiro-cli's sign-in behind another and alone first both have Remove with that title and post login/forget, magpie's first account has none. go build -tags nogui (and GOOS=linux, GOOS=windows), go test -tags nogui ./... and the whole GUI suite (138) pass. Not tried with a real Kiro, kiro-cli or the Kiro IDE.
|
2026-09-29 23:52:33 +08:00 |
|
|
yetone
|
bdb1dfdd1b
|
providers: a Command Code sign-in goes through when whoami errs on the new key (tigger_ultra on X: Sign-in didn't finish · Command Code didn't take the new key: Internal Server Error) — magpie asked /alpha/whoami to name the account of the key Studio had just posted, and failed the sign-in on any answer but a 200; whoami answered that key with a 500. The CLI's own browser sign-in never asks whoami (it keeps the key and the name Studio posts; whoami is its check on a key typed in, and only a 401 there means a bad key). Now only whoami turning the key down (401, 403) fails it; any other error is asked again twice, a second apart, and then passed over for the name Studio sent, the plan still read from billing/subscriptions. With no name from Studio either, it fails saying so. Tested: TestCommandCodeSignInWhoamiDown, a fake Command Code whose whoami answers 500: signed in as the posted name with its plan after three asks, a 401 key refused, no name at all refused; go test -tags nogui ./... (TestClaudeSignedOut failed once under load, passes on its own with and without the change and in a rerun), GOOS=linux build
|
2026-09-29 17:41:26 +08:00 |
|
|
yetone
|
b0c42d738e
|
subscription: a Command Code plan's 5-hour and weekly windows show on the Usage page and the panel (ARNO: command code plan的五小时额度，周额度等订阅信息没有显示到用量面板里) — the plan's card was read right (billing/credits as command-code 1.66's /usage reads it: credits.{planId, monthlyCredits, purchasedCredits, freeCredits}, windowLimits.{limited, fiveHour, weekly}.{used, cap, resetAt in ms} beside it) but also carried the dollars left as its Balance, and a card's Balance is shown in place of its windows everywhere (the panel, the Usage page, the TUI): the windows were read and never drawn. The dollars are now a Credits window, used of the CLI's own pool (the plan's month — Go $10, Pro $30 or $80 for pro-v1, Provider $15, GOAT $70, Teams Pro $40, Max $150, Ultra $300 — or what is left of it if more, plus bought and free credits), "$spent / $pool"; only a reply with no windows and no known plan is a Balance still. A plan's key on the keyed commandcode preset gets the same windows as a plan card (api.commandcode.ai is a plan quota source; a pay-as-you-go key has none and no card), and its balance card is the dollars left alone rather than "5h 42% · week 18% · $12.30" squeezed into one amount. billing/credits carries no planId (4b21f62 found it so on a live account), so the pool's month is the plan billing/subscriptions names; an account with no plan and no windows shows what it bought as its Balance
|
2026-09-29 00:22:50 +08:00 |
|
|
yetone
|
4b21f62e89
|
commandcode: a plan's usage says its plan (为什么Command Code Plan没有用量？) — billing/credits has no planId, so the plan (and the account's badge) came up empty; it's read from billing/subscriptions: planId, currentPeriodEnd as when it ends, cancelAtPeriodEnd as whether it renews, and an account with none is "No plan" (无订阅). The plan is said even when billing/credits fails — Command Code answers it 503, "Couldn't verify your credit balance just now", at times — and an account with a balance but no 5-hour or weekly window shows the balance instead of 暂无用量数据. Checked against a live GOAT account: GOAT, $70.00, both windows
|
2026-09-29 00:19:00 +08:00 |
|
|
yetone
|
fa3ea3149a
|
subscription: Command Code Plan, signed in from magpie (Yetone 老师，CommandCode 也是有登录订阅额度的，并不是类似中转的那种哇 — @RookieRicardoR) — a Command Code plan (Pro, GOAT, Max, Ultra) is now a subscription under 订阅, not only the keyed relay preset: Add signs in with the CLI's own browser sign-in (commandcode.ai/studio/auth/cli posting the new key to a callback on 127.0.0.1, answered as the CLI does, 303 to its complete page; wrong state 403, access_denied fails), whoami names the account and billing/credits its plan; the CLI's own account is read from ~/.commandcode/auth.json, never changed, others kept in logins.json with switch/on/forget like ZCode's. Its models are served from the Provider API (/provider/v1 Chat and Responses, /provider Messages) with the plan's key, billed against the plan's credits; usage shows the 5-hour and weekly windows with their resets and the credits left. Its id is commandcode-plan, since commandcode is the keyed preset's
|
2026-09-28 23:24:19 +08:00 |
|