dsh-connect-minimaxcode 0.5.7 → 0.5.8

package/README.en.md

@@ -283,6 +283,27 @@ Two sets of data each cover one thing:
 
   > The official price list has no separate price for **cache writes** (`cache_creation_input_tokens`), so the plugin counts its tokens but **does not convert them to money**, to avoid quoting a number that has no public basis.
 
+### Account usage profile
+
+The account's **usage history** comes from the open platform's usage summary, and it is a different thing from the token count the pill reports: the latter counts only the requests this host made.
+
+```
+GET https://www.minimaxi.com/backend/account/token_plan/usage_summary?token_type=5&heatmap_days=365&business=Agent&device_platform=desktop
+Authorization: Bearer <OAuth 令牌>
+```
+
+The card shows the parts worth acting on:
+
+| Field | Meaning |
+| --- | --- |
+| `current_consecutive_days` | Days used in a row |
+| `active_days` / `total_days` | Days with usage in the window / the window's length |
+| `total_token_consumed` | Tokens consumed in the window, in the upstream's own wording (`826.14M`) |
+| `usage_ranking_percent` | Where the account ranks by usage |
+| `most_active_day` | The busiest day and what it consumed |
+
+This data **needs no M Plan subscription**: the endpoint is an account one, read with the OAuth bearer, unlike the limit windows, which belong to the subscription.
+
 ### About token refresh
 
 The OAuth token is valid for about an hour and is refreshed automatically by the client. The plugin **only refreshes it once, with the refresh token the app already stored, when its own token has expired**, and writes the rotated new tokens back to the same file atomically, in the client's **original format** (with `generation` unchanged), so the desktop app's login state is unaffected. The plugin never starts a login, never signs out, and never calls any paid or subscription endpoint.
@@ -308,6 +329,15 @@ The OAuth token is valid for about an hour and is refreshed automatically by the
 
 ## Changelog
 
+### 0.5.8 (2026-11-10)
+
+- **Fixed "M3's reasoning could not be turned off"**: the plugin used to declare "reasoning cannot be disabled" for *every* reasoning model, on the grounds that the gateway refuses `thinking: {type: "disabled"}` with `400 ... requires adaptive thinking`. That refusal only holds for a `forced_on` model: the upstream catalog states `thinking_config.mode` per model, and `MiniMax-M3` is `switchable` (measured: the disabled form is accepted, 200) while `MiniMax-M3.1-Flash` is `forced_on` (measured: 400). Each model is now handled as upstream describes it: **M3's reasoning levels now include "off"**, and picking it really does stop the reasoning — fewer tokens, lower latency. M3.1-Flash is unchanged and the option still does not appear.
+  Upstream's `effort_options` (six levels for M3.1-Flash: default/low/medium/high/xhigh/max) are parsed and recorded but **not wired**: pi-ai's level mapping still dispatches the budget form, and reaching those six levels would switch the whole request shape, which this change does not do.
+- **New "account usage profile"**: reads the open platform's `GET /backend/account/token_plan/usage_summary` (a constant this plugin had defined and never used). The card shows the consecutive days of use, the active days in the window, the tokens consumed in it, the usage ranking and the busiest day. It describes the *account*'s history, which is a different thing from the token count the pill reports for this host.
+- **Says why there are no limit windows**: an account without an M Plan subscription gets `2062 no active token plan subscription` from upstream (already recognised in 0.5.7). The card now states that outright instead of leaving the reader to assume a failed read.
+- **Endpoint survey**: every one of the twenty account-domain endpoints the desktop app calls each day was mapped — **nineteen of them are readable with the OAuth bearer and need no subscription at all**. What a subscription buys is not more endpoints but two things: the limit windows and a larger allowance.
+- Added `tests/usage-profile.spec.ts` (16 cases) plus reasoning-mode cases in `tests/catalog.spec.ts` / `tests/adapter.spec.ts`. All 236 cases pass.
+
 ### 0.5.7 (2026-11-10)
 
 - **The quota readout now uses the open platform's documented endpoint**: the plugin read `/backend/account/token_plan/remains_percent`, and that path now answers every account with an empty `success` — it no longer even carries a `model_remains` field — so the readout showed nothing for anyone and said nothing about why. It now reads `GET /v1/token_plan/remains`, the endpoint the open platform's own M Plan documentation names. That endpoint asks for the **open platform's API key** rather than the OAuth bearer; the key comes from the `token_plan_credit` response and is remembered between reads.

package/README.md

@@ -319,6 +319,27 @@ Authorization: Bearer <API Key>
 - **没有订阅就没有窗口，且这不算错误**：上游对未订阅 M Plan 的账户明确回 `2062 no active token plan subscription`，插件会如实标为「无订阅」而不是「读取失败」—— 积分包本身不带滚动窗口
 - **接口异常时其余显示不受影响**：限额读不到，胶囊与卡片仍显示余额、签到与本机用量
 - 上游还发 `current_*_count` 计数字段（无计数制时为 `-1`），插件只读百分比与起止时刻
