dsh-connect-minimaxcode 0.5.7 → 0.5.9

package/README.en.md

@@ -10,19 +10,17 @@ Bring the models of the **MiniMax Code desktop app (China region)**, already sig
 
 ## Inspiration
 
-The idea for this plugin came from **[corrinehu/dsh-workbuddy-connect](https://github.com/corrinehu/dsh-workbuddy-connect)** (by Corrine Hu).
+The community established the route this plugin follows: **a model already signed in on a desktop app can be moved into DSH with zero configuration** — no handling of accounts or passwords, no new authentication scheme; it just attaches a provider to the login state the machine already has and reuses DSH's built-in provider adapter. This plugin applies the same approach to MiniMax Code:
 
-That project was the first to show that **a model already signed in on a desktop app can be moved into DSH with zero configuration** — no handling of accounts or passwords, no new authentication scheme; it just attaches a provider to the login state the machine already has and reuses DSH's built-in provider adapter. This plugin applies the same approach to MiniMax Code:
-
-| | dsh-workbuddy-connect | This plugin |
+| | Sibling plugins | This plugin |
 |---|---|---|
-| Data source | Local login state of the WorkBuddy desktop app | Local login state of the MiniMax Code desktop app |
+| Data source | Local login state of their own desktop app | Local login state of the MiniMax Code desktop app |
 | Integration | Registers a DSH provider and exposes the already-signed-in models | Same |
 | Catalog source | Live model list from upstream | Same |
 
-Another implementation in the same direction is **[dingminhua/dsh-connect-workbuddy](https://github.com/dingminhua/dsh-connect-workbuddy)**; for **how the plugin is structured and how the provider is registered**, this plugin also follows the same author's [dsh-connect-trae](https://github.com/dingminhua/dsh-connect-trae) (whose connection core itself references corrinehu's implementation — see the acknowledgements in its README).
+Several implementations exist in the same direction; for **how the plugin is structured and how the provider is registered**, this plugin follows **[dingminhua/dsh-connect-workbuddy](https://github.com/dingminhua/dsh-connect-workbuddy)** and the same author's [dsh-connect-trae](https://github.com/dingminhua/dsh-connect-trae).
 
-> The two differ in this way: **corrinehu was the original pioneer** — the "reuse the local login state" route was established by that project; **dingminhua's implementation follows the existing conventions of the DSH plugin structure more closely**, and this plugin's directory layout and `cordis.patch.yml` follow the latter. Both are credited at the end of this document.
+> These projects are developed independently and are not affiliated with this one. This plugin's directory layout and `cordis.patch.yml` follow the existing conventions of the DSH plugin structure.
 
 ---
 
@@ -283,6 +281,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 +327,20 @@ The OAuth token is valid for about an hour and is refreshed automatically by the
 
 ## Changelog
 
+### 0.5.9 (2026-11-10)
+
+- **README**: every reference to a repository that no longer exists (it now answers 404) is gone — the inspiration section, the sibling-plugin table and its section, and the acknowledgements. The practice it established and the sibling projects that followed it are still described, and every repository link left in the README was checked to be alive.
+- **README**: the marketplace section now states the situation as it stands — all twelve listing pull requests are closed, the forks opened for them are cleaned up, those directories are not being worked on, and distribution runs through npm and this repository's releases. The two registries that still carry an entry (the official registry and dshbase) are still listed. The npm package ships the README, so this change needs a release to reach the package page.
+
+### 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.
@@ -395,30 +428,25 @@ For earlier versions, see [GitHub Releases](https://github.com/JeffTsuiCUG/dsh-c
 
 ## Marketplace listing and presentation
 
-The plugin ships an installable `dsh.bundle` manifest and is published to npm. The directory of the community plugin marketplace (`dshmarket`) is generated from the [Awesome DSH Plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin) registry, and this plugin's listing has been submitted as PR [#8110](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/8110). A draft and the operating notes are kept in the repository: [`awesome-dsh-plugin-submission/`](awesome-dsh-plugin-submission/).
+The plugin ships an installable `dsh.bundle` manifest and is published to npm — **npm is the installation path**:
+
+```bash
+dsh plugin --profile desktop add dsh-connect-minimaxcode
+```
+
+The directory of the community plugin marketplace (`dshmarket`) is generated from the [Awesome DSH Plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin) registry, and this plugin's entry is in it ([#8110](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/8110) listed, [#8380](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/8380) refreshed), so it also shows up in the DSH plugin centre.
 
-**Other directories and marketplaces** (entries submitted or already listed, text refreshed to 0.5.1):
+**Other directories**: entries were submitted to several awesome lists as well, but those projects see little maintenance; the entries and the forks opened for them have been cleaned up and are **no longer maintained**. Distribution runs through npm and this repository's Releases. The original draft and the submission notes are kept in the repository: [`awesome-dsh-plugin-submission/`](awesome-dsh-plugin-submission/), in case they are ever needed again.
 
 | Channel | State |
 |---|---|
-| [awesome-dsh-plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin) (the registry) | Listed; entry refresh PR [#8380](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/8380) |
-| [awesome-deepseek-harness](https://github.com/0xsline/awesome-deepseek-harness) | PR [#727](https://github.com/0xsline/awesome-deepseek-harness/pull/727) |
-| [Awesome-DeepSeek-Harness-Plugins](https://github.com/Zhiyuan-Fan/Awesome-DeepSeek-Harness-Plugins) | PR [#92](https://github.com/Zhiyuan-Fan/Awesome-DeepSeek-Harness-Plugins/pull/92) |
-| [dsh-suite](https://github.com/whyihaveyou/dsh-suite) | PR [#66](https://github.com/whyihaveyou/dsh-suite/pull/66) |
-| [awesome-dsh-plugins](https://github.com/kejixiaoliang/awesome-dsh-plugins) | PR [#143](https://github.com/kejixiaoliang/awesome-dsh-plugins/pull/143) |
-| [awesome-dsh-plugins](https://github.com/dshworks/awesome-dsh-plugins) | PR [#176](https://github.com/dshworks/awesome-dsh-plugins/pull/176) |
-| [awesome-deepseek-harness](https://github.com/awesome-deepseekharness/awesome-deepseek-harness) | PR [#177](https://github.com/awesome-deepseekharness/awesome-deepseek-harness/pull/177) |
-| [dsh-plugin-radar](https://github.com/AdamPlatin123/dsh-plugin-radar) | PR [#964](https://github.com/AdamPlatin123/dsh-plugin-radar/pull/964) |
-| [dsh-community-plugins](https://github.com/zhu1090093659/dsh-community-plugins) | PR [#46](https://github.com/zhu1090093659/dsh-community-plugins/pull/46) |
-| [dsh-plugin.org](https://github.com/dshplugin/dsh-plugin-hub) | Listed (automatic scan; the npm package shows up in the DSH plugin centre) |
-| [dshbase](https://github.com/ylwl1997/dshbase) | Listed |
-| [awesome-deepseek-harness-plugins](https://github.com/walkinglabs/awesome-deepseek-harness-plugins) | PR [#117](https://github.com/walkinglabs/awesome-deepseek-harness-plugins/pull/117) |
-| [awesome-deepseek-harness](https://github.com/Dominic789654/awesome-deepseek-harness) | PR [#663](https://github.com/Dominic789654/awesome-deepseek-harness/pull/663) |
-| [awesome-deepseek-harness-plugins](https://github.com/imsai-sh/awesome-deepseek-harness-plugins) | PR [#660](https://github.com/imsai-sh/awesome-deepseek-harness-plugins/pull/660) |
+| [awesome-dsh-plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin) (the registry behind `dshmarket`) | Listed |
+| [dshbase](https://github.com/ylwl1997/dshbase) | Listed (automatic scan) |
+| Other awesome lists | No longer maintained; entries and forks cleaned up |
 
 Marketplace screenshots are declared, per the current convention, by the **`screenshots.json` in the plugin's own repository root** (the registry's `data/screenshots.json` is a fallback from the old convention, and no new keys are added there). This repository **does not ship screenshots yet**, so the file does not exist; once there are some, put `screenshots.json` in the repository root (an array of relative image paths) and the marketplace card will pick them up.
 
-> **Since 0.5.1 the readout lives in the composer tool row (beside the model picker) and is gated by the host's `modelSelection` projection**: the balance belongs to the provider the next request will actually use, so it sits where that selection is made — and it hides entirely, polling included, when another connector's model (workbuddy, for example) is selected. This follows `dsh-connect-trae`, whose `ComposerPointsGate` returns null for every provider but its own.
+> **Since 0.5.1 the readout lives in the composer tool row (beside the model picker) and is gated by the host's `modelSelection` projection**: the balance belongs to the provider the next request will actually use, so it sits where that selection is made — and it hides entirely, polling included, when another connector's model (dsh-connect-workbuddy, for example) is selected. This follows `dsh-connect-trae`, whose `ComposerPointsGate` returns null for every provider but its own.
 >
 > The tool row is a shared slot and can in principle be crowded out (a sibling plugin lost a reading this way in `workbuddy` issue #62; trae's answer is a second seat). **This plugin registers the tool-row seat only**; the ambient dock is a proven fallback should crowding ever occur.
 
@@ -455,7 +483,6 @@ These plugins follow the same idea — **reuse the login state your local deskto
 |---|---|---|---|
 | **dsh-connect-trae** | Trae (China + international) | ✅ China region | ✅ Work / general credit overview |
 | **dsh-qoder-connect** | Qoder (China + international, PAT) | ✅ 100 Credits per day | ✅ Sidebar quota card + breakdown |
-| **dsh-workbuddy-connect** | WorkBuddy (China + international) | — | ✅ Remaining credits + breakdown |
 
 > Each plugin's check-in rules, quota basis and limitations are defined by its own documentation. The readings above come from the same machine and only represent the state at that time; they are not a promise.
 
@@ -475,16 +502,6 @@ Connects Qoder through a personal access token (PAT), with independent configura
 dsh plugin --profile desktop add dsh-qoder-connect
 ```
 
-### [dsh-workbuddy-connect](https://github.com/corrinehu/dsh-workbuddy-connect)
-
-Connects the WorkBuddy desktop app; the China and international versions can coexist, each using its own account and its own credits. It shows the account information, token validity and remaining credits, and ships a CLI:
-
-```bash
-dsh plugin --profile web exec dsh-workbuddy-connect status
-```
-
-> This plugin's version must match your DSH core exactly (each core line uses a different version); see the version table in its README before installing.
-
 ## Contributors
 
 - **[eghrhegpe](https://github.com/eghrhegpe)** — raised the request for a plugin-page icon and Chinese/English copy ([#1](https://github.com/JeffTsuiCUG/dsh-connect-minimaxcode/issues/1)). It became 0.5.2: the plugin page has its own SVG artwork, the title and the introduction come in both languages, and the interface follows the host's language.
@@ -494,8 +511,7 @@ dsh plugin --profile web exec dsh-workbuddy-connect status
 
 ## Acknowledgements
 
-- **[corrinehu/dsh-workbuddy-connect](https://github.com/corrinehu/dsh-workbuddy-connect)** — **the inspiration for this plugin**. The overall idea of "reuse the desktop app's local login state and bring the already-signed-in model into DSH" was established first by that project, and this plugin follows the same approach; the read-only reuse of credentials was designed with it in mind.
-- **[dingminhua/dsh-connect-workbuddy](https://github.com/dingminhua/dsh-connect-workbuddy)** — another implementation in the same direction; this plugin's **plugin structure and provider registration** follow it (its connection core also references corrinehu's implementation — see that project's acknowledgements).
+- **[dingminhua/dsh-connect-workbuddy](https://github.com/dingminhua/dsh-connect-workbuddy)** — another implementation in the same direction; this plugin's **plugin structure and provider registration** follow it.
 - [dingminhua/dsh-connect-trae](https://github.com/dingminhua/dsh-connect-trae) — the same author's DSH plugin, useful as a reference for the DSH plugin structure.
 
 > The projects listed under "Similar plugins" are the work of independent developers. They are not affiliated with or endorsed by this project, and each one follows its own license and disclaimer.

package/README.md

@@ -10,19 +10,17 @@
 
 ## 灵感来源
 
-本插件的思路来自 **[corrinehu/dsh-workbuddy-connect](https://github.com/corrinehu/dsh-workbuddy-connect)**（作者 Corrine Hu）。
+社区先走通了这样一条路：**桌面 App 已经登录的模型，可以零配置地搬进 DSH** —— 不去碰账号密码，不引入新的鉴权体系，只是把本机已有的登录态接上一个 provider，并复用 DSH 自带的 provider 适配器。本插件把同一套做法用在了 MiniMax Code 上：
 
-它最早证明了这样一件事：**桌面 App 已经登录的模型，可以零配置地搬进 DSH**——不去碰账号密码，不引入新的鉴权体系，只是把本机已有的登录态接上一个 provider，并复用 DSH 自带的 provider 适配器。本插件把同一套做法用在了 MiniMax Code 上：
-
-| | dsh-workbuddy-connect | 本插件 |
+| | 同类插件 | 本插件 |
 |---|---|---|
-| 数据来源 | WorkBuddy 桌面 App 的本地登录态 | MiniMax Code 桌面 App 的本地登录态 |
+| 数据来源 | 各自桌面 App 的本地登录态 | MiniMax Code 桌面 App 的本地登录态 |
 | 接入方式 | 注册 DSH provider，暴露已登录模型 | 同左 |
 | 目录来源 | 上游实时模型列表 | 同左 |
 
-同方向的另一实现是 **[dingminhua/dsh-connect-workbuddy](https://github.com/dingminhua/dsh-connect-workbuddy)**，本插件在**插件结构与 provider 注册的组织方式**上参考了同一作者的 [dsh-connect-trae](https://github.com/dingminhua/dsh-connect-trae)（该项目的连接内核本身也参照了 corrinehu 的实现，见其 README 致谢）。
+同方向已有多个实现，本插件在**插件结构与 provider 注册的组织方式**上参考了 **[dingminhua/dsh-connect-workbuddy](https://github.com/dingminhua/dsh-connect-workbuddy)** 与同一作者的 [dsh-connect-trae](https://github.com/dingminhua/dsh-connect-trae)。
 
-> 两者的价值可以这样区分：**corrinehu 是最早的开创者**，「复用本机登录态」的路线由它确立；**dingminhua 的实现更贴近 DSH 插件结构的既有约定**，本插件的目录布局与 `cordis.patch.yml` 写法沿用了后者。二者都已列入文末致谢。
+> 同类项目各自独立开发，与本项目无隶属关系。本插件的目录布局与 `cordis.patch.yml` 写法沿用了 DSH 插件结构的既有约定。
 
 ---
 
@@ -319,6 +317,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 +363,20 @@ OAuth 令牌有效期约 1 小时，由客户端自动续期。插件**只在自
 
 ## 更新记录
 
+### 0.5.9（2026-11-10）
+
+- **README**：移除指向已不存在仓库的引用（该仓库现已 404），灵感来源、同类插件与致谢三处一并清理，保留的做法与仍有效的同类项目说明不变；README 中保留的每一个仓库链接都已逐一确认存活。
+- **README**：市场收录章节改为如实描述现状 —— 十二个收录 PR 均已关闭、为收录开的分叉已清理、那些目录不再维护，分发以 npm 与本仓库 Releases 为准；仍收录本插件的两个注册表（官方注册表与 dshbase）照旧列出。npm 包内含 README，因此本次改动需要发版才能在包页生效。
+
+### 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` 的响应并缓存复用。
@@ -387,7 +420,7 @@ OAuth 令牌有效期约 1 小时，由客户端自动续期。插件**只在自
 
 ### 0.5.1（2026-10-20）
 
-- **余额读数跟随所选模型**：从输入框下方的 dock 移到**输入框工具行（模型选择器旁）**，并按宿主 `modelSelection` 投影门控 —— **只有选中 `minimaxcode` 模型时才显示**；切到其他反代插件（如 workbuddy）的模型即整体隐藏，且不轮询（学习 `dsh-connect-trae` 的做法）。
+- **余额读数跟随所选模型**：从输入框下方的 dock 移到**输入框工具行（模型选择器旁）**，并按宿主 `modelSelection` 投影门控 —— **只有选中 `minimaxcode` 模型时才显示**；切到其他反代插件（如 dsh-connect-workbuddy）的模型即整体隐藏，且不轮询（学习 `dsh-connect-trae` 的做法）。
 - **`engines.dsh` 收窄为 `>=0.2.1-rc.2 <0.3.0-0`**：只声明实测过的档位，此前的 `>=0.1.7-rc.1` 覆盖过宽。
 
 ### 0.5.0（2026-10-20）
@@ -433,26 +466,21 @@ OAuth 令牌有效期约 1 小时，由客户端自动续期。插件**只在自
 
 ## 市场收录与展示
 
-插件已包含可安装的 `dsh.bundle` manifest，并发布到 npm。社区插件市场（`dshmarket`）的目录由 [Awesome DSH Plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin) 注册表生成，本插件的收录条目已提交为 PR [#8110](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/8110)，仓库内保留了一份草稿与操作说明：[`awesome-dsh-plugin-submission/`](awesome-dsh-plugin-submission/)。
+插件已包含可安装的 `dsh.bundle` manifest，并发布到 npm —— **安装方式以 npm 为准**：
+
+```bash
+dsh plugin --profile desktop add dsh-connect-minimaxcode
+```
+
+社区插件市场（`dshmarket`）的目录由 [Awesome DSH Plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin) 注册表生成，本插件的条目已在该注册表中（[#8110](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/8110) 收录、[#8380](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/8380) 更新），因此也会出现在 DSH 的插件中心里。
 
-**其它目录 / 市场的收录**（条目已提交或已上线，内容随版本更新到 0.5.1）：
+**其它目录**：此前也向若干 awesome 清单提交过收录条目，但那些项目的更新活跃度很低，条目与为此开的分叉都已清理完毕，**不再维护**。插件的分发以 npm 与本仓库的 Releases 为准。仓库内保留了一份当初的草稿与提交说明：[`awesome-dsh-plugin-submission/`](awesome-dsh-plugin-submission/)，供日后需要时参考。
 
 | 渠道 | 状态 |
 |---|---|
-| [awesome-dsh-plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin)（官方注册表） | ✅ 已收录；条目更新 PR [#8380](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/8380) |
-| [awesome-deepseek-harness](https://github.com/0xsline/awesome-deepseek-harness) | PR [#727](https://github.com/0xsline/awesome-deepseek-harness/pull/727) |
-| [Awesome-DeepSeek-Harness-Plugins](https://github.com/Zhiyuan-Fan/Awesome-DeepSeek-Harness-Plugins) | PR [#92](https://github.com/Zhiyuan-Fan/Awesome-DeepSeek-Harness-Plugins/pull/92) |
-| [dsh-suite](https://github.com/whyihaveyou/dsh-suite) | PR [#66](https://github.com/whyihaveyou/dsh-suite/pull/66) |
-| [awesome-dsh-plugins](https://github.com/kejixiaoliang/awesome-dsh-plugins) | PR [#143](https://github.com/kejixiaoliang/awesome-dsh-plugins/pull/143) |
-| [awesome-dsh-plugins](https://github.com/dshworks/awesome-dsh-plugins) | PR [#176](https://github.com/dshworks/awesome-dsh-plugins/pull/176) |
-| [awesome-deepseek-harness](https://github.com/awesome-deepseekharness/awesome-deepseek-harness) | PR [#177](https://github.com/awesome-deepseekharness/awesome-deepseek-harness/pull/177) |
-| [dsh-plugin-radar](https://github.com/AdamPlatin123/dsh-plugin-radar) | PR [#964](https://github.com/AdamPlatin123/dsh-plugin-radar/pull/964) |
-| [dsh-community-plugins](https://github.com/zhu1090093659/dsh-community-plugins) | PR [#46](https://github.com/zhu1090093659/dsh-community-plugins/pull/46) |
-| [dsh-plugin.org](https://github.com/dshplugin/dsh-plugin-hub) | ✅ 已收录（自助扫描，会随目录更新出现在 DSH「插件中心」） |
-| [dshbase](https://github.com/ylwl1997/dshbase) | ✅ 已收录 |
-| [awesome-deepseek-harness-plugins](https://github.com/walkinglabs/awesome-deepseek-harness-plugins) | PR [#117](https://github.com/walkinglabs/awesome-deepseek-harness-plugins/pull/117) |
-| [awesome-deepseek-harness](https://github.com/Dominic789654/awesome-deepseek-harness) | PR [#663](https://github.com/Dominic789654/awesome-deepseek-harness/pull/663) |
-| [awesome-deepseek-harness-plugins](https://github.com/imsai-sh/awesome-deepseek-harness-plugins) | PR [#660](https://github.com/imsai-sh/awesome-deepseek-harness-plugins/pull/660) |
+| [awesome-dsh-plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin)（官方注册表，`dshmarket` 目录来源） | ✅ 已收录 |
+| [dshbase](https://github.com/ylwl1997/dshbase) | ✅ 已收录（自动扫描） |
+| 其它 awesome 清单 | 已停止维护，条目与分叉已清理 |
 
 市场截图按当前约定由**插件自己仓库根目录的** `screenshots.json` 声明（注册表 `data/screenshots.json` 是旧约定下的回退，不再新增键）。本仓库目前**尚未提供截图**，所以还没有这个文件；补上截图后，在根目录放 `screenshots.json`（内容是图片相对路径的数组）即可被市场卡片取用。
 
@@ -493,7 +521,6 @@ pnpm build && git add lib
 |---|---|---|---|
 | **dsh-connect-trae** | Trae（国内版 + 国际版） | ✅ 国内版 | ✅ Work / 通用积分概览 |
 | **dsh-qoder-connect** | Qoder（国内版 + 国际版，PAT） | ✅ 每日 100 Credits | ✅ 侧栏额度小卡 + 明细 |
-| **dsh-workbuddy-connect** | WorkBuddy（国内版 + 国际版） | — | ✅ 剩余积分 + 明细 |
 
 > 各插件的签到规则、额度口径与限制以各自文档为准。下表为同一台机器上的实测读数，仅代表当时状态，非承诺。
 
@@ -513,16 +540,6 @@ dsh plugin --profile desktop add dsh-connect-trae
 dsh plugin --profile desktop add dsh-qoder-connect
 ```
 
-### [dsh-workbuddy-connect](https://github.com/corrinehu/dsh-workbuddy-connect)
-
-接入 WorkBuddy 桌面 App，国内版与国际版可并存，各自使用自己的账号与积分。提供账号信息、令牌有效期与剩余积分查看，并带 CLI：
-
-```bash
-dsh plugin --profile web exec dsh-workbuddy-connect status
-```
-
-> 该插件的版本需与你的 DSH 内核严格对应（不同内核线用不同版本），安装前请见其 README 的版本对应表。
-
 ## 贡献者
 
 - **[eghrhegpe](https://github.com/eghrhegpe)** —— 提出了插件页图标与中英文文案的建议（[#1](https://github.com/JeffTsuiCUG/dsh-connect-minimaxcode/issues/1)）。这条建议促成了 0.5.2：插件页有了自己的 SVG 图标，标题与简介有了中英两版，界面文案也开始跟随宿主语言。
@@ -532,8 +549,7 @@ dsh plugin --profile web exec dsh-workbuddy-connect status
 
 ## 致谢
 
-- **[corrinehu/dsh-workbuddy-connect](https://github.com/corrinehu/dsh-workbuddy-connect)** — **本插件的灵感来源**。「复用桌面 App 本机登录态、把已登录模型接进 DSH」的整体思路由该项目最早确立，本插件沿用同一做法；凭据只读复用的设计也参照于此。
-- **[dingminhua/dsh-connect-workbuddy](https://github.com/dingminhua/dsh-connect-workbuddy)** — 同方向的另一实现，本插件的**插件结构与 provider 注册组织方式**参考了它（其连接内核亦参照 corrinehu 的实现，见该项目致谢）。
+- **[dingminhua/dsh-connect-workbuddy](https://github.com/dingminhua/dsh-connect-workbuddy)** — 同方向的另一实现，本插件的**插件结构与 provider 注册组织方式**参考了它。
 - [dingminhua/dsh-connect-trae](https://github.com/dingminhua/dsh-connect-trae) — 同作者的 DSH 插件，可作为 DSH 插件结构的参照。
 
 > 上方「同类插件」中的项目均为独立开发者的作品，与本项目无隶属或背书关系，各自遵循其自身的许可与免责声明。

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.9",
   "author": "JeffTsuiCUG",
   "contributors": [
     {