@mars-sea/dsh-commandcode-provider 0.11.6 → 0.11.8

package/CHANGELOG.md

@@ -6,6 +6,21 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 
 ## [Unreleased]
 
+## [0.11.8] - 2026-09-22
+
+### Changed
+
+- **Synced with the official command-code@1.62.0 CLI** (2026-09-22 check of the 2026-09-21 npm `latest`; five releases since the last sync — 1.58.1, then the 1.59.0/1.60.0/1.61.0/1.62.0 train whose changelog entries are "Add Grok 4.7", "Add Step 5 Preview", "Grok 4.7 40% off" and "Add MiMo V2.6 Flash / Add MiMo V2.6 Pro and Pro UltraSpeed"). `COMMAND_CODE_CLI_VERSION` is now `1.62.0`. This train is purely additive: the CLI registry grows 78 → 83 with exactly five additions and no removal or edit, so five models gain their picker annotations and prices. `xai/grok-4.7` (500K context, text+image, `low`/`medium`/`high`/`xhigh` efforts, GOAT and above) launches on a 40% off deal running 2026-09-21 → 2026-09-27 that reverts to $2.00 in / $6.00 out when it lapses; its snapshotted rates are the discounted $1.20 in / $3.60 out / $0.30 cache read, doubling to $2.40 / $7.20 / $0.60 past 200K, and the deal carries the page's own expiry stamp so the badge hides itself after that instant. `stepfun/Step-5-Preview` is StepFun's 600B sparse-MoE agentic coding model (1M context, text+image, `low`/`medium`/`high` efforts, Go, $1.00 / $2.70 / $0.05). The MiMo V2.6 family is text+image with a 1,048,576-token context and no reasoning flag in any source: `xiaomi/mimo-v2.6-flash` ($0.14 / $0.28 / $0.0028) and `xiaomi/mimo-v2.6-pro` ($0.435 / $0.87 / $0.0036) on Go, plus `xiaomi/mimo-v2.6-pro-ultraspeed` on GOAT and above ($4.35 / $8.70 / $0.036). In snapshot terms: the effort map gains exactly two keys (46 → 48), the Vision set the five (52 → 57), the plan map three Go and two GOAT entries without moving a tier (46/52/65/72 → 49/57/70/77), the deals five → six, and the vendored price table exactly the five matching rows (71 → 76) with no rate change to any existing row (`node scripts/sync-model-prices.mjs --check` now reports all 76 rows up to date). Everything else is re-verified unchanged against both bundles and the public sources: the subscription plan maps, the peak/off-peak membership and schedule (01:00–04:00 and 06:00–10:00 UTC, Monday–Friday only), the automatic-reasoning set, and the public catalog — which serves 76 models (71 + the five) with its route mix moving 55 → 60 × chat/completions + responses exactly by those additions, the same 8 Claude ids still messages-only and 8 models still chat/completions-only, which agrees with the adapter's `claude-*` routing rule. Static inspection of the two bundles finds no transport drift: the `/alpha/*` endpoint set, the `/alpha/generate` converters (`toWireMessages`/`toWireTools`/`toWireToolOutput`), the stream event vocabulary, the `x-command-code-version` header, the browser-login call site and the web-search field names differ only by minified variable renames, and the documented Provider API endpoint set is unchanged. Two CLI-local changelog items reach nothing this adapter owns: 1.58.1's "Auto-compact past images and keep their result" (the CLI's own compaction behavior, not a wire change) and 1.59.0's YOLO/accept-edits keybinding rework. The two upstream leftovers stay deliberately un-snapshotted, exactly as the previous check recorded them: `gpt-6-astra` is still a CLI/pricing/docs-only model the public catalog does not serve, and the pricing page still embeds an already-expired (`2026-06-22`) `qwen-3.7-max-2x-usage` deal record its own Deals section does not list.
+
+## [0.11.7] - 2026-09-20
+
+### Fixed
+- **A plain 429 is no longer reported as an exhausted usage window** ([#54](https://github.com/Mars-Sea/dsh-commandcode-provider/issues/54)). The report was a contradiction: the turn failed with `llm-commandcode: all 1 Command Code account(s) have exhausted their usage window` while the account card at that moment showed the five-hour window at 2% ($0.22 / $14.00) and the weekly one at 10% ($3.43 / $35.00), and the reporter noted it only reproduced at the default reasoning effort and always recovered by itself a little later. The message was the tell: it carried no "the earliest window resets at …" clause, and that clause appears only when a mark is a `cooldown` with a known reset — so the pool was reporting an exhausted window from a mark that had no reset at all, i.e. from nothing but a 429. The chain: `classifyAccountRejection()` treated ANY 429 (or a bare `RATE_LIMITED` code) as a usage-window rejection, `markRejected()` filed it as `unknown`, the follow-up `/alpha/billing/credits` probe either failed (the same account was still being refused) or read no reset, and `allAccountsUnusable()` then asserted "exhausted their usage window" regardless of the evidence — exactly the sentence the reporter was shown. Classification now follows the official CLI's own bar (command-code@1.56.0 `parseWindowLimitError` → `resolveWindowLabel`): a rejection is a WINDOW limit only when the body names one — `error.rateLimit.window` of `fiveHour`/`weekly`/`daily`, or the "usage limit for your plan" wording — and `readWindowLimitEvidence()` reads that window and its `reset` (seconds, with the `resets at <ISO>` wording as the fallback) in one place. Everything else stays a new `throttled` reason: it rotates and marks the key exactly like a window limit does (so rotation across a multi-account pool is unchanged, and a burst or model-level limiter still moves the request off that key), but the mark carries a `cause` — `window`, `throttle` or `auth` — and only a `window` cause may be described as an exhausted window. A throttle mark is deliberately left `unknown` with no reset, so the next all-marked pass still probes the real windows and upgrades the cause to `window` when a probe reads one as exceeded; a throttle mark that a probe cannot confirm now answers `all N Command Code account(s) are rate limited (429) — the provider did not report an exhausted usage window; retrying` instead, with no invented reset and no invented wait. The same honesty was applied to a window mark whose provider published no reset (`— the provider published no reset time for it` / `，服务商未公布重置时间`), where the old message silently said nothing, and the adapter's end-of-turn `RATE_LIMIT` for a non-429 status carrying a bare `RATE_LIMITED` now says the same thing. `tests/accounts.test.ts` pins the throttle diagnosis (and that it never claims a window), the probe upgrade from throttle to window, the reset-stamped window cooldown, and the no-reset wording; `tests/adapter.test.ts` pins the classification of a bare 429 as `throttled`, the three window-carrying shapes as `rate-limit` (including the plan-usage-limit wording and a window without a reset), and the end-of-turn message.
+
+### Changed
+
+- **Synced with the official command-code@1.58.0 CLI** (2026-09-20 check of the 2026-09-19 npm `latest`, whose changelog entry is "Retire the free LongCat 2.0 tier and sell LongCat 2.0 as a paid model"). `COMMAND_CODE_CLI_VERSION` is now `1.58.0`. The CLI registry grows 77 → 78 with exactly one addition — the paid `meituan/LongCat-2.0` — while its retired `meituan/LongCat-2.0:free` sibling gains `hidden` and the display name "LongCat 2.0 (Free)": that is the CLI catching up with the backend rename the 1.57.0 sync had already snapshotted, so no capability-snapshot entry moves, the model was already served under the paid id at $0.30 in / $1.20 out / $0.006 cache read on Go, and no runtime behavior changes. Everything else is re-verified unchanged against both the bundle and the public sources: the per-model effort map, the subscription plan maps (8 plans including their monthly credits), every plan tier (map still 46/52/65/72), the five model deals, the peak/off-peak membership and schedule (01:00–04:00 and 06:00–10:00 UTC, Monday–Friday only), the vendored price table (`node scripts/sync-model-prices.mjs --check` reports all 71 rows up to date), and the public catalog (71 models, its `supported_endpoints` mix still 55 × chat/completions + responses, the same 8 Claude ids × messages-only, 8 × chat/completions, which agrees with the adapter's `claude-*` routing rule). Static inspection of both bundles finds no transport drift: the `/alpha/*` endpoint set, the `/alpha/generate` converters (`toWireMessages`/`toWireTools`/`toWireToolOutput`), the stream event vocabulary, the `x-command-code-version` header, the browser-login call site and the web-search field names are byte-identical to 1.57.0, and the documented Provider API endpoint set is unchanged. Two upstream leftovers stay deliberately un-snapshotted, exactly as the previous check recorded them: `gpt-6-astra` is still a CLI/pricing/docs-only model the public catalog does not serve, and the pricing page still embeds an already-expired (`2026-06-22`) `qwen-3.7-max-2x-usage` deal record that its own Deals section does not list. The Provider API docs now also document the optional `x-cmd-zdr: 1` zero-data-retention header (the CLI parity of `CMD_ZDR=1`); this plugin does not send it, because ZDR opt-in would be a new feature rather than a data sync.
+
 ## [0.11.6] - 2026-09-19
 
 ### Fixed

package/lib/client.js

@@ -2157,7 +2157,7 @@ window.__ModuleLoader__.load({
 		}
 		//#endregion
 		//#region package.json
-		var version = "0.11.6";
+		var version = "0.11.8";
 		var repository = {
 			"type": "git",
 			"url": "git+https://github.com/Mars-Sea/dsh-commandcode-provider.git"

package/lib/index.d.ts

@@ -7,7 +7,7 @@ import { Context } from "@deepseek-ai/cordis";
 import { AttachmentStore, ImageAttachmentRef } from "@deepseek-ai/dsh-attachment";
 import { CommandDefinition } from "@deepseek-ai/dsh-commands";
 //#region src/adapter.d.ts
-declare const COMMAND_CODE_CLI_VERSION = "1.57.0";
+declare const COMMAND_CODE_CLI_VERSION = "1.62.0";
 declare const DEFAULT_API_BASE = "https://api.commandcode.ai";
 declare const DEFAULT_GENERATE_MAX_TOKENS = 64000;
 declare const DEFAULT_MAX_OUTPUT_TOKENS = 65536;
@@ -101,14 +101,19 @@ interface CommandCodeConnectionOptions {
  */
 type ResolveAttachments = () => AttachmentStore | undefined;
 /**
- * Why a pre-stream rejection rotates to another account. `rate-limit` and
- * `invalid-credential` are the two the pool records as marks; `unavailable` is
- * an account-scoped rejection that must NOT become a mark — the account's key
- * is valid and its windows may be open, the ACCOUNT just cannot serve THIS
+ * Why a pre-stream rejection rotates to another account. `rate-limit` (a usage
+ * window the provider NAMED), `throttled` (a 429 that named no window) and
+ * `invalid-credential` are the three the pool records as marks; `unavailable`
+ * is an account-scoped rejection that must NOT become a mark — the account's
+ * key is valid and its windows may be open, the ACCOUNT just cannot serve THIS
  * request (no credits, a model outside its plan) — so the pool moves on
  * without remembering anything.
+ *
+ * The window/throttle split decides what the pool may CLAIM, never whether it
+ * rotates: both leave rotation and mark the key, but only a named window lets
+ * the pool report an exhausted usage window (issue #54).
  */
-type AccountRotationReason = 'rate-limit' | 'invalid-credential' | 'unavailable';
+type AccountRotationReason = 'rate-limit' | 'throttled' | 'invalid-credential' | 'unavailable';
 /** What the rotation hook knows about the request it is rotating within. */
 interface AccountRotationContext {
   /** Every API key this request has already used, just-rejected key included. */
@@ -461,8 +466,21 @@ interface CommandCodeAccountSlot {
   /** Whether the official CLI auth file may back this slot (default slot only). */
   allowAuthFile: boolean;
 }
-/** Why a key stopped serving requests. */
-type AccountRejection = 'rate-limit' | 'invalid-credential';
+/**
+ * Why a key stopped serving requests.
+ *
+ * `rate-limit` is a USAGE-WINDOW rejection: the provider named one of its
+ * metered windows (`error.rateLimit.window`, or a message saying the plan's
+ * usage limit was reached — the only two shapes the official CLI's own
+ * `parseWindowLimitError`/`resolveWindowLabel` accept). `throttled` is the
+ * plain 429: the provider refused the request without saying anything about a
+ * window, so the key leaves rotation for now but the pool must not describe it
+ * as an exhausted window. Collapsing the two is issue #54: the reporter's
+ * account panel showed the five-hour window at 2% and the weekly one at 10%
+ * while the turn failed with "all 1 Command Code account(s) have exhausted
+ * their usage window".
+ */
+type AccountRejection = 'rate-limit' | 'throttled' | 'invalid-credential';
 /** One key's rotation state. */
 interface CommandCodeAccountState {
   kind:
@@ -472,6 +490,14 @@ interface CommandCodeAccountState {
   'cooldown' |
   /** Marked by a 401: skipped until the stored credential changes. */
   'disabled';
+  /**
+   * The evidence behind the mark — what the pool may CLAIM when it reports
+   * that no account can serve. `window`: the provider named a usage window, or
+   * a `/alpha/billing/credits` probe read one as exceeded. `throttle`: a 429
+   * that said nothing about a window (a burst limiter, or a model- or
+   * spend-level limit the billing endpoint cannot show). `auth`: a 401.
+   */
+  cause: 'window' | 'throttle' | 'auth';
   /** Human-readable reason for the mark (e.g. `rate limited (429)`). */
   reason: string;
   /** Cooldown end in millis; 0 for the other kinds. */
@@ -628,16 +654,21 @@ declare class CommandCodeAccountPool {
     slot: CommandCodeAccountSlot;
   } | undefined>;
   /**
-   * Record a rejection against one key. `rate-limit` marks the key exhausted
-   * (`429`/`RATE_LIMITED`) — as a `cooldown` until `resetAtMs` when the
-   * rejection body published the provider's own reset time, otherwise as an
-   * `unknown` mark whose reset is probed lazily — and `invalid-credential`
-   * (401) disables the key until the stored credential changes.
+   * Record a rejection against one key. `rate-limit` marks the key's usage
+   * WINDOW exhausted — as a `cooldown` until `resetAtMs` when the rejection
+   * body named the provider's own reset time, otherwise as an `unknown` mark
+   * whose window is probed lazily. `throttled` (the plain 429 that named no
+   * window) marks the key with the `throttle` cause instead: it leaves rotation
+   * exactly like a window mark does, but the pool's own diagnosis keeps saying
+   * "rate limited" rather than inventing an exhausted window. A 401
+   * (`invalid-credential`) disables the key until the stored credential
+   * changes.
    *
    * `resetAtMs` is seconds-to-millis converted by the adapter from the
    * provider's `error.rateLimit.reset`: knowing the real reset immediately is
    * what keeps an exhausted account out of rotation for exactly as long as the
-   * provider said, instead of until a probe happens to run.
+   * provider said. It only applies to a window mark; a plain throttle keeps the
+   * window unknown on purpose, so a probe can still find out.
    */
   markRejected(apiKey: string, rejection: AccountRejection, resetAtMs?: number): void;
   /**
@@ -778,7 +809,11 @@ declare const KNOWN_THINKING_MODELS: ReadonlySet<string>;
  * free `inclusionai/ling-3.0-flash-sante:free` (Go); command-code@1.53.0
  * added `deepseek/deepseek-v4.1-flash` (Go); command-code@1.56.0 added
  * `Qwen/Qwen3.8-Omni-Flash` (Go); command-code@1.57.0 added
- * `z-ai/glm-5.3-flashx` (Go).
+ * `z-ai/glm-5.3-flashx` (Go); command-code@1.59.0 added `xai/grok-4.7` (GOAT)
+ * and 1.60.0 added `stepfun/Step-5-Preview` (Go); command-code@1.62.0 added the
+ * MiMo V2.6 family — `xiaomi/mimo-v2.6-flash` + `xiaomi/mimo-v2.6-pro` (Go) and
+ * `xiaomi/mimo-v2.6-pro-ultraspeed` (GOAT) — so the 1.58.0 -> 1.62.0 window's
+ * only tier changes are additions and the superset chain still holds.
  *
  * The Provider API exposes no plan metadata, so this snapshot is the source of
  * truth for the picker's plan annotation — it answers "which plan do I need to

package/lib/index.js

@@ -203,6 +203,11 @@ const KNOWN_EFFORTS = {
 		"high"
 	],
 	"sakana/fugu-ultra": ["high", "xhigh"],
+	"stepfun/Step-5-Preview": [
+		"low",
+		"medium",
+		"high"
+	],
 	"tencent/hy4-preview": [
 		"low",
 		"medium",
@@ -219,6 +224,12 @@ const KNOWN_EFFORTS = {
 		"high",
 		"xhigh"
 	],
+	"xai/grok-4.7": [
+		"low",
+		"medium",
+		"high",
+		"xhigh"
+	],
 	"z-ai/glm-5.3-flash": [
 		"low",
 		"high",
@@ -340,11 +351,16 @@ const KNOWN_IMAGE_MODELS = /* @__PURE__ */ new Set([
 	"moonshotai/Kimi-K3",
 	"sakana/fugu-ultra",
 	"stepfun/Step-3.7-Flash",
+	"stepfun/Step-5-Preview",
 	"thinkingmachines/inkling",
 	"thinkingmachines/inkling-small",
 	"xai/grok-4.5",
 	"xai/grok-4.6",
+	"xai/grok-4.7",
 	"xiaomi/mimo-v2.5",
+	"xiaomi/mimo-v2.6-flash",
+	"xiaomi/mimo-v2.6-pro",
+	"xiaomi/mimo-v2.6-pro-ultraspeed",
 	"z-ai/glm-5.3-flash",
 	"z-ai/glm-5.3-flashx"
 ]);
@@ -458,7 +474,11 @@ function requiresMessagesEndpoint(modelId) {
 * free `inclusionai/ling-3.0-flash-sante:free` (Go); command-code@1.53.0
 * added `deepseek/deepseek-v4.1-flash` (Go); command-code@1.56.0 added
 * `Qwen/Qwen3.8-Omni-Flash` (Go); command-code@1.57.0 added
-* `z-ai/glm-5.3-flashx` (Go).
+* `z-ai/glm-5.3-flashx` (Go); command-code@1.59.0 added `xai/grok-4.7` (GOAT)
+* and 1.60.0 added `stepfun/Step-5-Preview` (Go); command-code@1.62.0 added the
+* MiMo V2.6 family — `xiaomi/mimo-v2.6-flash` + `xiaomi/mimo-v2.6-pro` (Go) and
+* `xiaomi/mimo-v2.6-pro-ultraspeed` (GOAT) — so the 1.58.0 -> 1.62.0 window's
+* only tier changes are additions and the superset chain still holds.
 *
 * The Provider API exposes no plan metadata, so this snapshot is the source of
 * truth for the picker's plan annotation — it answers "which plan do I need to
@@ -501,6 +521,7 @@ const KNOWN_PLANS = {
 	"poolside/laguna-s-2.1-free": "go",
 	"stepfun/Step-3.5-Flash": "go",
 	"stepfun/Step-3.7-Flash": "go",
+	"stepfun/Step-5-Preview": "go",
 	"tencent/hy3-paid": "go",
 	"tencent/hy4-preview": "go",
 	"thinkingmachines/inkling": "go",
@@ -508,6 +529,8 @@ const KNOWN_PLANS = {
 	"xai/grok-4.5": "go",
 	"xiaomi/mimo-v2.5": "go",
 	"xiaomi/mimo-v2.5-pro": "go",
+	"xiaomi/mimo-v2.6-flash": "go",
+	"xiaomi/mimo-v2.6-pro": "go",
 	"z-ai/glm-5.3-flash": "go",
 	"z-ai/glm-5.3-flashx": "go",
 	"zai-org/GLM-5": "go",
@@ -521,6 +544,8 @@ const KNOWN_PLANS = {
 	"meta/muse-spark-1.2": "goat",
 	"meta/muse-spark-1.3": "goat",
 	"xai/grok-4.6": "goat",
+	"xai/grok-4.7": "goat",
+	"xiaomi/mimo-v2.6-pro-ultraspeed": "goat",
 	"claude-haiku-4-5-20251001": "pro",
 	"claude-sonnet-4-6": "pro",
 	"claude-sonnet-5": "pro",
@@ -691,6 +716,10 @@ const KNOWN_DEALS = {
 	"MiniMaxAI/MiniMax-M3": { label: "50% off" },
 	"xiaomi/mimo-v2.5-pro": { label: "99% off" },
 	"xiaomi/mimo-v2.5": { label: "98% off" },
+	"xai/grok-4.7": {
+		label: "40% off",
+		expiresAt: "2026-09-27T23:59:59.999Z"
+	},
 	"poolside/laguna-s-2.1-free": {
 		label: "FREE",
 		free: true
@@ -1273,6 +1302,26 @@ const MODEL_PRICE_ROWS = [
 			1
 		] }]
 	},
+	{
+		id: "grok-4.7",
+		rates: [
+			1.2,
+			3.6,
+			.3
+		],
+		contextTiers: [{
+			"maxContext": 2e5,
+			"rates": [
+				1.2,
+				3.6,
+				.3
+			]
+		}, { "rates": [
+			2.4,
+			7.2,
+			.6
+		] }]
+	},
 	{
 		id: "inkling",
 		rates: [
@@ -1353,6 +1402,30 @@ const MODEL_PRICE_ROWS = [
 			.0036
 		]
 	},
+	{
+		id: "mimo-v2.6-flash",
+		rates: [
+			.14,
+			.28,
+			.0028
+		]
+	},
+	{
+		id: "mimo-v2.6-pro",
+		rates: [
+			.435,
+			.87,
+			.0036
+		]
+	},
+	{
+		id: "mimo-v2.6-pro-ultraspeed",
+		rates: [
+			4.35,
+			8.7,
+			.036
+		]
+	},
 	{
 		id: "minimax-m2.5",
 		rates: [
@@ -1578,6 +1651,14 @@ const MODEL_PRICE_ROWS = [
 			.04
 		]
 	},
+	{
+		id: "step-5-preview",
+		rates: [
+			1,
+			2.7,
+			.05
+		]
+	},
 	{
 		id: "tencent/hy3-paid",
 		rates: [
@@ -1924,10 +2005,11 @@ function installCostProjection(ctx) {
 *     usable, the routed account — resolving each slot's key lazily (literal
 *     config key → credential seam → launch environment → the official CLI
 *     auth file for the default slot only).
-*   - {@link CommandCodeAccountPool.markRejected} records a 429 (rate limit,
-*     window unknown) or 401 (invalid key, disabled until the config changes)
-*     against the exact API key, so several slots sharing one key share one
-*     state.
+*   - {@link CommandCodeAccountPool.markRejected} records a 429 or 401 against
+*     the exact API key, so several slots sharing one key share one state. A
+*     429 that NAMED a usage window marks the window exhausted; a 429 that
+*     named none is recorded as a plain throttle, which rotates the same way
+*     but is never reported as an exhausted window (issue #54).
 *   - When every account is marked, the pool probes each key's
 *     `/alpha/billing/credits` window limits (through the injected
 *     {@link CommandCodeAccountPoolDeps.probeWindow}): an account whose window
@@ -2125,9 +2207,16 @@ var CommandCodeAccountPool = class {
 			}
 			if (probe.resetAt > 0) this.states.set(account.key, {
 				kind: "cooldown",
-				reason: account.state?.reason ?? "rate limited (429)",
+				cause: "window",
+				reason: account.state?.reason ?? "usage window exhausted (429)",
 				until: probe.resetAt
 			});
+			else if (account.state?.kind !== "cooldown") this.states.set(account.key, {
+				kind: "unknown",
+				cause: "window",
+				reason: account.state?.reason ?? "usage window exhausted (429)",
+				until: 0
+			});
 		}));
 		const latestAccounts = await this.resolvedAccounts();
 		const revived = selectActiveAccount(tried === void 0 || tried.length === 0 ? latestAccounts : latestAccounts.filter((account) => !tried.includes(account.key)), preferred);
@@ -2136,31 +2225,45 @@ var CommandCodeAccountPool = class {
 		throw allAccountsUnusable(latestAccounts.length > 0 ? latestAccounts : accounts);
 	}
 	/**
-	* Record a rejection against one key. `rate-limit` marks the key exhausted
-	* (`429`/`RATE_LIMITED`) — as a `cooldown` until `resetAtMs` when the
-	* rejection body published the provider's own reset time, otherwise as an
-	* `unknown` mark whose reset is probed lazily — and `invalid-credential`
-	* (401) disables the key until the stored credential changes.
+	* Record a rejection against one key. `rate-limit` marks the key's usage
+	* WINDOW exhausted — as a `cooldown` until `resetAtMs` when the rejection
+	* body named the provider's own reset time, otherwise as an `unknown` mark
+	* whose window is probed lazily. `throttled` (the plain 429 that named no
+	* window) marks the key with the `throttle` cause instead: it leaves rotation
+	* exactly like a window mark does, but the pool's own diagnosis keeps saying
+	* "rate limited" rather than inventing an exhausted window. A 401
+	* (`invalid-credential`) disables the key until the stored credential
+	* changes.
 	*
 	* `resetAtMs` is seconds-to-millis converted by the adapter from the
 	* provider's `error.rateLimit.reset`: knowing the real reset immediately is
 	* what keeps an exhausted account out of rotation for exactly as long as the
-	* provider said, instead of until a probe happens to run.
+	* provider said. It only applies to a window mark; a plain throttle keeps the
+	* window unknown on purpose, so a probe can still find out.
 	*/
 	markRejected(apiKey, rejection, resetAtMs) {
 		if (rejection === "invalid-credential") this.states.set(apiKey, {
 			kind: "disabled",
+			cause: "auth",
 			reason: "invalid API key (401)",
 			until: 0
 		});
+		else if (rejection === "throttled") this.states.set(apiKey, {
+			kind: "unknown",
+			cause: "throttle",
+			reason: "rate limited (429)",
+			until: 0
+		});
 		else if (resetAtMs !== void 0 && resetAtMs > Date.now()) this.states.set(apiKey, {
 			kind: "cooldown",
-			reason: "rate limited (429)",
+			cause: "window",
+			reason: "usage window exhausted (429)",
 			until: resetAtMs
 		});
 		else this.states.set(apiKey, {
 			kind: "unknown",
-			reason: "rate limited (429)",
+			cause: "window",
+			reason: "usage window exhausted (429)",
 			until: 0
 		});
 	}
@@ -2255,9 +2358,16 @@ var CommandCodeAccountPool = class {
 		}
 		if (probe.resetAt > 0) this.states.set(account.key, {
 			kind: "cooldown",
-			reason: account.state?.reason ?? "rate limited (429)",
+			cause: "window",
+			reason: account.state?.reason ?? "usage window exhausted (429)",
 			until: probe.resetAt
 		});
+		else if (account.state?.kind !== "cooldown") this.states.set(account.key, {
+			kind: "unknown",
+			cause: "window",
+			reason: account.state?.reason ?? "usage window exhausted (429)",
+			until: 0
+		});
 	}
 	/** Hand out the chosen account's key. */
 	pick(account) {
@@ -2268,26 +2378,39 @@ var CommandCodeAccountPool = class {
 	}
 };
 /**
-* The error for "accounts exist but none of them can serve": all-401 becomes
-* `INVALID_CREDENTIAL`, anything else `RATE_LIMIT` naming the earliest known
-* window reset. Shared by the all-marked tail of {@link CommandCodeAccountPool.resolveKey}
+* The error for "accounts exist but none of them can serve". Three shapes, each
+* claiming only what the pool actually knows:
+*
+*   - every account rejected with 401 → `INVALID_CREDENTIAL`;
+*   - at least one account marked by a NAMED usage window (or by a probe that
+*     read a window as exceeded) → the window diagnosis, naming the earliest
+*     known reset when the provider published one;
+*   - every mark a plain throttle (a 429 that said nothing about a window, and
+*     no probe could confirm one) → a throttle diagnosis that says so. Claiming
+*     "all accounts have exhausted their usage window" here is issue #54: the
+*     report's account panel showed the five-hour window at 2% and the weekly
+*     one at 10% while the turn failed with exactly that sentence.
+*
+* Shared by the all-marked tail of {@link CommandCodeAccountPool.resolveKey}
 * and by its already-tried diagnosis, so the two can never drift apart.
 *
 * The attached `providerRetryAfterMs` is the exact wait until the earliest
-* known reset, so dsh-llm-retry sleeps through the window instead of polling
-* at its backoff cadence. It is capped at {@link RETRY_MAX_DELAY_MS}: the
-* executor honors a provider wait verbatim only at or below the policy's
+* known window reset, so dsh-llm-retry sleeps through the window instead of
+* polling at its backoff cadence. It is capped at {@link RETRY_MAX_DELAY_MS}:
+* the executor honors a provider wait verbatim only at or below the policy's
 * `maxDelayMs` — a LONGER attached wait makes it abandon the retry entirely
 * (normal mode), which would turn "poll until the window opens" into "fail
 * now". Longer resets simply ride the capped local backoff and the probe
-* revival.
+* revival. A throttle diagnosis attaches none: its marks carry no reset.
 */
 function allAccountsUnusable(accounts) {
 	if (accounts.filter((account) => account.state?.kind === "disabled").length === accounts.length) return new LlmError(`llm-commandcode: every configured Command Code account (${accounts.length}) was rejected with 401 — check the stored API keys (Models page / settings) or the auth file；已配置的 ${accounts.length} 个 Command Code 账户密钥均被拒绝（401）——请在设置页检查存储的 API 密钥，或重新运行 command-code login`, "INVALID_CREDENTIAL");
-	const resets = accounts.map((account) => account.state).filter((state) => state !== void 0 && state.kind === "cooldown" && state.until > 0).map((state) => state.until);
+	const windowMarked = accounts.map((account) => account.state).filter((state) => state !== void 0).filter((state) => state.cause === "window");
+	if (windowMarked.length === 0) return new LlmError(`llm-commandcode: all ${accounts.length} Command Code account(s) are rate limited (429) — the provider did not report an exhausted usage window; retrying；全部 ${accounts.length} 个 Command Code 账户被限流（429）——服务商未报告用量窗口用尽，正在重试`, "RATE_LIMIT");
+	const resets = windowMarked.filter((state) => state.kind === "cooldown" && state.until > 0).map((state) => state.until);
 	const earliest = resets.length > 0 ? Math.min(...resets) : 0;
 	const wait = earliest > 0 ? Math.max(1e3, earliest - Date.now()) : 0;
-	return new LlmError(`llm-commandcode: all ${accounts.length} Command Code account(s) have exhausted their usage window` + (earliest > 0 ? `; the earliest window resets at ${clockLabel(earliest)}` : "") + ` — requests will succeed again after the reset (or add another account)；已用尽全部 ${accounts.length} 个 Command Code 账户的用量窗口` + (earliest > 0 ? `，最早的重置时间为 ${clockLabel(earliest)}` : "") + "——窗口重置后请求会自动恢复（也可以添加更多账户）", "RATE_LIMIT", wait > 0 && wait <= 9e5 ? { providerRetryAfterMs: wait } : void 0);
+	return new LlmError(`llm-commandcode: all ${accounts.length} Command Code account(s) have exhausted their usage window` + (earliest > 0 ? `; the earliest window resets at ${clockLabel(earliest)}` : " — the provider published no reset time for it") + ` — requests will succeed again after the reset (or add another account)；已用尽全部 ${accounts.length} 个 Command Code 账户的用量窗口` + (earliest > 0 ? `，最早的重置时间为 ${clockLabel(earliest)}` : "，服务商未公布重置时间") + "——窗口重置后请求会自动恢复（也可以添加更多账户）", "RATE_LIMIT", wait > 0 && wait <= 9e5 ? { providerRetryAfterMs: wait } : void 0);
 }
 /**
 * Normalize one resolved credential to the form every consumer sees. Trim
@@ -2538,7 +2661,7 @@ function scaleBy(size, factor) {
 * and API key or subscription, and Command Code's terms apply.
 *
 * Wire protocol (reverse-engineered by the pi plugin, command-code@1.28.4;
-* re-verified against command-code@1.57.0 — endpoints, request shape, and
+* re-verified against command-code@1.62.0 — endpoints, request shape, and
 * stream events unchanged):
 *   POST {apiBase}/alpha/generate
 *   body: { config, memory, taste, skills, params: { model, messages, tools,
@@ -2551,7 +2674,7 @@ function scaleBy(size, factor) {
 * per-request options thunk and an API-key resolver from the plugin entry
 * (src/index.ts), so a settings change reaches the very next request.
 */
-const COMMAND_CODE_CLI_VERSION = "1.57.0";
+const COMMAND_CODE_CLI_VERSION = "1.62.0";
 const DEFAULT_API_BASE = "https://api.commandcode.ai";
 const DEFAULT_GENERATE_MAX_TOKENS = 64e3;
 const DEFAULT_MAX_OUTPUT_TOKENS = 65536;
@@ -4272,11 +4395,12 @@ var CommandCodeAdapter = class extends LlmAdapter {
 					continue;
 				}
 			}
-			if (rejection?.reason === "rate-limit" && (rejection.resetAtMs !== void 0 || attempt.status !== 429)) {
+			if (rejection !== void 0 && (rejection.reason === "rate-limit" || rejection.reason === "throttled") && (rejection.resetAtMs !== void 0 || attempt.status !== 429)) {
 				const reset = rejection.resetAtMs;
 				const wait = reset === void 0 ? 0 : Math.min(Math.max(1e3, reset - Date.now()), RETRY_MAX_DELAY_MS);
 				const when = reset === void 0 ? void 0 : new Date(reset).toISOString();
-				throw new LlmError("llm-commandcode: the Command Code account is rate limited" + (when === void 0 ? "" : ` — the provider reports it resets at ${when}`) + "；当前 Command Code 账户已被限流" + (when === void 0 ? "" : `，服务商给出的重置时间为 ${when}`), "RATE_LIMIT", wait > 0 ? { providerRetryAfterMs: wait } : void 0);
+				const window = rejection.reason === "rate-limit";
+				throw new LlmError((window ? "llm-commandcode: the Command Code account is rate limited" : "llm-commandcode: the Command Code account is rate limited (429) — the provider did not report an exhausted usage window") + (when === void 0 ? "" : ` — the provider reports it resets at ${when}`) + (window ? "；当前 Command Code 账户已被限流" : "；当前 Command Code 账户被限流（429），服务商未报告用量窗口用尽") + (when === void 0 ? "" : `，服务商给出的重置时间为 ${when}`), "RATE_LIMIT", wait > 0 ? { providerRetryAfterMs: wait } : void 0);
 			}
 			throw generateHttpError(attempt.status, attempt.errText, attempt.retryAfterMs);
 		}
@@ -4687,10 +4811,19 @@ function mapFinishReason(reason) {
 * the host should do with them, which is the caller's decision, not this
 * function's:
 *
-*   - `rate-limit`: a usage window is spent. The code `RATE_LIMITED` is the
+*   - `rate-limit`: a usage WINDOW is spent. The code `RATE_LIMITED` is the
 *     authoritative signal — the CLI accepts the code OR a 429 status — and the
 *     body's `error.rateLimit` names the window and its `reset` (in seconds),
 *     so the host can hold the account out until the provider's own reset time.
+*   - `throttled`: the provider refused the request (429 or a bare
+*     `RATE_LIMITED` code) without naming a usage window. It is account-scoped
+*     like the above, so it rotates and marks the key the same way, but it is
+*     NOT evidence that a metered window is spent: the CLI's own
+*     `parseWindowLimitError` returns a window limit only when
+*     `resolveWindowLabel` can name one, and a burst/model/spend limiter the
+*     billing endpoint cannot see is exactly this shape (issue #54's report: a
+*     429 whose probe read five-hour 2% and weekly 10% while the error claimed
+*     both were exhausted).
 *   - `invalid-credential`: 401; the key itself is bad.
 *   - `unavailable`: the key is fine but this account cannot serve: no credits
 *     (`400 Insufficient credits`, the codes `INSUFFICIENT_CREDITS`,
@@ -4702,10 +4835,11 @@ function mapFinishReason(reason) {
 */
 function classifyAccountRejection(status, errText) {
 	if (status === 429 || readProviderErrorCode(errText)?.toUpperCase() === "RATE_LIMITED") {
-		const resetAtMs = readWindowResetAtMs(errText);
-		return resetAtMs === void 0 ? { reason: "rate-limit" } : {
+		const evidence = readWindowLimitEvidence(errText);
+		if (evidence.window === void 0) return { reason: "throttled" };
+		return evidence.resetAtMs === void 0 ? { reason: "rate-limit" } : {
 			reason: "rate-limit",
-			resetAtMs
+			resetAtMs: evidence.resetAtMs
 		};
 	}
 	if (status === 401) return { reason: "invalid-credential" };
@@ -4726,31 +4860,44 @@ function readProviderErrorCode(errText) {
 	}
 }
 /**
-* The exact reset time carried by a window-limit rejection body, in millis.
-* The CLI reads `error.rateLimit.reset` as SECONDS (`1e3 * reset`) and falls
-* back to a `resets at <ISO>` stamp in the message; both are honored here so a
-* 429 does not need a billing probe to learn a fact the provider already told
-* us. Undefined when the body carries neither.
-*/
-function readWindowResetAtMs(errText) {
+* The usage-window evidence carried by a rejected request, mirroring the CLI's
+* `parseWindowLimitError` → `resolveWindowLabel`/`extractResetAtMs` pair.
+*
+* `window` is present only when the body actually names one: a
+* `error.rateLimit.window` of `fiveHour`/`weekly`/`daily`, or the
+* "usage limit for your plan" wording (read as `weekly` when it says so, else
+* `fiveHour`). That is the CLI's own bar for calling a rejection a WINDOW
+* limit, and it is what keeps a bare 429 — a burst limiter, a model-level
+* limit, a spend cap `windowLimits` cannot show — from being reported as an
+* exhausted window (issue #54).
+*
+* `resetAtMs` is the reset the body publishes: `error.rateLimit.reset` is
+* SECONDS (`1e3 * reset`, like the CLI), and a `resets at <ISO>` stamp in the
+* message is honored as the fallback. Either can be present without the other;
+* the window label is what decides the classification.
+*/
+function readWindowLimitEvidence(errText) {
+	let named;
+	let message = "";
+	let seconds;
 	try {
 		const parsed = JSON.parse(errText);
 		if (isRecord(parsed)) {
 			const error = isRecord(parsed.error) ? parsed.error : parsed;
-			const seconds = numberValue((isRecord(error.rateLimit) ? error.rateLimit : void 0)?.reset);
-			if (seconds !== void 0 && seconds > 0) return Math.round(seconds * 1e3);
-			const message = stringValue(error.message) ?? "";
-			const stamp = /resets at (\d{4}-\d{2}-\d{2}T[\d:.]+Z)/i.exec(message)?.[1];
-			if (stamp !== void 0) {
-				const at = Date.parse(stamp);
-				if (!Number.isNaN(at)) return at;
-			}
+			const rateLimit = isRecord(error.rateLimit) ? error.rateLimit : void 0;
+			named = stringValue(rateLimit?.window);
+			message = stringValue(error.message) ?? stringValue(parsed.message) ?? "";
+			seconds = numberValue(rateLimit?.reset);
 		}
 	} catch {}
-	const stamp = /resets at (\d{4}-\d{2}-\d{2}T[\d:.]+Z)/i.exec(errText)?.[1];
-	if (stamp === void 0) return void 0;
-	const at = Date.parse(stamp);
-	return Number.isNaN(at) ? void 0 : at;
+	const window = named === "fiveHour" || named === "weekly" || named === "daily" ? named : /usage limit for your plan/i.test(message) || /usage limit for your plan/i.test(errText) ? /weekly/i.test(message) ? "weekly" : "fiveHour" : void 0;
+	const stamp = /resets at (\d{4}-\d{2}-\d{2}T[\d:.]+Z)/i.exec(message)?.[1] ?? /resets at (\d{4}-\d{2}-\d{2}T[\d:.]+Z)/i.exec(errText)?.[1];
+	const stamped = stamp === void 0 ? void 0 : Date.parse(stamp);
+	const resetAtMs = seconds !== void 0 && seconds > 0 ? Math.round(seconds * 1e3) : stamped !== void 0 && !Number.isNaN(stamped) ? stamped : void 0;
+	return {
+		...window === void 0 ? {} : { window },
+		...resetAtMs === void 0 ? {} : { resetAtMs }
+	};
 }
 function isUpgradeRequiredError(status, errText) {
 	if (status !== 403) return false;