+### 账户用量画像
+
+账户的**用量历史**由开放平台的用量汇总接口给出，与「本机累计 token」是两回事 —— 后者只统计这台机器发起的请求：
+
+```
+GET https://www.minimaxi.com/backend/account/token_plan/usage_summary?token_type=5&heatmap_days=365&business=Agent&device_platform=desktop
+Authorization: Bearer <OAuth 令牌>
+```
+
+卡片显示的是其中有行动价值的几项：
+
+| 字段 | 含义 |
+| --- | --- |
+| `current_consecutive_days` | 连续使用天数 |
+| `active_days` / `total_days` | 统计窗口内有使用的天数 / 窗口长度 |
+| `total_token_consumed` | 窗口内累计消耗（上游自己的写法，如 `826.14M`） |
+| `usage_ranking_percent` | 用量排名分位 |
+| `most_active_day` | 最活跃的一天及其消耗 |
+
+这一节读到的数据**不需要订阅 M Plan**：该接口属于账户域，用 OAuth 令牌即可读取，与限额窗口（属于订阅）不同。
+
 ### 关于续期
 
 OAuth 令牌有效期约 1 小时，由客户端自动续期。插件**只在自己的令牌已过期时**才用 App 已存的 refresh token 续一次，并把轮换后的新令牌按客户端**原格式原子写回**同一个文件（`generation` 保持不变），因此桌面 App 的登录态不受影响。插件不会发起登录、不会登出、也不会调用任何付费/订阅类接口。
@@ -344,6 +365,15 @@ OAuth 令牌有效期约 1 小时，由客户端自动续期。插件**只在自
 
 ## 更新记录
 
+### 0.5.8（2026-11-10）
+
+- **修复「M3 的推理关不掉」**：插件此前对**所有**推理模型都声明「不支持关闭推理」，理由是网关会以 `400 ... requires adaptive thinking` 拒绝 `thinking: {type: "disabled"}`。但该拒绝只对 `forced_on` 的模型成立 —— 上游模型目录逐模型声明 `thinking_config.mode`，`MiniMax-M3` 是 `switchable`（实测接受该形式，200），`MiniMax-M3.1-Flash` 才是 `forced_on`（实测 400）。现在按上游声明逐模型处理：**M3 的推理档位里出现了「关」**，选它就真的不发推理，既省 token 也更快；M3.1-Flash 的行为不变，选项仍不出现。
+  上游的 `effort_options`（M3.1-Flash 有 default/low/medium/high/xhigh/max 六档）也一并解析存档，但**未接线**：pi-ai 的档位映射目前走 budget 形式，要用上这六档得切换整个请求形态，这一步不在本次改动里。
+- **新增「账户用量画像」**：读取开放平台的 `GET /backend/account/token_plan/usage_summary`（该常量此前定义了却从未使用），卡片显示连续使用天数、统计窗口内的活跃天数、窗口内累计消耗、用量排名分位与最活跃的一天。它说的是**账户**的历史，与胶囊里「本机累计 token」是两回事。
+- **说明「为什么没有限额窗口」**：账户未订阅 M Plan 时，上游回 `2062 no active token plan subscription`（0.5.7 已识别）。现在卡片直接写明「未订阅 M Plan（仅积分包），因此没有限额窗口」，而不是让人以为读取失败。
+- **接口盘点**：把桌面 App 每天真实调用的 20 个账户域接口全部盘了一遍 —— 其中 **19 个用 OAuth 令牌即可读取，无需任何订阅**，只有「限额窗口」属于订阅本身。也就是说订阅 M Plan 换来的不是「更多接口」，而是**限额窗口**与**更高额度**这两样。
+- 新增 `tests/usage-profile.spec.ts`（16 个用例）与 `tests/catalog.spec.ts` / `tests/adapter.spec.ts` 的推理模式用例。全量 236 个用例通过。
+
 ### 0.5.7（2026-11-10）
 
 - **限额窗口改走官方文档接口**：原先读的是 `/backend/account/token_plan/remains_percent`，这条路径现在对任何账户都只回一个空的 `success`（连 `model_remains` 字段都没有），于是限额一栏对所有人都显示不出来，却看不出原因。改用开放平台官方文档（M Plan 用量说明页）给出的 `GET /v1/token_plan/remains`。新接口要求**开放平台 API 密钥**而非 OAuth 令牌，密钥取自 `token_plan_credit` 的响应并缓存复用。

package/lib/client.js

@@ -68,6 +68,13 @@
         claimableToday: '今日可签到',
         usageWindow: '{duration}限额',
         resetIn: '{duration}后',
