 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
|
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
|
e54ebf397a
|
accounts: signing in again to an agent's own account removed in magpie brings it back (#320) — removing the account an agent CLI is signed in to (Command Code, Kiro, Devin, Grok, Copilot…) only hides it, and a sign-in from magpie to that same account was dropped as its duplicate with the account still hidden: the sign-in said done, and "signed in, but magpie can't list it". The hidden mark now comes off. TestCommandCodeSignInAgainToRemovedOwn fails without the change. go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./... pass.
|
2026-09-30 18:47:03 +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 |
|