dsh-connect-minimaxcode 0.4.1 → 0.5.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.en.md +421 -0
- package/README.md +426 -342
- package/lib/client.js +165 -8
- package/lib/index.d.ts +304 -1
- package/lib/index.js +968 -26
- package/package.json +94 -91
package/README.md
CHANGED
|
@@ -1,343 +1,427 @@
|
|
|
1
|
-
# DSH Connect MiniMax Code (`dsh-connect-minimaxcode`)
|
|
2
|
-
|
|
3
|
-
把本机已登录的 **MiniMax Code 桌面 App（国内版）** 的模型接入 **DeepSeek Harness（DSH）**，装好即用，无需配置 API Key。
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
2
|
+
|
|
3
|
+
把本机已登录的 **MiniMax Code 桌面 App（国内版）** 的模型接入 **DeepSeek Harness（DSH）**，装好即用，无需配置 API Key。
|
|
4
|
+
|
|
5
|
+
|
|
6
|
+
[](https://www.npmjs.com/package/dsh-connect-minimaxcode)
|
|
7
|
+
[](https://github.com/JeffTsuiCUG/dsh-connect-minimaxcode/actions/workflows/ci.yml)
|
|
8
|
+
|
|
9
|
+
[English](README.en.md) | 简体中文
|
|
10
|
+
|
|
11
|
+
## 灵感来源
|
|
12
|
+
|
|
13
|
+
本插件的思路来自 **[corrinehu/dsh-workbuddy-connect](https://github.com/corrinehu/dsh-workbuddy-connect)**（作者 Corrine Hu）。
|
|
14
|
+
|
|
15
|
+
它最早证明了这样一件事：**桌面 App 已经登录的模型，可以零配置地搬进 DSH**——不去碰账号密码，不引入新的鉴权体系，只是把本机已有的登录态接上一个 provider，并复用 DSH 自带的 provider 适配器。本插件把同一套做法用在了 MiniMax Code 上：
|
|
16
|
+
|
|
17
|
+
| | dsh-workbuddy-connect | 本插件 |
|
|
18
|
+
|---|---|---|
|
|
19
|
+
| 数据来源 | WorkBuddy 桌面 App 的本地登录态 | MiniMax Code 桌面 App 的本地登录态 |
|
|
20
|
+
| 接入方式 | 注册 DSH provider，暴露已登录模型 | 同左 |
|
|
21
|
+
| 目录来源 | 上游实时模型列表 | 同左 |
|
|
22
|
+
|
|
23
|
+
同方向的另一实现是 **[dingminhua/dsh-connect-workbuddy](https://github.com/dingminhua/dsh-connect-workbuddy)**，本插件在**插件结构与 provider 注册的组织方式**上参考了同一作者的 [dsh-connect-trae](https://github.com/dingminhua/dsh-connect-trae)（该项目的连接内核本身也参照了 corrinehu 的实现，见其 README 致谢）。
|
|
24
|
+
|
|
25
|
+
> 两者的价值可以这样区分：**corrinehu 是最早的开创者**，「复用本机登录态」的路线由它确立；**dingminhua 的实现更贴近 DSH 插件结构的既有约定**，本插件的目录布局与 `cordis.patch.yml` 写法沿用了后者。二者都已列入文末致谢。
|
|
26
|
+
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
## ⚠️ 重要声明（请先阅读）
|
|
30
|
+
|
|
31
|
+
- **本项目仅供学习与研究使用**，不面向生产环境，也不提供任何商业支持。
|
|
32
|
+
- **本项目为非官方插件**，与 MiniMax、DeepSeek 均无关联，未获其认可或授权。
|
|
33
|
+
- 本插件仅**读取你自己本机上 MiniMax Code 已登录的凭证**，仅驱动**你自己的账号在你自己的电脑上**调用。
|
|
34
|
+
- **禁止**将本插件用于商业用途、超出个人合理使用范围的场景，或任何批量/多账号/规避限额的目的。
|
|
35
|
+
- 本插件依赖 MiniMax 客户端的**非公开接口**。MiniMax 更新客户端后，接口可能变更导致插件失效。
|
|
36
|
+
- 使用者需自行遵守 [MiniMax 的服务条款](https://agent.minimax.cn/doc/zh/terms-of-service.html)。因使用本插件产生的一切后果（账号受限、额度清空、服务中断等）由使用者自行承担。
|
|
37
|
+
- 本项目作者不对任何因使用或不当使用本插件造成的直接或间接损失负责。
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## 特点
|
|
42
|
+
|
|
43
|
+
- **零配置**：自动读取 MiniMax Code 桌面 App 的登录态，不在 DSH 中存储任何明文 Token
|
|
44
|
+
- **动态模型目录**：从上游接口实时拉取，模型增减无需更新插件
|
|
45
|
+
- **积分余额可见**：在对话框底部的胶囊里显示 MiniMax Code 的剩余积分，以及本机累计消耗
|
|
46
|
+
- **实时消耗统计**：每次请求的 token 用量取自上游响应本身，可按官方价目表折算等效金额
|
|
47
|
+
- **复用官方适配器**：上游为标准 Anthropic Messages 协议，直接复用 DSH 自带 provider，工具调用、推理块、上下文压缩均由 DSH 托管
|
|
48
|
+
- **不用装桌面 App 也能用**：插件可以自己走 OAuth 设备码流登录，你在自己的浏览器里确认即可，插件从不接触密码
|
|
49
|
+
- **每日签到**：MiniMax Code 每天送积分，客户端**不会自动领**；插件可以显示七天一签的进度，并代领当天的额度
|
|
50
|
+
- **只读为主**：除「续期已过期的桌面 App 登录态」和「你自己发起的登录」外，不写入、不修改 MiniMax 的任何文件
|
|
51
|
+
- **界面不打扰**：胶囊只在输入框下方的 dock 里占一行，不改动 DSH 的其它界面
|
|
52
|
+
|
|
53
|
+
## 前置条件
|
|
54
|
+
|
|
55
|
+
二选一：
|
|
56
|
+
|
|
57
|
+
1. **已安装并登录 MiniMax Code 桌面 App（国内版）** —— 插件直接复用它的登录态（最省事）
|
|
58
|
+
2. **什么都不装** —— 在插件页面点「登录 MiniMax Code」，插件发起 OAuth 设备码流，你在浏览器里用自己的 MiniMax 账号确认，插件拿到自己的登录态（需要能访问 `account.minimax.cn`）
|
|
59
|
+
|
|
60
|
+
另外需要 DSH 桌面版（内置内核 `0.2.0` 系列）或 Web profile。
|
|
61
|
+
|
|
62
|
+
## 安装
|
|
63
|
+
|
|
64
|
+
**方式一：从 Git 仓库安装**（推荐，拿到最新代码）
|
|
65
|
+
|
|
66
|
+
```bash
|
|
67
|
+
dsh plugin --profile desktop add github:JeffTsuiCUG/dsh-connect-minimaxcode
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
**方式二：npm 安装**（发布后可用）
|
|
71
|
+
|
|
72
|
+
```bash
|
|
73
|
+
dsh plugin --profile desktop add dsh-connect-minimaxcode
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
> **想立刻用上积分余额与到期提示**，请锁版本安装 —— pnpm 11 默认 `minimumReleaseAge` 为 1440 分钟，新版本发布后 24 小时内不带版本号的安装会解析到**较早的版本**（当前会落到 0.2.x，而积分功能是 0.3.0 才有的）：
|
|
77
|
+
>
|
|
78
|
+
> ```bash
|
|
79
|
+
> dsh plugin --profile desktop add dsh-connect-minimaxcode@0.4.2
|
|
80
|
+
> ```
|
|
81
|
+
|
|
82
|
+
Web profile 把 `--profile desktop` 换成 `--profile web`。
|
|
83
|
+
|
|
84
|
+
> 桌面版的 profile 由 Electron 应用独占，若 `dsh` 命令不在 PATH 中，请使用 DSH 应用自带的载体 CLI（路径随安装位置而变，例如 `<DSH安装目录>\resources\runtime\cli\bin\dsh.cmd`）。
|
|
85
|
+
|
|
86
|
+
安装后插件会热加载，模型随后出现在模型选择器的 **MiniMax Code** 分组中。
|
|
87
|
+
|
|
88
|
+
> 积分胶囊与插件页面卡片属于浏览器侧插件，**首次安装、或升级到 0.3.0 及之后的版本后，需要重启一次 DSH** 才会出现（模型通路本身不需要重启）。
|
|
89
|
+
|
|
90
|
+
### 若安装被 `allowBuilds` 拦截
|
|
91
|
+
|
|
92
|
+
本仓库把构建产物 `lib/` 一并提交，因此正常情况下安装不会触发构建。若你看到：
|
|
93
|
+
|
|
94
|
+
```text
|
|
95
|
+
[ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED] Failed to prepare git-hosted package
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
说明你使用的是**某个早于 `0.2.1` 的提交**（那些版本尚未提交 `lib/`）。解决办法二选一：
|
|
99
|
+
|
|
100
|
+
- 改用上面写法指定版本：`github:JeffTsuiCUG/dsh-connect-minimaxcode#v0.2.1`
|
|
101
|
+
- 或在该 profile 的 `pnpm-workspace.yaml` 中加入 pnpm 提示的 `allowBuilds` 条目后重试
|
|
102
|
+
|
|
103
|
+
## 使用流程
|
|
104
|
+
|
|
105
|
+
1. **确认桌面 App 已登录**
|
|
106
|
+
打开 MiniMax Code 桌面 App，确认处于已登录状态。插件读取的是 App 写入的本地登录态。
|
|
107
|
+
|
|
108
|
+
2. **安装插件**（见上一步的命令），等待热加载完成。
|
|
109
|
+
|
|
110
|
+
3. **选择模型**
|
|
111
|
+
打开 DSH 的模型选择器，在 **MiniMax Code** 分组下选择模型。可用模型来自上游实时目录，例如 `M3`、`M3.1-Flash`。
|
|
112
|
+
|
|
113
|
+
4. **正常对话**
|
|
114
|
+
直接使用即可。工具调用由 DSH 本地工具执行，插件只负责提供模型通路。
|
|
115
|
+
|
|
116
|
+
5. **令牌过期时重新登录**
|
|
117
|
+
MiniMax Code 有**两份互不通用**的登录态，本插件各用其一：
|
|
118
|
+
|
|
119
|
+
| 凭证 | 位置 | 有效期 | 用途 |
|
|
120
|
+
|---|---|---|---|
|
|
121
|
+
| JWT | `~/.minimax/local-runtime.auth.json` | 约 15 天 | 调模型网关（`/mavis/api/v1/llm/v1/messages`） |
|
|
122
|
+
| OAuth（`mmoat_`） | `~/.minimax/auth/prod/<region>/mcode-public/auth.json` | 约 1 小时 | 读账户与积分（`/matrix/api/v1/commerce/get_membership_info`） |
|
|
123
|
+
|
|
124
|
+
两份凭证互不通用：拿 JWT 打账户接口一律 `401`，拿 OAuth 令牌打模型网关同样不通。**模型对话**用 JWT，**积分显示**用 OAuth。
|
|
125
|
+
|
|
126
|
+
| 现象 | 含义 | 处理方式 |
|
|
127
|
+
|---|---|---|
|
|
128
|
+
| 正常使用 | 两份凭证都有效 | — |
|
|
129
|
+
| 模型报鉴权错误 | JWT 已失效 | 在 MiniMax Code 中**重新登录**，然后重启 DSH |
|
|
130
|
+
| 积分胶囊显示「登录态已过期」 | OAuth 令牌过期 | 插件会用 App 自己的 refresh token 续期并写回；若续期失败，请打开一次 MiniMax Code 桌面 App 让它自行续期 |
|
|
131
|
+
|
|
132
|
+
> OAuth 令牌过期**不会**影响模型对话：JWT 仍然有效，模型照常可用，只是积分胶囊暂时拿不到余额。
|
|
133
|
+
>
|
|
134
|
+
> 续期会**轮换** refresh token。插件因此把新的一对令牌按客户端**原格式原子写回**同一个文件，并保持 `generation` 不变——客户端靠它判断「这份凭据是否仍属于本次登录」，擅自抬高会让桌面 App 误判为异地登录。
|
|
135
|
+
|
|
136
|
+
### 关于响应速度
|
|
137
|
+
|
|
138
|
+
MiniMax 的这些模型**强制要求先推理再输出**，思考无法关闭。因此：
|
|
139
|
+
|
|
140
|
+
- 首个字符出现前会有一段等待（实测 M3.1-Flash 约 3 秒）
|
|
141
|
+
- 推理过程会以 `thinking` 块实时返回，可以在界面中看到模型"在想什么"
|
|
142
|
+
- 这是模型本身的行为，**不是插件造成的延迟**
|
|
143
|
+
|
|
144
|
+
若更看重流式体感的即时反馈，建议同时保留 DSH 官方模型或其他 provider 作为备选。
|
|
145
|
+
|
|
146
|
+
## 工作原理
|
|
147
|
+
|
|
148
|
+
1. 读取 `~/.minimax/local-runtime.auth.json`（MiniMax Code 写入的明文登录信息），**仅在内存中**解析其 JWT
|
|
149
|
+
2. 调用 `GET /mavis/api/v1/models` 获取实时模型目录（含上下文长度、多模态、工具调用等能力声明）
|
|
150
|
+
3. 注册 `minimaxcode` provider，指向 `POST /mavis/api/v1/llm/v1/messages`（标准 Anthropic Messages 协议）
|
|
151
|
+
4. 读取 `~/.minimax/auth/prod/<region>/mcode-public/auth.json` 的 OAuth 令牌，按需续期
|
|
152
|
+
5. 调用 `POST /matrix/api/v1/commerce/get_membership_info` 获取积分余额，通过插件自己的状态接口 `/plugins/dsh-connect-minimaxcode/status` 交给界面胶囊
|
|
153
|
+
|
|
154
|
+
### 与网关对接时的三个兼容处理
|
|
155
|
+
|
|
156
|
+
这些是实测中必须处理的差异，也是本插件与"直接改个 URL 就能用"的主要差异所在：
|
|
157
|
+
|
|
158
|
+
| # | 现象 | 处理 |
|
|
159
|
+
|---|---|---|
|
|
160
|
+
| 1 | 网关只认 `Authorization: Bearer`，而 pi-ai 默认发 `x-api-key`，后者单独出现会返回 `401 token is required` | 在模型描述符上附带 `Authorization` 头（网关同时接受两个头） |
|
|
161
|
+
| 2 | Anthropic SDK 会自己在 `baseUrl` 后追加 `/v1/messages`；若 `baseUrl` 已以 `/v1` 结尾，请求路径会变成 `/v1/v1/messages`，网关返回 `503 direct_route_not_configured` | `baseUrl` 收到版本段之前，由 SDK 补齐 |
|
|
162
|
+
| 3 | 所有模型强制要求推理，而"关闭推理"会让 pi-ai 发出 `thinking: {type: "disabled"}`，网关返回 `400 ... requires adaptive thinking` | 将"关闭"级别标记为不支持，使该字段被省略（网关接受） |
|
|
163
|
+
|
|
164
|
+
插件**不**包含任何硬编码的 Token、账号或接口密钥。
|
|
165
|
+
|
|
166
|
+
## 自己登录，不装桌面 App
|
|
167
|
+
|
|
168
|
+
插件可以自己完成登录，用的是 MiniMax Code 桌面端同一套 **OAuth 2.0 设备码流**（RFC 8628）：
|
|
169
|
+
|
|
170
|
+
1. 插件向 `account.minimax.cn/oauth2/device/code` 申请一个设备码，拿到一个 8 位用户码和授权页地址
|
|
171
|
+
2. 你在浏览器里打开那个地址，用**自己的 MiniMax 账号**登录并确认授权
|
|
172
|
+
3. 插件轮询 `oauth2/token`，拿到 `mmoat_` 令牌与 refresh token
|
|
173
|
+
|
|
174
|
+
要点：
|
|
175
|
+
|
|
176
|
+
- **插件不接触密码、也不接触验证码** —— 唯一的人工环节发生在你自己的浏览器里、账号官方的页面上
|
|
177
|
+
- **用了 PKCE**：设备码即使泄露，没有本进程里的 verifier 也换不成令牌
|
|
178
|
+
- **一枚令牌够用**：`mmoat_` 令牌既能调模型网关（`agent.minimax.cn/mavis/api/v1/llm`），也能调账户接口（积分、签到），所以登录一次就够
|
|
179
|
+
- **不写客户端的文件**：插件把凭据存在自己的 `~/.dsh/.minimaxcode-auth.json`（权限 0600，原子写）。桌面 App 的两个文件带 `generation` 计数器且必须同步递增，写进去会被它当成「在别处登录过」而要求重登
|
|
180
|
+
- **refresh token 会轮转**，插件把新的一对写回自己的文件，所以登录能长期有效
|
|
181
|
+
|
|
182
|
+
## 每日签到
|
|
183
|
+
|
|
184
|
+
MiniMax Code 的免费积分是**每天签到送的**，不是登录就送。客户端有个「每日签到」卡片，但**不会自动领** —— 卡片弹出来，得你自己点。
|
|
185
|
+
|
|
186
|
+
上游的接口是：
|
|
187
|
+
|
|
188
|
+
```
|
|
189
|
+
GET /minimax-cloud/api/v1/signin/status?timezone_id=Asia/Shanghai # 七天一轮的进度
|
|
190
|
+
POST /minimax-cloud/api/v1/signin/claim?timezone_id=Asia/Shanghai # 领取当天额度
|
|
191
|
+
```
|
|
192
|
+
|
|
193
|
+
几点实测结论：
|
|
194
|
+
|
|
195
|
+
- **时区必须是 IANA 名字**（`Asia/Shanghai`）。传偏移量或干脆不传，服务端会回 `invalid timezone_id`
|
|
196
|
+
- **一轮七天**：400 / 400 / 400 / 1000 / 400 / 400 / 1000 = **4000 积分**
|
|
197
|
+
- **签到的积分 30 天有效**（响应里的 `expire_at_ms` 正好是领取日 + 30 天的北京时间零点）
|
|
198
|
+
- **按天幂等**：当天重复领返回 `claim_result: 2`（今日已领），不会重复发放
|
|
199
|
+
|
|
200
|
+
插件页面里能看到当天是第几天、值多少积分、一轮还剩哪些天，并提供两个动作：
|
|
201
|
+
|
|
202
|
+
- **「签到」按钮** —— 你点一下，插件领当天的额度
|
|
203
|
+
- **「每天自动签到」开关**（默认关） —— 打开后，插件在检测到「服务端说今天可领」时自动领一次，每天至多一次
|
|
204
|
+
|
|
205
|
+
自动签到刻意做得很克制：只在上游明确说当天可领时才发请求、当天至多一次、不并发重试、不绕过任何验证，出错就把原因显示出来而不是静默重试。请自行确认这样做符合 MiniMax 的服务条款。
|
|
206
|
+
|
|
207
|
+
## 积分余额与用量
|
|
208
|
+
|
|
209
|
+
对话框输入框下方的胶囊会显示 MiniMax Code 的**剩余积分**；点开还能看到赠送/购买拆分、两次读取之间的消耗，以及本机累计的 token 与等效金额。
|
|
210
|
+
|
|
211
|
+
### 余额从哪里来
|
|
212
|
+
|
|
213
|
+
MiniMax Code 桌面 App 自己每天在调一个「会员信息」接口，响应里就带着客户端设置页显示的那三个数字：
|
|
214
|
+
|
|
215
|
+
```
|
|
216
|
+
POST https://agent.minimax.cn/matrix/api/v1/commerce/get_membership_info
|
|
217
|
+
Authorization: Bearer <桌面 App 的 mmoat_ OAuth 令牌>
|
|
218
|
+
Content-Type: application/json
|
|
219
|
+
|
|
220
|
+
{}
|
|
221
|
+
```
|
|
222
|
+
|
|
223
|
+
```json
|
|
224
|
+
"op_credit_summary": {
|
|
225
|
+
"total_remaining_amount": "11459.454", // 总剩余积分
|
|
226
|
+
"purchased_remaining_amount": "0", // 其中购买的
|
|
227
|
+
"free_remaining_amount": "11459.454" // 其中赠送的
|
|
228
|
+
}
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
插件读的就是 `op_credit_summary.total_remaining_amount`。**注意别取错字段**：同一个响应里的 `total_remains_credit` 与 `opcredit_balance` 是旧账，在已迁移到积分池的账号上恒为 `0`，取它们会显示「0 积分」。
|
|
232
|
+
|
|
233
|
+
顺带一提，这里有三个**单位不同**的「钱」，别混：
|
|
234
|
+
|
|
235
|
+
| 数值 | 含义 | 本插件是否显示 |
|
|
236
|
+
|---|---|---|
|
|
237
|
+
| `op_credit_summary.total_remaining_amount` | Code 积分余额 | ✅ 就是它 |
|
|
238
|
+
| `token_plan_credit.remaining_credits` | 已购积分池 | ❌ |
|
|
239
|
+
| `query_balance.available_amount` | 开放平台钱包（元） | ❌ |
|
|
240
|
+
|
|
241
|
+
### 积分会过期吗？会
|
|
242
|
+
|
|
243
|
+
积分不是一池子，而是**按笔发放的批次**，每批有自己的到期日。客户端每天发一批，每批在**发放日 + 30 个自然日**到期（按账户所在时区，当日 00:00 失效），于是形成一条逐日错开的 30 天阶梯：
|
|
244
|
+
|
|
245
|
+
```
|
|
246
|
+
GET https://agent.minimax.cn/minimax-cloud/api/v1/credit/details?page_number=1&page_size=100
|
|
247
|
+
→ details[] { granted_amount, remaining_amount, consumed_amount, granted_at_ms, expire_at_ms, credit_type }
|
|
248
|
+
```
|
|
249
|
+
|
|
250
|
+
实测本机 23 笔：09-20 发的在 10-20 到期、09-21 发的在 10-21 到期……另有一笔 08-25 发的在 2027-08-25 到期（一年期批次，`credit_type` 1=购买 / 2=签到）。**到期日一律读 `expire_at_ms`**，不写死天数——至少存在 30 天与 365 天两种制式。
|
|
251
|
+
|
|
252
|
+
插件据此在**插件页面**（设置 → 插件 → DSH Connect MiniMax Code）与输入框下方的胶囊里给出：
|
|
253
|
+
|
|
254
|
+
- **7 天内到期**的剩余积分，以及最近一笔的到期日
|
|
255
|
+
- **30 天内到期**的剩余积分
|
|
256
|
+
- 接下来几笔**到期批次**的清单（日期 + 金额）
|
|
257
|
+
- 余额条与本机消耗（token 数、等效金额）
|
|
258
|
+
|
|
259
|
+
只统计**仍有余额**的批次：已发放但用光的批次到期时并没有东西可损失，把它算进去会让每个账号都看起来"快过期了"。积分的消耗近似先进先出，所以**"7 天内到期"的金额常常是 0**（快到期的那些基本都已被用完），因此界面同时给出**最早到期时间**，那才是真正有意义的信号。
|
|
260
|
+
|
|
261
|
+
> 过期不会把批次里的 `remaining_amount` 清零（实测会留下 -0.31 这样的负值残留），而是把过期批次**排除在余额之外**；所以总额以余额接口为准。
|
|
262
|
+
>
|
|
263
|
+
> 台账的 `remaining_amount` 合计与余额接口的 `total_remaining_amount` 在**静止期逐位相等**；两次采样之间看到的差异，是账户在这段时间里被真实消耗掉的量。
|
|
264
|
+
|
|
265
|
+
### 消耗怎么算
|
|
266
|
+
|
|
267
|
+
两路数据各管一件事：
|
|
268
|
+
|
|
269
|
+
- **真实积分消耗**：余额是个活值，两次读取的差值就是这段时间真正花掉的积分（客户端也会并发消耗，所以差值含其它客户端的开销）。
|
|
270
|
+
- **本机消耗**：每次请求的响应都自带 `usage`（`input_tokens` / `output_tokens` / `cache_creation_input_tokens` / `cache_read_input_tokens`），插件原样累计。折算金额时**只用这四个分量自己算**，不能用任何 `total_token` 汇总值——上游的两级汇总口径不同（差 1.94 倍，差额正是缓存读取部分）。单价取自 [MiniMax 官方价目表](https://platform.minimax.cn/docs/pricing/overview)：
|
|
271
|
+
|
|
272
|
+
| 模型 | 输入 | 输出 | 缓存读取 |
|
|
273
|
+
|---|---|---|---|
|
|
274
|
+
| `MiniMax-M3.1-Flash` | 1.00 元/百万 tokens | 4.00 | 0.10 |
|
|
275
|
+
| `MiniMax-M3`（≤512k 输入） | 2.10 | 8.40 | 0.42 |
|
|
276
|
+
| `MiniMax-M3`（>512k 输入） | 4.20 | 16.80 | 0.84 |
|
|
277
|
+
|
|
278
|
+
折算出的金额是**等效金额**，不是扣费：积分与金额之间 MiniMax 没有公开换算关系（套餐只公布了 1×/3×/12× 的相对倍数），所以插件不会把它说成「花了多少积分」。
|
|
279
|
+
|
|
280
|
+
> 官方价目表没有单列**缓存写入**（`cache_creation_input_tokens`）的单价，因此插件只统计它的 token 数、**不折算金额**，以免给出一个没有公开依据的数字。
|
|
281
|
+
|
|
282
|
+
### 关于续期
|
|
283
|
+
|
|
284
|
+
OAuth 令牌有效期约 1 小时，由客户端自动续期。插件**只在自己的令牌已过期时**才用 App 已存的 refresh token 续一次，并把轮换后的新令牌按客户端**原格式原子写回**同一个文件（`generation` 保持不变），因此桌面 App 的登录态不受影响。插件不会发起登录、不会登出、也不会调用任何付费/订阅类接口。
|
|
285
|
+
|
|
286
|
+
> 这一节的结论与 0.2.x 的「无法显示额度」相反。当时的调查按 `credits` / `quota` / `summary` 这类英文语义猜路径，真实接口用的是 `commerce` / `membership` 这套计费域词汇，因此全部落空；后来是从桌面 App 自己的运行日志（`%APPDATA%\MiniMax\logs\api-*.log`）里读出它每天真实调用的 URL，才定位到这条路径。
|
|
287
|
+
|
|
288
|
+
## 已知限制
|
|
289
|
+
|
|
290
|
+
- **仅支持国内版（`agent.minimax.cn`）**。国际版网关是否可用**未经验证**，请勿据此推断其他区域可用。
|
|
291
|
+
- **必须开启推理**。MiniMax 的全部模型都声明需要推理，关不掉。首字延迟因此高于非推理模型。
|
|
292
|
+
- **未登录时模型列表是内置兜底**。此时选择器中仍会显示 `M3`、`M3.1-Flash` 两个内置条目，但它们无法真正调用；登录后才会切换为上游实时目录。判断是否可用，请以实际调用结果为准。
|
|
293
|
+
- **积分只覆盖 MiniMax Code 的赠送/购买积分**，不包含开放平台钱包余额与已购积分池，插件也不会把金额折算成积分。
|
|
294
|
+
- **余额是账户级数值**，两次读取的差值包含 MiniMax Code 其它客户端的并发消耗；本机单独的消耗看胶囊里的 token 数与等效金额。
|
|
295
|
+
- **等效金额是按公开价目表折算的估值**，不是实际扣费；官方未公开 token 与积分的换算关系。
|
|
296
|
+
- **OAuth 令牌过期时积分胶囊会暂时失效**。复用桌面 App 登录态时，打开一次 MiniMax Code 让它自行续期即可；用插件自己登录的，插件会用自己的 refresh token 续期（服务端会轮转 refresh token，插件会把新的一对写回自己的文件）。这不影响模型对话。
|
|
297
|
+
- **签到需要账号能领**。签到是上游给账号的权益，插件只是替你按那个按钮；服务端判定「暂不可签到」时插件只会如实显示，不会重试或绕过。
|
|
298
|
+
- **自动签到默认关闭**，且只在服务端明确说「当天可领」时才发请求、每天至多一次。是否开启、以及这样做是否符合 MiniMax 的服务条款，请自行判断。
|
|
299
|
+
- **不提供设置界面卡片**。插件不在 DSH 设置页注册卡片；界面只增加输入框下方的一枚胶囊，以及插件页面里的一张小卡片。
|
|
300
|
+
- **上游接口非公开**，MiniMax 客户端更新后可能失效。余额接口失效时胶囊会显示「积分不可用」，不会影响模型对话。
|
|
301
|
+
- **设备码流需要能访问 `account.minimax.cn`**，且授权时要在浏览器里能登录 MiniMax 账号。某些内网或受限网络下打不开授权页。
|
|
302
|
+
|
|
303
|
+
## 更新记录
|
|
304
|
+
|
|
305
|
+
### 0.5.0（2026-10-20）
|
|
306
|
+
|
|
307
|
+
- **新增「自己登录」**：插件可以自己走 OAuth 设备码流登录 MiniMax Code，**不再依赖本机已安装并登录的桌面 App**。你在自己的浏览器里确认，插件不接触密码；凭据存在插件自己的文件里，不写客户端的目录。
|
|
308
|
+
- **新增「每日签到」**：读取上游的七天一签进度（400/400/400/1000/400/400/1000 = 4000 分/轮），显示当天状态与到期批次，并提供手动「签到」与**默认关闭**的「每天自动签到」。
|
|
309
|
+
- **实测更正**：`mmoat_` 令牌**既能调模型网关也能调账户接口**（此前文档写「OAuth 打网关会 401」，是错的）—— 所以一次登录即可覆盖模型、积分与签到。
|
|
310
|
+
- 插件自建的两条路由：状态路由之外新增一条 POST 动作路由（签到、登录、开关设置），**仅限 loopback**。
|
|
311
|
+
|
|
312
|
+
### 0.4.2（2026-10-19）
|
|
313
|
+
|
|
314
|
+
- **可发现性**：npm 描述改为中英双语，关键词补齐（`dsh`、`credits`、`usage` 等）；GitHub 仓库描述与 topics 同步更新。
|
|
315
|
+
- 仓库内新增 [`awesome-dsh-plugin-submission/`](awesome-dsh-plugin-submission/)：市场收录条目草稿与提交规范。
|
|
316
|
+
- 新增[英文版 README](README.en.md)。
|
|
317
|
+
|
|
318
|
+
### 0.4.1（2026-10-19）
|
|
319
|
+
|
|
320
|
+
- **修正台账翻页参数**：接口会**接受** `page` 然后**忽略**它，真正生效的是 `page_number`。批次超过 100 笔的账号原本会反复收集同一页。
|
|
321
|
+
- **更正到期规则表述**：「发放后 29 天」是拿 UTC 发放时刻对 UTC 到期时刻的混算假象，真实规则是**发放日 + 30 个自然日**（按账户时区当日 00:00 失效）。另存在 365 天制式批次，所以到期日一律读接口的 `expire_at_ms`。
|
|
322
|
+
- 更正两处表述：过期**不清零**批次的 `remaining_amount`（可能有负值残留），而是把过期批次**排除在余额之外**；台账合计与余额在静止期逐位相等，采样间隔里的差额是期间真实消耗。
|
|
323
|
+
|
|
324
|
+
### 0.4.0（2026-10-19）
|
|
325
|
+
|
|
326
|
+
- **新增「积分即将过期」**：积分是按笔发放、每批独立到期的（发放日 + 30 个自然日）。插件读取积分台账 `GET /minimax-cloud/api/v1/credit/details`，在**插件页面**与胶囊里显示 7 天内到期、30 天内到期、最近到期日与到期批次清单。
|
|
327
|
+
- **只统计仍有余额的批次**，避免把「已用光但快到期」的批次算成损失。
|
|
328
|
+
- **插件页面卡片**：在「设置 → 插件 → DSH Connect MiniMax Code」新增一张卡片（余额、赠送/购买拆分、到期分布、到期批次、本机消耗与等效金额），列表里则显示一行摘要。
|
|
329
|
+
- 胶囊与卡片共用一个状态存储与同一个轮询器，多个界面不会重复请求账户接口。
|
|
330
|
+
|
|
331
|
+
### 0.3.0（2026-10-19）
|
|
332
|
+
|
|
333
|
+
- **新增积分余额显示**：对话框输入框下方的胶囊显示 MiniMax Code 的剩余积分（赠送/购买拆分），点开可看两次读取之间的消耗、本机累计 token 与按官方价目表折算的等效金额。
|
|
334
|
+
- **新增用量计量**：每次请求的 `usage` 取自上游响应本身，累计到本机并折算金额。
|
|
335
|
+
- **新增账户接口定位**：找到桌面 App 每天真实调用的 `POST /matrix/api/v1/commerce/get_membership_info`，并**推翻了 0.2.x 「无法显示额度」的结论**——原因见「积分余额与用量」末尾。
|
|
336
|
+
- **令牌策略调整**：模型网关用 JWT、账户接口用桌面 App 的 OAuth 令牌；后者过期时插件会用 App 已存的 refresh token 续期，并按客户端原格式写回，不影响桌面 App 登录态。
|
|
337
|
+
- **首次带浏览器侧插件**：新增 `lib/client.js`（classic script），只注册一枚 composer dock 胶囊。**升级后需重启一次 DSH**。
|
|
338
|
+
|
|
339
|
+
### 0.2.3（2026-10-19）
|
|
340
|
+
|
|
341
|
+
- **同步上游模型变动**：MiniMax 下架了 `M2.7`、`M2.7-highspeed` 两个旧模型；此前以匿名形式灰度的测试模型（代号 "space bunny" / 太空兔）正式发布为 **`M3.1-Flash`**。当前上游实时目录为 `M3`、`M3.1-Flash`。
|
|
342
|
+
- 内置兜底列表与文档随之更新。**已登录用户无需更新插件**即可看到模型变动（列表来自上游实时目录），本次发布只是让未登录兜底、测试与文档与上游保持一致。
|
|
343
|
+
|
|
344
|
+
历史版本见 [GitHub Releases](https://github.com/JeffTsuiCUG/dsh-connect-minimaxcode/releases) 与 [npm 版本列表](https://www.npmjs.com/package/dsh-connect-minimaxcode?activeTab=versions)。
|
|
345
|
+
|
|
346
|
+
## 市场收录与展示
|
|
347
|
+
|
|
348
|
+
插件已包含可安装的 `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/)。
|
|
349
|
+
|
|
350
|
+
市场截图按当前约定由**插件自己仓库根目录的** `screenshots.json` 声明（注册表 `data/screenshots.json` 是旧约定下的回退，不再新增键）。本仓库目前**尚未提供截图**，所以还没有这个文件；补上截图后，在根目录放 `screenshots.json`（内容是图片相对路径的数组）即可被市场卡片取用。
|
|
351
|
+
|
|
352
|
+
> 界面胶囊放在**输入框下方的 dock**，而不是输入框工具栏：工具栏是**共享插槽**，外壳自己的控件和别的插件都注册在那里，无法保证每个占用者都可见——同族插件就因为这个原因丢过一次读数。
|
|
353
|
+
|
|
354
|
+
## 卸载
|
|
355
|
+
|
|
356
|
+
```bash
|
|
357
|
+
dsh plugin --profile desktop remove dsh-connect-minimaxcode
|
|
358
|
+
```
|
|
359
|
+
|
|
360
|
+
## 开发
|
|
361
|
+
|
|
362
|
+
```bash
|
|
363
|
+
pnpm install
|
|
364
|
+
pnpm test # 单元测试 + 宿主集成测试
|
|
365
|
+
pnpm typecheck # 类型检查
|
|
366
|
+
pnpm build # 构建
|
|
367
|
+
```
|
|
368
|
+
|
|
369
|
+
构建依赖 `@earendil-works/pi-ai`，需与宿主中 `dsh-llm-pi-ai` 解析出的版本一致（当前为 `0.85.x`），否则类型不兼容。
|
|
370
|
+
|
|
371
|
+
界面半边（`src/client.ts`）由 `tsconfig.client.json` 单独编译成 **classic script**（`lib/client.js`）：宿主以 `<script>` 方式加载客户端 bundle，若产出 ESM 会直接导致 Web 启动失败（`Cannot use import statement outside a module`），所以这里刻意不用打包器、也不自带 React——React 来自宿主的浏览器模块表。
|
|
372
|
+
|
|
373
|
+
**`lib/` 是纳入版本管理的构建产物**，不是生成物。这是刻意为之：git 源安装拿到的是仓库原样内容，若不含 `lib/`，pnpm 会判定该包"需要构建"并触发 `prepare`，随即被构建脚本白名单拦下。改动源码后请重新构建并提交：
|
|
374
|
+
|
|
375
|
+
```bash
|
|
376
|
+
pnpm build && git add lib
|
|
377
|
+
```
|
|
378
|
+
|
|
379
|
+
## 同类插件
|
|
380
|
+
|
|
381
|
+
这些插件与本插件的思路一致——**复用你本机桌面 App 已有的登录态，把模型接进 DSH**，无需另配 API Key。它们由不同作者独立开发，与本项目无隶属关系。
|
|
382
|
+
|
|
383
|
+
| 插件 | 数据来源 | 每日签到领免费额度 | 额度 / 用量显示 |
|
|
384
|
+
|---|---|---|---|
|
|
385
|
+
| **dsh-connect-trae** | Trae（国内版 + 国际版） | ✅ 国内版 | ✅ Work / 通用积分概览 |
|
|
386
|
+
| **dsh-qoder-connect** | Qoder（国内版 + 国际版，PAT） | ✅ 每日 100 Credits | ✅ 侧栏额度小卡 + 明细 |
|
|
387
|
+
| **dsh-workbuddy-connect** | WorkBuddy（国内版 + 国际版） | — | ✅ 剩余积分 + 明细 |
|
|
388
|
+
|
|
389
|
+
> 各插件的签到规则、额度口径与限制以各自文档为准。下表为同一台机器上的实测读数，仅代表当时状态，非承诺。
|
|
390
|
+
|
|
391
|
+
### [dsh-connect-trae](https://github.com/dingminhua/dsh-connect-trae)
|
|
392
|
+
|
|
393
|
+
把本机已登录的 Trae 接入 DSH，国内版与国际版可同时使用。国内版支持每日签到领积分，并提供 Work / 通用积分的只读概览。注意 Trae 的签到按「每台设备每天一次」限制。
|
|
394
|
+
|
|
395
|
+
```bash
|
|
396
|
+
dsh plugin --profile desktop add dsh-connect-trae
|
|
397
|
+
```
|
|
398
|
+
|
|
399
|
+
### [dsh-qoder-connect](https://github.com/masknull/dsh-qoder-connect)
|
|
400
|
+
|
|
401
|
+
以个人访问令牌（PAT）接入 Qoder，双区域独立配置。每日自动签到领取 100 Credits 算力额度，签到时刻可自定义（默认 10:00，UTC+8），并带开机防漏补签；另有侧栏额度展示与逐包明细。
|
|
402
|
+
|
|
403
|
+
```bash
|
|
404
|
+
dsh plugin --profile desktop add dsh-qoder-connect
|
|
405
|
+
```
|
|
406
|
+
|
|
407
|
+
### [dsh-workbuddy-connect](https://github.com/corrinehu/dsh-workbuddy-connect)
|
|
408
|
+
|
|
409
|
+
接入 WorkBuddy 桌面 App，国内版与国际版可并存，各自使用自己的账号与积分。提供账号信息、令牌有效期与剩余积分查看，并带 CLI：
|
|
410
|
+
|
|
411
|
+
```bash
|
|
412
|
+
dsh plugin --profile web exec dsh-workbuddy-connect status
|
|
413
|
+
```
|
|
414
|
+
|
|
415
|
+
> 该插件的版本需与你的 DSH 内核严格对应（不同内核线用不同版本），安装前请见其 README 的版本对应表。
|
|
416
|
+
|
|
417
|
+
## 致谢
|
|
418
|
+
|
|
419
|
+
- **[corrinehu/dsh-workbuddy-connect](https://github.com/corrinehu/dsh-workbuddy-connect)** — **本插件的灵感来源**。「复用桌面 App 本机登录态、把已登录模型接进 DSH」的整体思路由该项目最早确立，本插件沿用同一做法；凭据只读复用的设计也参照于此。
|
|
420
|
+
- **[dingminhua/dsh-connect-workbuddy](https://github.com/dingminhua/dsh-connect-workbuddy)** — 同方向的另一实现，本插件的**插件结构与 provider 注册组织方式**参考了它（其连接内核亦参照 corrinehu 的实现，见该项目致谢）。
|
|
421
|
+
- [dingminhua/dsh-connect-trae](https://github.com/dingminhua/dsh-connect-trae) — 同作者的 DSH 插件，可作为 DSH 插件结构的参照。
|
|
422
|
+
|
|
423
|
+
> 上方「同类插件」中的项目均为独立开发者的作品，与本项目无隶属或背书关系，各自遵循其自身的许可与免责声明。
|
|
424
|
+
|
|
425
|
+
## 许可证
|
|
426
|
+
|
|
343
427
|
[MIT](./LICENSE)
|