+        accountUsage: '账户用量',
+        usageStreak: '连续使用 {days} 天',
+        usageActiveDays: '近 {total} 天中有 {active} 天用过',
+        usageTotalTokens: '累计消耗 {count} tokens',
+        usageRanking: '用量排名前 {percent}%',
+        usageBestDay: '最活跃的一天 {date}',
+        planNoSubscription: '未订阅 M Plan（仅积分包），因此没有限额窗口',
     };
     const en = {
         title: 'MiniMax Code credits',
@@ -110,6 +117,13 @@
         claimableToday: 'Claimable today',
         usageWindow: '{duration} limit',
         resetIn: 'resets in {duration}',
+        accountUsage: 'Account usage',
+        usageStreak: '{days} days in a row',
+        usageActiveDays: 'Used on {active} of the last {total} days',
+        usageTotalTokens: '{count} tokens consumed',
+        usageRanking: 'Top {percent}% by usage',
+        usageBestDay: 'Busiest day {date}',
+        planNoSubscription: 'No M Plan subscription (credits only), so there are no usage windows',
     };
     const loader = globalThis.__ModuleLoader__;
     if (loader === undefined)
@@ -259,6 +273,49 @@
                     return null;
                 return h('div', { style: expiryBoxStyle, 'data-minimax-rate-limit': true }, row(t('usageWindow', { duration: windowLabel(rateLimit.interval) }), `${rateLimit.interval.usedPercent}%(${t('resetIn', { duration: countdown(rateLimit.interval.resetAtMs) })})`), row(t('usageWindow', { duration: windowLabel(rateLimit.weekly) }), `${rateLimit.weekly.usedPercent}%(${t('resetIn', { duration: countdown(rateLimit.weekly.resetAtMs) })})`));
             }
