 yetone
|
9992678c64
|
zcode: an account with no GLM Coding Plan uses ZCode's Start Plan (体验套餐) where ZCode does, with ZCode's own token, and shows its allowance (#236 tasselx: ZCode 3.14.4, magpie 0.1.410, a trial-only account, the free quota not read and every request refused with rate_limit_error "ZCode: [1113][Insufficient balance or no resource package. Please recharge.]"; #225 xiaozhu1337: ZCode ships a built-in trial package) — magpie sent every ZCode account to the Coding Plan's endpoint, api.z.ai/api/anthropic, with the account's zcode-api-key, and read its allowance only from /api/monitor/usage/quota/limit. That key is billed to a Coding Plan, or else to the account's API balance, so an account with only the Start Plan got 1113. ZCode itself (ZCode.app 3.14.3's zcode-builtin.json providerRules and host/index.js: resolveCurrent, buildZaiStartPlanBalanceUrl, hasActiveStartPlan, isZaiStartPlanIdentity, normalizeStartPlanExpiry, normalizeZaiStartPlanBalanceLimits, pollPendingOAuth) serves the Start Plan (account:zai-start-plan and account:bigmodel-start-plan) from zcode.z.ai/api/v1/zcode-plan/anthropic, keyed by its own session token (the credential store's zcodejwttoken, the token its sign-in's poll hands back, which magpie dropped), and reads what is left from /api/v1/zcode-plan/billing/balance?app_version= with that token. Now, in a new zcode_start.go: an account keeps ZCode's token beside its key (zcodeKey.JWT; zcodeOwn reads zcodejwttoken, and user_info from oauth:bigmodel:user_info when there is no Z.ai one; an account with the token and no coding plan key is an account). Whether it is on the Start Plan is asked of /api/biz/subscription/list (a Coding Plan: as before; none: the Start Plan; can't tell: the Start Plan if its balance has an active one), kept 10 minutes (1 when unsure); with no token it is the Coding Plan as before, asking nothing, and with no key it is the Start Plan. On the Start Plan a request is moved to zcode-plan/anthropic, signed with the token (x-api-key and Bearer) and ZCode's own headers (User-Agent ZCode/<ver>, X-ZCode-App-Version, X-Title, HTTP-Referer, X-Platform), refused with "sign in to ZCode again" once the token has run out; its models are the Start Plan's (zcodePlanID account:zai-start-plan for ZCode's config, zcodeModels less GLM-5.3 before it is read). Its allowance is the balance as ZCode reads it: a plan still "active" past ends_at (by server_time) is expired and the buckets of expired plans left out; the plan's name (Start Plan) with Until its end and Renew off; a window per bucket, named by its show_name (or its models, or Credits), Used and "used / total" from total/used/remaining units (numbers or strings), ResetsAt its expires_at, Span from its entitlement's period (daily/weekly/monthly) or period_start..end, and matched to the bucket's models. Signing in from magpie no longer refuses an account with no Coding Plan: with an active Start Plan it is added on that (its key kept too, so a Coding Plan bought later is used), and refused only when the Start Plan is over as well ("this Z.ai account has no GLM Coding Plan, and ZCode's Start Plan has ended or was never started — subscribe at z.ai/subscribe, then add it again"). Accounts with a Coding Plan are routed, signed and metered as before. The provider keeps the name ZCode (#225 asked for "GLM Coding Plan"; ZCode names these plans "Z.AI Individual Coding Plan" and "Start Plan", and the plan line already shows "GLM Coding <Level>"). Tested with a new internal/provider/zcode_start_test.go against a fake Z.ai/zcode.z.ai in a sandbox HOME, no real tokens: ZCode signed in with only its token (BigModel user_info) is an account, its provider served at zcode-plan/anthropic, a request signed with the token and ZCode's headers, the Start Plan's models and plan id, its allowance (Start Plan, Until, Renew off, GLM-5.1's window 25%, "250000 / 1000000", reset, a day's span, matching GLM-5.1 only); an expired plan and one active past its end give none; with a key and the token, no Coding Plan moves the request (query kept) to the Start Plan and it reaches it with the token, a Coding Plan keeps it on api.z.ai with the key and no ZCode headers, no token asks nothing, an expired token is refused; a sign-in with only the Start Plan is added on it, with a Coding Plan on that plan, with neither refused naming both. TestZCodeAccounts passes unchanged. go build -tags nogui (and GOOS=linux, GOOS=windows), go vet and go test -tags nogui ./... pass (TestUpdateCLI, TestClaudeSignedOut, TestClaudeAccountNamedAsItsLogin and TestUserPath timed out once each under load beside other builds and pass alone). Not tried with a real Start Plan account: the endpoint's acceptance of the token as x-api-key/Bearer and whether it needs ZCode's headers, the balance's real field values and period strings, what subscription/list returns for a trial-only account, and ZCode 3.14.4 (read from 3.14.3) are from ZCode's code, not seen on the wire.
|
2026-09-30 02:15:50 +08:00 |
|
|
yetone
|
9eccb96a51
|
provider: ZCode's and WorkBuddy's models take the reasoning levels their apps offer them (当然要做) — ZCode's from its modelRules' reasoningLevel (disabled is none; enabled, GLM-5-Turbo's one level, is high): GLM-5.3 low/high/max, GLM-5.2 none/high/max; WorkBuddy's from its config's reasoning.supportedEfforts, with none only where its CLI offers thinking off (deepseek-v4-pro): hy3 low/high, glm-5.2 high/xhigh, kimi-k3-1 low/high/xhigh, and a model it gives no levels still takes any. The written-in lists carry them too. gateway: Z.ai's GLM-5.2 and GLM-5.3 are asked their effort in output_config.effort beside thinking on, as ZCode asks them, built or passed through and fitted to their levels — a budget alone left them at their default: tested live, budget_tokens 4096 thought 4.8k–7.6k chars, output_config low 0.9k
|
2026-09-28 18:56:04 +08:00 |
|
|
yetone
|
e8eb7078db
|
provider: ZCode's and WorkBuddy's plans list the models their apps offer now, not a list written into magpie (我觉得一定有API来查询动态的模型列表) — ZCode's come from its built-in provider config, which zcode.z.ai names (/api/v1/client/configs → a release on cdn-zcode.z.ai) and ZCode also ships and caches: the later revision of those is read, as ZCode does, the coding plan's models taken from its providerRules and builtinProviderModelRules (bigmodel.cn's plan its own), and each one's context, output limit and images from the modelRules that match it; WorkBuddy's come from its product config, GET /v3/config signed as a chat, asked with the CLI's User-Agent (CLI/<v> WorkBuddy/<v>; a bare WorkBuddy/<v> gets CodeBuddy IDE's config), its cli agent's models with their names, input and output limits and images — Kimi-K2.8-Preview is there now, and Auto is 256k. The written-in lists are what shows before the first read. Tested live against both with the accounts signed in here
|
2026-09-28 18:26:07 +08:00 |
|