+            /**
+             * The account's own usage history.
+             *
+             * This is not the token count of this host — the pill reports that
+             * separately — but the account's days, consumption and standing, which
+             * is what the upstream knows and nobody else does.
+             */
+            function usageProfileBlock(t, profile) {
+                if (profile === undefined || profile.state !== 'ok')
+                    return null;
+                const rows = [];
+                if (profile.consecutiveDays !== undefined && profile.consecutiveDays > 0) {
+                    rows.push(row(t('usageStreak', { days: profile.consecutiveDays }), ''));
+                }
+                if (profile.activeDays !== undefined) {
+                    rows.push(row(t('usageActiveDays', { active: profile.activeDays, total: profile.totalDays ?? '' }), ''));
+                }
+                if (profile.totalTokenConsumed !== undefined) {
+                    rows.push(row(t('usageTotalTokens', { count: profile.totalTokenConsumed }), ''));
+                }
+                if (profile.rankingPercent !== undefined) {
+                    rows.push(row(t('usageRanking', { percent: profile.rankingPercent.toFixed(1) }), ''));
+                }
+                if (profile.mostActiveDay?.date !== undefined) {
+                    rows.push(row(t('usageBestDay', { date: profile.mostActiveDay.date }), ''));
+                }
+                if (rows.length === 0)
+                    return null;
+                return h('div', { style: expiryBoxStyle, 'data-minimax-usage-profile': true }, ...rows);
+            }
+            /**
+             * Why there are no usage windows, when there are none because the plan
+             * has none to give.
+             *
+             * The rolling windows belong to the subscription; an account holding
+             * only a credit package has none, and saying so is more useful than
+             * leaving the reader to wonder whether a read failed.
+             */
+            function planNotice(t, rateLimit) {
+                if (rateLimit?.reason !== 'no-subscription')
+                    return null;
+                return h('div', { style: mutedStyle, 'data-minimax-plan-notice': true }, t('planNoSubscription'));
+            }
             /** The pill itself; the gate decides whether it is drawn at all. */
             function CreditPill(props) {
                 const [status] = useStatus();
@@ -291,7 +348,7 @@
                 const detail = available
                     ? h('div', { style: detailStyle, 'data-minimax-credits-detail': true }, row(t('free'), credits(credits_.free, 3)), row(t('purchased'), credits(credits_.purchased, 3)), credits_.consumed !== undefined && credits_.consumed > 0
                         ? row(t('consumed'), credits(credits_.consumed, 3))
-                        : null, expiryBlock(t, credits_), rateLimitBlock(t, status?.rateLimit), usage !== undefined
+                        : null, expiryBlock(t, credits_), rateLimitBlock(t, status?.rateLimit), planNotice(t, status?.rateLimit), usageProfileBlock(t, status?.usageProfile), usage !== undefined
                         ? h('div', { style: rowStyle }, h('span', null, t('tokens', { count: tokens(usage.inputTokens + usage.outputTokens + usage.cacheReadTokens) })), h('span', null, t('cost', { amount: money(usage.estimatedCny) })))
                         : null, credits_.updatedAtMs !== undefined
                         ? row(t('updated', { time: new Date(credits_.updatedAtMs).toLocaleTimeString() }), '')
@@ -432,11 +489,11 @@
                 if (!available) {
                     return h('div', { style: cardStyle, 'data-minimax-credits-card': true }, h('div', { style: cardTitleStyle }, t('title')), h('div', { style: rowStyle }, h('span', null, t('unavailable')), h('span', null, credits_?.state === 'expired' ? t('expired') : '')), loginBlock(t, login, refresh));
                 }
-                return h('div', { style: cardStyle, 'data-minimax-credits-card': true }, h('div', { style: cardTitleStyle }, t('title')), h('div', { style: bigNumberStyle }, t('balance', { total: credits(credits_.total, 2) })), row(t('free'), credits(credits_.free, 3)), row(t('purchased'), credits(credits_.purchased, 3)), expiryBlock(t, credits_), rateLimitBlock(t, status?.rateLimit), signinBlock(t, signin, refresh), h('div', { style: sectionTitleStyle }, t('lots')), (credits_.upcoming ?? []).length === 0
+                return h('div', { style: cardStyle, 'data-minimax-credits-card': true }, h('div', { style: cardTitleStyle }, t('title')), h('div', { style: bigNumberStyle }, t('balance', { total: credits(credits_.total, 2) })), row(t('free'), credits(credits_.free, 3)), row(t('purchased'), credits(credits_.purchased, 3)), expiryBlock(t, credits_), rateLimitBlock(t, status?.rateLimit), planNotice(t, status?.rateLimit), signinBlock(t, signin, refresh), h('div', { style: sectionTitleStyle }, t('lots')), (credits_.upcoming ?? []).length === 0
                     ? h('div', { style: mutedStyle }, t('noLots'))
                     : h('ul', { style: listStyle }, ...(credits_.upcoming ?? []).map((lot, index) => h('li', { key: `${lot.expireAtMs}-${index}`, style: rowStyle }, h('span', null, day(lot.expireAtMs)), h('span', null, credits(lot.amount, 2))))), usage !== undefined
                     ? h('div', { style: usageBoxStyle }, row(t('tokens', { count: tokens(usage.inputTokens + usage.outputTokens + usage.cacheReadTokens) }), ''), row(t('cost', { amount: money(usage.estimatedCny) }), ''), usage.requests > 0 ? row(t('requests', { count: usage.requests }), usage.lastModel ?? '') : null)
-                    : null, loginBlock(t, login, refresh), credits_.updatedAtMs !== undefined
+                    : null, usageProfileBlock(t, status?.usageProfile), loginBlock(t, login, refresh), credits_.updatedAtMs !== undefined
                     ? h('div', { style: mutedStyle }, t('updated', { time: new Date(credits_.updatedAtMs).toLocaleTimeString() }))
                     : null);
             }

package/lib/index.d.ts

@@ -133,6 +133,28 @@ interface CatalogModel {
   inputModalities: string[];
   /** Whether the model accepts images at all. */
   attachment: boolean;
+  /**
+   * Whether reasoning can be turned off for this model.
+   *
+   * Upstream states it per model in `thinking_config.mode`: a `switchable`
+   * model accepts `thinking: {type: "disabled"}`, a `forced_on` model refuses
+   * it with `400 ... requires adaptive thinking` (both measured against the live
+   * gateway on 2026-11-10). Absent means upstream did not say, which is read as
+   * "reasoning is mandatory".
+   */
+  reasoningOptional?: boolean;
+  /**
+   * The reasoning effort levels upstream declares (`effort_options`).
+   *
+   * Recorded rather than acted on. pi-ai's own level mapping still dispatches
+   * the budget form (`thinking: {type: "enabled", budget_tokens}`) for these
+   * models, so naming the levels here changes no request; the names are kept
+   * so the information is not lost when it becomes usable. Reaching them on
+   * the wire would need pi-ai's `compat.forceAdaptiveThinking`, which switches
+   * the request to the adaptive form — a change of shape this plugin does not
+   * make on the strength of a catalog field alone.
+   */
+  effortLevels?: string[];
 }
 /** Provider id registered with DSH, distinct from the upstream one. */
 declare const MINIMAXCODE_PROVIDER_ID = "minimaxcode";
@@ -150,6 +172,11 @@ declare const MINIMAXCODE_PROVIDER_ID = "minimaxcode";
  * reports: 512k is the billing tier boundary, and the gateway itself was
  * measured serving 946,206 tokens before refusing ~1,050,000 with
  * `invalid params, context window exceeds limit (2013)`.
+ *
+ * The reasoning modes are the upstream ones measured on 2026-11-10: `M3` is
+ * `switchable` and accepts `thinking: {type: "disabled"}`, `M3.1-Flash` is
+ * `forced_on` and refuses it. Encoding them here keeps the fallback honest
+ * about what the gateway accepts even when no catalog could be fetched.
  */
 declare const FALLBACK_MODELS: readonly CatalogModel[];
 /** Where the currently served list came from. */
@@ -385,6 +412,36 @@ declare function parseRateLimitWindows(document: unknown): RateLimitWindows | un
  * @returns The windows, or `undefined` when the response carries none.
  */
 declare function fetchRateLimitWindows(credential: OAuthCredential, region: MinimaxRegion, fetchImpl?: typeof fetch): Promise<RateLimitWindows | undefined>;
+/**
+ * The account's usage profile, as the upstream summarizes it.
+ *
+ * The desktop app asks for this once a day and shows it as a yearly heatmap
+ * with a few headline numbers. It is the only place the upstream says how the
+ * account actually uses its tokens, and none of it is visible elsewhere: the
+ * balance says how much is left, not how much was spent or how the account
+ * compares with other users.
+ */
+interface UsageProfile {
+  /** Days the summary window covers. */
+  totalDays?: number;
+  /** Days in the window that saw any usage. */
+  activeDays?: number;
+  /** Consecutive days of use up to today. */
+  currentConsecutiveDays?: number;
+  /** Tokens consumed in the window, in the upstream's own wording ("826.14M"). */
+  totalTokenConsumed?: string;
+  /** Where the account sits among other users, in percent (10.3 = above 89.7% of users). */
+  usageRankingPercent?: number;
+  /** The busiest day in the window. */
+  mostActiveDay?: {
+    date?: string;
+    tokenCount?: string;
+  };
+  /** When the upstream last refreshed the summary. */
+  lastUpdateTime?: string;
+  /** Daily token usage, oldest first. */
+  dailyTokenUsage?: number[];
+}
 /** What a quota read found. */
 interface RateLimitRead {
   /** The windows, when the plan meters any. */
@@ -440,14 +497,18 @@ declare class MinimaxCredits {
   get rateLimitAbsence(): 'no-subscription' | undefined;
   /** When the windows were last read. */
   get rateLimitAtMs(): number | undefined;
+  /** The account's usage profile as last read. */
+  get usageProfile(): UsageProfile | undefined;
+  /** Why the usage profile could not be read, when it could not. */
+  get usageProfileError(): string | undefined;
   /**
    * Read the balance and record how much was consumed since the last read.
    *
    * The credit ledger is read alongside it, but a ledger that cannot be read
    * never hides the balance: the two come from different endpoints and only
-   * the balance is essential. The rate-limit windows ride along under the
-   * same rule — they come from yet another endpoint, and none of the three
-   * takes the others down with it.
+   * the balance is essential. The rate-limit windows and the usage profile
+   * ride along under the same rule — they come from yet other endpoints, and
+   * none of the four takes the others down with it.
    *
    * @returns Whether the balance changed.
    */
@@ -467,6 +528,13 @@ declare class MinimaxCredits {
    * window that cannot be read leaves the last one on display.
    */
   refreshRateLimit(credential: OAuthCredential, region: MinimaxRegion, fetchImpl?: typeof fetch, now?: number): Promise<void>;
+  /**
+   * Read the account's usage profile.
+   *
+   * Same rule as the ledger: a failure is remembered but never thrown, and a
+   * profile that cannot be read leaves the last one on display.
+   */
+  refreshUsageProfile(credential: OAuthCredential, region: MinimaxRegion, fetchImpl?: typeof fetch): Promise<void>;
   /**
    * Read the windows from whichever endpoint can answer.
    *
@@ -940,6 +1008,36 @@ interface RateLimitStatus {
   /** Why the windows could not be read. */
   error?: string;
 }
+/**
+ * The account's usage profile, as the upstream summarizes it.
+ *
+ * This is the account's own history — how long it has been used, how much it
+ * has consumed, how it ranks — and it is a different thing from the usage
+ * this host has made, which the card reports separately.
+ */
+interface UsageProfileStatus {
+  /** Whether the profile could be read. */
+  state: 'ok' | 'unavailable';
+  /** Days the summary window covers. */
+  totalDays?: number;
+  /** Days in the window that saw any usage. */
+  activeDays?: number;
+  /** Consecutive days of use up to today. */
+  consecutiveDays?: number;
+  /** Tokens consumed in the window, in the upstream's own wording. */
+  totalTokenConsumed?: string;
+  /** Where the account sits among other users, in percent. */
+  rankingPercent?: number;
+  /** The busiest day in the window. */
+  mostActiveDay?: {
+    date?: string;
+    tokenCount?: string;
+  };
+  /** When the upstream last refreshed the summary. */
+  updatedAt?: string;
+  /** Why the profile could not be read. */
+  error?: string;
+}
 /** What the card renders. */
 interface StatusDocument {
   state: 'signed-in' | 'signed-out' | 'expired';
@@ -970,6 +1068,8 @@ interface StatusDocument {
   signin?: SigninStatus;
   /** How the plugin is signed in. */
   login?: LoginStatus;
+  /** The account's usage profile, when it could be read. */
+  usageProfile?: UsageProfileStatus;
 }
 /** Inputs the document is derived from. */
 interface StatusDeps {
@@ -998,6 +1098,8 @@ interface StatusDeps {
   signin?: SigninStatus;
   /** How the plugin is signed in. */
   login?: LoginStatus;
+  /** The account's usage profile, when the account API could be reached. */
+  usageProfile?: UsageProfileStatus;
 }
 /**
  * Build the card's status document.

package/lib/index.js

@@ -243,6 +243,11 @@ const MINIMAXCODE_PROVIDER_ID = "minimaxcode";
 * reports: 512k is the billing tier boundary, and the gateway itself was
 * measured serving 946,206 tokens before refusing ~1,050,000 with
 * `invalid params, context window exceeds limit (2013)`.
+*
+* The reasoning modes are the upstream ones measured on 2026-11-10: `M3` is
+* `switchable` and accepts `thinking: {type: "disabled"}`, `M3.1-Flash` is
+* `forced_on` and refuses it. Encoding them here keeps the fallback honest
+* about what the gateway accepts even when no catalog could be fetched.
 */
 const FALLBACK_MODELS = [{
 	id: "MiniMax-M3",
@@ -256,7 +261,8 @@ const FALLBACK_MODELS = [{
 		"image",
 		"video"
 	],
-	attachment: true
+	attachment: true,
+	reasoningOptional: true
 }, {
 	id: "MiniMax-M3.1-Flash",
 	name: "M3.1-Flash",
@@ -269,14 +275,20 @@ const FALLBACK_MODELS = [{
 		"image",
 		"video"
 	],
-	attachment: true
+	attachment: true,
+	reasoningOptional: false
 }];
+/** Whether two effort level lists name the same levels in the same order. */
+function sameEffortLevels(a, b) {
+	if (a === void 0 || b === void 0) return a === b;
+	return a.length === b.length && a.every((value, index) => value === b[index]);
+}
 /** Model with the same id, from a newer snapshot. */
 function sameCatalog(a, b) {
 	if (a.length !== b.length) return false;
 	return a.every((model, index) => {
 		const other = b[index];
-		return model.id === other.id && model.contextWindow === other.contextWindow && model.toolCall === other.toolCall && model.reasoning === other.reasoning && model.attachment === other.attachment;
+		return model.id === other.id && model.contextWindow === other.contextWindow && model.toolCall === other.toolCall && model.reasoning === other.reasoning && model.attachment === other.attachment && model.reasoningOptional === other.reasoningOptional && sameEffortLevels(model.effortLevels, other.effortLevels);
 	});
 }
 /** Keep only models whose id the upstream keys them by. */
@@ -313,6 +325,37 @@ function readContextWindow(raw, limit) {
 	}
 	return typeof limit.context === "number" ? limit.context : 2e5;
 }
+/**
+* Read upstream's `thinking_config.mode`.
+*
+* `switchable` is the only mode whose reasoning can be turned off; every
+* other value — including a missing block, which the gateway treats as
+* mandatory reasoning — leaves the model's reasoning required.
+*
+* @param raw - The upstream model entry.
+* @returns Whether reasoning is optional, or undefined when upstream said nothing.
+*/
+function readReasoningOptional(raw) {
+	const mode = (raw.thinking_config ?? {}).mode;
+	if (mode === "switchable") return true;
+	if (mode === "forced_on") return false;
+}
+/**
+* Read upstream's `effort_options`.
+*
+* The levels are recorded as upstream names them; nothing maps them onto a
+* request yet, because pi-ai's level mapping dispatches the budget form for
+* these models and the effort levels would need the adaptive form to travel.
+*
+* @param raw - The upstream model entry.
+* @returns The declared levels, or undefined when upstream declares none.
+*/
+function readEffortLevels(raw) {
+	const options = raw.effort_options;
+	if (!Array.isArray(options)) return void 0;
+	const names = options.filter((value) => typeof value === "string");
+	return names.length > 0 ? names : void 0;
+}
 /** Read the fields the upstream sends, tolerating their absence. */
 function readModel(id, raw) {
 	const limit = raw.limit ?? {};
@@ -327,7 +370,9 @@ function readModel(id, raw) {
 		toolCall: raw.tool_call === true,
 		reasoning: raw.reasoning === true,
 		inputModalities: input,
-		attachment: raw.attachment === true || input.includes("image")
+		attachment: raw.attachment === true || input.includes("image"),
+		reasoningOptional: readReasoningOptional(raw),
+		effortLevels: readEffortLevels(raw)
 	};
 }
 /**
@@ -500,12 +545,16 @@ const NO_COST = {
 *   anthropic client sends the resolved apiKey as `x-api-key`, and MiniMax
 *   rejects that alone with 401 "token is required"; it accepts both headers, so
 *   the bearer value is added alongside rather than replacing it.
-* - `thinkingLevelMap.off = null` marks "thinking off" as unsupported. Every
-*   MiniMax model here requires reasoning, and pi-ai answers an explicit
-*   `thinkingEnabled: false` with `thinking: {type: "disabled"}`, which the
-*   gateway refuses with `400 ... requires adaptive thinking`. Marking the level
-*   unsupported makes pi-ai omit the field instead, which the gateway accepts
-*   (and, correctly, hides the option that cannot work).
+* - `thinkingLevelMap.off` is how a model says "reasoning cannot be turned
+*   off". pi-ai answers an explicit `thinkingEnabled: false` with
+*   `thinking: {type: "disabled"}` whenever `off` is not `null`, and omits the
+*   field entirely when it is. Which of the two a model needs is upstream's
+*   call, not this plugin's: `thinking_config.mode` is `switchable` for a model
+*   that accepts the disabled form and `forced_on` for one that refuses it with
+*   `400 ... requires adaptive thinking` (both measured on 2026-11-10). So the
+*   restriction is declared only where it is real — pinning `off` to `null` for
+*   a switchable model would make its reasoning impossible to turn off, and
+*   leaving it unset for a forced_on model would make the gateway answer 400.
 *
 * @param model - Catalog entry to describe.
 * @param baseUrl - Region gateway base the anthropic client extends.
@@ -526,7 +575,7 @@ function toPiModel(model, baseUrl, authorization) {
 		contextWindow: model.contextWindow,
 		maxTokens: model.maxOutputTokens ?? 128e3,
 		...authorization === void 0 ? {} : { headers: { authorization } },
-		...model.reasoning ? { thinkingLevelMap: { off: null } } : {}
+		...model.reasoning ? model.reasoningOptional === true ? {} : { thinkingLevelMap: { off: null } } : {}
 	};
 }
 /**
@@ -717,7 +766,8 @@ function statusDocument(deps) {
 		...deps.rateLimit === void 0 ? {} : { rateLimit: deps.rateLimit },
 		...deps.usage === void 0 ? {} : { usage: deps.usage },
 		...deps.signin === void 0 ? {} : { signin: deps.signin },
-		...deps.login === void 0 ? {} : { login: deps.login }
+		...deps.login === void 0 ? {} : { login: deps.login },
+		...deps.usageProfile === void 0 ? {} : { usageProfile: deps.usageProfile }
 	};
 	if (auth.state === "expired") return {
 		...base,
@@ -793,6 +843,8 @@ const MINIMAX_OPEN_HOSTS = {
 const MEMBERSHIP_PATH = "/matrix/api/v1/commerce/get_membership_info";
 /** Credit ledger endpoint: per-grant amounts and expiry. */
 const CREDIT_DETAILS_PATH = "/minimax-cloud/api/v1/credit/details";
+/** Per-model token usage summary (open platform). */
+const USAGE_SUMMARY_PATH = "/backend/account/token_plan/usage_summary";
 /** Open-platform credit endpoint that carries the account's plan key. */
 const TOKEN_PLAN_CREDIT_PATH = "/backend/account/token_plan_credit";
 /**
@@ -1213,6 +1265,66 @@ async function fetchTokenPlanApiKey(credential, region, fetchImpl = fetch) {
 	const key = (await response.json()).api_key;
 	return typeof key === "string" && key.length > 0 ? key : void 0;
 }
+/**
+* Read a string field, ignoring anything that is not a string.
+*
+* The upstream's token counts carry their own unit ("826.14M"), so they are
+* kept as the wording it used rather than pulled apart into a number.
+*/
+function toText(value) {
+	return typeof value === "string" ? value : void 0;
+}
+/**
+* Read the usage profile out of a summary response.
+*
+* Every field is optional in practice: the upstream adds fields over time, and
+* an account with no history at all answers with a body that carries none of
+* them. A field that is missing — or that arrives in a shape this does not
+* recognise — is therefore reported as absent rather than as an error, so one
+* odd field never costs the whole profile. A body that is not an object at
+* all carries no profile and yields none.
+*/
+function parseUsageProfile(document) {
+	if (typeof document !== "object" || document === null || Array.isArray(document)) return void 0;
+	const record = document;
+	const day = record.most_active_day;
+	const mostActiveDay = typeof day === "object" && day !== null ? day : void 0;
+	const date = toText(mostActiveDay?.date);
+	const tokenCount = toText(mostActiveDay?.token_count);
+	const daily = Array.isArray(record.daily_token_usage) ? record.daily_token_usage.filter((entry) => typeof entry === "number" && Number.isFinite(entry)) : void 0;
+	return {
+		totalDays: toNumber$1(record.total_days),
+		activeDays: toNumber$1(record.active_days),
+		currentConsecutiveDays: toNumber$1(record.current_consecutive_days),
+		totalTokenConsumed: toText(record.total_token_consumed),
+		usageRankingPercent: toNumber$1(record.usage_ranking_percent),
+		mostActiveDay: date === void 0 && tokenCount === void 0 ? void 0 : {
+			date,
+			tokenCount
+		},
+		lastUpdateTime: toText(record.last_update_time),
+		dailyTokenUsage: daily
+	};
+}
+/**
+* Fetch the account's usage profile.
+*
+* The endpoint lives on the open-platform host and takes the same OAuth
+* bearer the membership endpoint takes; the JWT the model gateway accepts
+* does not work here. The query is the one the desktop app sends, and it is
+* not trimmed down: `token_type` picks which token kind is counted and
+* `heatmap_days` sets how far back the daily series reaches.
+*
+* @returns The profile, or `undefined` when the response carries no object.
+*/
+async function fetchUsageProfile(credential, region, fetchImpl = fetch) {
+	const response = await fetchImpl(`${MINIMAX_OPEN_HOSTS[region]}${USAGE_SUMMARY_PATH}?token_type=5&heatmap_days=365&business=Agent&device_platform=desktop`, { headers: {
+		accept: "application/json",
+		authorization: `Bearer ${credential.token}`
+	} });
+	if (!response.ok) throw new Error(`usage summary request failed: HTTP ${response.status}`);
+	return parseUsageProfile(await response.json());
+}
 /** The upstream's own code for "this account has no plan subscription". */
 const NO_SUBSCRIPTION_CODE = 2062;
 /** The upstream's own code for "the request carried no usable API key". */
@@ -1289,6 +1401,8 @@ var MinimaxCredits = class {
 	#rateLimitError;
 	#rateLimitAbsence;
 	#rateLimitAtMs;
+	#usageProfile;
+	#usageProfileError;
 	#apiKey;
 	/** The balance as last read. */
 	get snapshot() {
@@ -1330,14 +1444,22 @@ var MinimaxCredits = class {
 	get rateLimitAtMs() {
 		return this.#rateLimitAtMs;
 	}
+	/** The account's usage profile as last read. */
+	get usageProfile() {
+		return this.#usageProfile;
+	}
+	/** Why the usage profile could not be read, when it could not. */
+	get usageProfileError() {
+		return this.#usageProfileError;
+	}
 	/**
 	* Read the balance and record how much was consumed since the last read.
 	*
 	* The credit ledger is read alongside it, but a ledger that cannot be read
 	* never hides the balance: the two come from different endpoints and only
-	* the balance is essential. The rate-limit windows ride along under the
-	* same rule — they come from yet another endpoint, and none of the three
-	* takes the others down with it.
+	* the balance is essential. The rate-limit windows and the usage profile
+	* ride along under the same rule — they come from yet other endpoints, and
+	* none of the four takes the others down with it.
 	*
 	* @returns Whether the balance changed.
 	*/
@@ -1361,6 +1483,7 @@ var MinimaxCredits = class {
 		}
 		await this.refreshLedger(credential, region, fetchImpl, now);
 		await this.refreshRateLimit(credential, region, fetchImpl, now);
+		await this.refreshUsageProfile(credential, region, fetchImpl);
 		return changed;
 	}
 	/**
@@ -1399,6 +1522,21 @@ var MinimaxCredits = class {
 		}
 	}
 	/**
+	* Read the account's usage profile.
+	*
+	* Same rule as the ledger: a failure is remembered but never thrown, and a
+	* profile that cannot be read leaves the last one on display.
+	*/
+	async refreshUsageProfile(credential, region, fetchImpl = fetch) {
+		try {
+			const profile = await fetchUsageProfile(credential, region, fetchImpl);
+			this.#usageProfile = profile;
+			this.#usageProfileError = void 0;
+		} catch (error) {
+			this.#usageProfileError = error instanceof Error ? error.message : String(error);
+		}
+	}
+	/**
 	* Read the windows from whichever endpoint can answer.
 	*
 	* The documented endpoint needs the open platform's plan key, which the
@@ -2472,6 +2610,31 @@ function apply(ctx) {
 			...credits.ledgerError === void 0 ? {} : { ledgerError: credits.ledgerError }
 		};
 	};
+	/**
+	* The account's usage profile as the card reads it.
+	*
+	* The upstream's own summary of the account's history: how many days it has
+	* been used in a row, how much it has consumed, and where it ranks. It is
+	* about the account rather than about this host, which is what the pill's
+	* own token count reports.
+	*/
+	const buildUsageProfileStatus = () => {
+		const profile = credits.usageProfile;
+		if (profile === void 0) return credits.usageProfileError === void 0 ? void 0 : {
+			state: "unavailable",
+			error: credits.usageProfileError
+		};
+		return {
+			state: "ok",
+			totalDays: profile.totalDays,
+			activeDays: profile.activeDays,
+			consecutiveDays: profile.currentConsecutiveDays,
+			totalTokenConsumed: profile.totalTokenConsumed,
+			rankingPercent: profile.usageRankingPercent,
+			mostActiveDay: profile.mostActiveDay,
+			updatedAt: profile.lastUpdateTime
+		};
+	};
 	/** The plan's rolling usage windows as the card reads them. */
 	const buildRateLimitStatus = () => {
 		if (creditState === "signed-out" || creditState === "expired") return { state: creditState };
@@ -2619,7 +2782,8 @@ function apply(ctx) {
 			rateLimit: buildRateLimitStatus(),
 			usage: buildUsageStatus(),
 			signin: buildSigninStatus(),
-			login: buildLoginStatus()
+			login: buildLoginStatus(),
+			usageProfile: buildUsageProfileStatus()
 		});
 	};
 	(async () => {

package/package.json

@@ -2,7 +2,7 @@
   "name": "dsh-connect-minimaxcode",
   "displayName": "DSH Connect MiniMax Code",
   "description": "把本机已登录的 MiniMax Code 桌面 App 模型接入 DeepSeek Harness：零配置、Anthropic Messages 兼容、动态模型目录，并显示积分余额与到期 — bring MiniMax Code desktop app models into DSH with a dynamic model catalog and a credit balance with expiry details.",
-  "version": "0.5.7",
+  "version": "0.5.8",
   "author": "JeffTsuiCUG",
   "contributors": [
     {