@eddyskywalker/dsh-chatgpt-subscription 0.37.0 → 0.38.1

package/CHANGELOG.md

@@ -2,6 +2,30 @@
 
 ## Unreleased
 
+## 0.38.1 - 2026-10-24
+- **[kimi-code] 请求体上限改成按模型分档：1M 档 8 MiB、256K 档 2 MiB（`DSH_KIMI_CODE_MAX_BODY_BYTES` 仍是全局强制覆盖）**
+  - **现象**：1M 上下文档位（`k3` / `k3.1-pro` / `k3.1-pro-highspeed` / `kimi-for-coding`）的会话把中文正文写到 3–4 MB 就被本线路的本地字节守卫拒绝，请求根本没发出去；宿主压缩也救不回来——压缩请求自己同样超过那个上限，于是长会话表现为「压缩一次后仍然失败」，而服务端从未拒绝过这个体积。
+  - **根因**：这条线路对**所有**模型套用同一个 `MAX_MESSAGE_BODY_BYTES`（2,097,152）。该数字来自官方错误参考里的通用示例（`total message size N exceeds limit 2097152`），**从未针对 1M 上下文档位实测**；而 1M 窗口的正文按英文约 4 MB、按密集中文约 4.5 MB，2 MB 必然先到。官方 `kimi-cli` 全仓库没有字节守卫，说明这个上限至少不是客户端必需的。
+  - **改法（分档）**：`model-catalog.ts` 的 `KimiCodeCatalogModel` 新增必填字段 `maxRequestBodyBytes`：`k3` / `k3.1-pro` / `k3.1-pro-highspeed` / `kimi-for-coding` = **8 MiB（8,388,608）**，`k3-256k` / `kimi-for-coding-highspeed` = **2 MiB（2,097,152，保持原值）**。8 MiB 的依据是「1M 窗口的正文大小」：一个 1M token 的请求体按英文约 4 MB、按密集中文约 4.5 MB，8 MiB 留出近一倍余量，所以**字节上限不会成为 1M 会话的实际瓶颈**；真正先到的是模型自身的 token 窗口——服务端回 `Your request exceeded model token limit`，该措辞已被 `common/context-overflow.ts` 归一到 `CONTEXT_WINDOW_EXCEEDED`，压缩与重试照旧生效。8 MiB 仍是**待实测的上界**，不是文档写明的网关上限。
+  - **改法（代码）**：`types.ts` 新增 `LONG_CONTEXT_MESSAGE_BODY_BYTES`（8 × 1024 × 1024，常量定义在 `model-catalog.ts`、由 `types.ts` 重新导出，避免 ESM 循环）与 `maxRequestBodyBytesFor(model, env)`，优先级为 **env → `model.maxRequestBodyBytes` → `DEFAULT_MAX_MESSAGE_BODY_BYTES`**（注册表不认识的 id 走最保守的 2 MiB）；`maxMessageBodyBytes(env)` 与其语义**原样保留**（无模型上下文的调用方仍拿 2 MiB）。`mapper.ts` 的 `assertRequestBodyFits(body, carriesVideo = false, context?, limit?)` 新增可选 `limit`，拒绝文案引用生效上限，不传时逐字节等于旧行为。`adapter.ts` 的 `bodyLimit` 改为 `carriesVideo ? MAX_VIDEO_MESSAGE_BODY_BYTES : maxRequestBodyBytesFor(<该模型的注册表行>, process.env)`，并把这个 `bodyLimit` **显式传给两处** `assertRequestBodyFits`——此前这两处各自又算一遍上限，模型档位根本到不了守卫。注册表行按 id 从 `model-catalog.ts` 取，而不是直接用线上 `/v1/models` 的条目：线上目录只报能力、从不报字节额度。
+  - **改法（env）**：`DSH_KIMI_CODE_MAX_BODY_BYTES` 仍是**全局强制覆盖、优先级最高**；空串、非有限、`0`、负数一律回落到**该模型的默认值**而不是关闭守卫（合法值会 floor，前后空格容忍）。视频档 `MAX_VIDEO_MESSAGE_BODY_BYTES`（64 MiB）不受影响。
+  - **测试**：新增 `test/kimi-code-body-limit-per-model.test.ts`（16 例）——六个条目的 `maxRequestBodyBytes` 逐一切值（8 MiB ×4 / 2 MiB ×2）、8 MiB 对两种 1M 正文密度都留有余量、resolver 的三级优先级（env 双向覆盖、模型行、未知 id 回落 2 MiB、小数 floor、空白容忍）、非法值（`''`、纯空白、`abc`、`0`、`-1`、`-2097152`、`NaN`、`huge`）回落到模型默认值而不关守卫、端到端 3.5 MB 在 `k3.1-pro` 上**能发出**（fetch 调用 1 次）而在 `k3-256k` 上被拒（fetch 0 次、文案含 `2097152`、码为 `CONTEXT_WINDOW_EXCEEDED`）、4.5 MB 能发、8.5 MB 被拒且文案含 `8388608`、env 强制把 1M 档按回 2 MiB、env 拼错仍拒、13 MB 视频照旧走 64 MiB 档、以及 `assertRequestBodyFits(body)` 无参调用仍按 2 MiB 抛错。另修正两处**依赖旧的全局 2 MB**的既有用例（**没有删任何断言**）：`kimi-code-capacity.test.ts` 的「2.1 MB 请求本地即拒」与 `kimi-code-adapter.test.ts` 的「不做没做过的省略」改跑 `k3-256k`——那两处的体积仍在该档 2 MB 之上，测的行为（本地拒绝、码、文案、fetch 零调用）一条未减。
+  - **验证**：`npm run typecheck` 三工程 0 错误（退出码 0）；`npx vitest run test/kimi-code**` 34 文件 / 512 例全绿；全量 `npm test` 282 文件通过 / 2 skipped、4649 passed / 8 skipped / 0 failed；`npm run build` 通过。
+  - **文档**：README 的 Kimi Code 小节把「请求体超 2 MB 本地即拒绝」改写成「按模型分档：1M 档 8 MiB / 256K 档 2 MiB」，写明 8 MiB 是待实测上界与该口径的推导、env 仍为全局覆盖且非法值回落，「上下文窗口」段落与错误处理总表里的 2 MB 措辞同步更新，并注明 `DSH_KIMI_CODE_BYTES_PER_TOKEN` 的折算基准**刻意仍是不随模型变动的 2 MiB**。
+  - **已知边界**：`DSH_KIMI_CODE_BYTES_PER_TOKEN` 的窗口折算仍以那个与模型无关的 2 MiB（设了 env 则取 env）为基准，不跟随按模型档位——它是可选的提前压缩开关而不是守卫，本次刻意不动；不想提前压缩时不设该变量即可（默认就是不设）。
+
+## 0.38.0 - 2026-10-24
+- **[kimi-code] 新增 K3.1 Pro 系列（与其它模型同一 OpenAI 兼容 chat completions）、只支持思考的档位、以及缓存写入这个计费项**
+  - **现象**：`k3.1-pro` / `k3.1-pro-highspeed` 不在模型目录、设置卡与能力表里；「默认思考档位」永远列着 `low` / `high` / `max` 与「关闭思考」，而 K3.1 Pro 根本关不掉（服务端 400）；缓存区块只有命中率、命中 / 新处理 / 输出 tokens 与请求数，**写入**这个独立计费项一个数字都没有，看不出 5m / 1h 两档各写了多少。
+  - **模型目录**：两条新条目按官方型号表写入（`k3.1-pro` 默认 256K、可覆盖到 1M；`k3.1-pro-highspeed` 1M），含 `thinkingType: 'only'`、`defaultReasoningEffort: 'max'` 与 `quotaMultiplier: null`（官方未公布相对倍率，卡片显示「未公布」而不是猜成 1×）。**协议不新增分支**：本线路对全部模型只走 OpenAI 兼容 chat completions（与官方 agent 的 `type = "kimi"` 一致），因此 K3.1 Pro 的请求照常发往 `/v1/chat/completions`，视频输入按型号表声明可用。
+  - **thinking-only**：`types.ts` 增 `thinkingTypeFor` / `defaultReasoningEffortFor` / `coerceThinkingEffort`，`reasoningEffortsFor` 对 `only` 行剔除 `none`；`adapter.ts` 在构建 body 之前加一道闸门（THE THINKING GATE）：被禁的 `none` 抬到模型默认档并通过 `recordThinkingCoercion` 记录（`KIMI_CODE_THINKING_COERCED` 警告），而不是让整轮失败。
+  - **缓存写入**：总量读 `usage.prompt_tokens_details.cache_write_tokens`（chat）与 `cache_creation_input_tokens`（Anthropic），5m / 1h 分档读 `Msh-Usage-Cache-Write-Tokens-5m/-1h` 响应头；`KimiCodeCacheStatsDto` 的 `cacheWriteTokens` / `cacheWrite5mTokens` / `cacheWrite1hTokens` 由 `routes.ts` 填真值（原 `cacheWriteTokensNote: 'always-zero-on-this-route'` 占位删除）。chat wire 的新处理量改为 `total − cached − written`（三者互斥），Anthropic 的 `input_tokens` 仍不减——它本身不含缓存。
+  - **改法（客户端）**：新增 `src/client/kimi-code/labels.ts`——`wireLabel`、`effortLadder`（读模型声明的档位，`thinkingType === 'only'` 时剔除 `none`）、`canDisableThinking`、`effortOptions`（取已勾选模型的并集；「关闭思考」是开关不是档位，任一勾选模型允许它就保留），两张卡片都从这里取标签。档位下拉改由 `effortOptions` 驱动；存着的档位若所有勾选模型都不接受，仍保留该选项并标注「当前勾选的模型不接受」。只支持思考的模型在档位旁给一句说明（含模型名与 400），能力表新增「只支持思考」标记与脚注。缓存区块新增一行 `缓存写入 = 总量 · 5 分钟档 · 1 小时档`，**0 也照实显示**（空白会被读成「没有测量」）。
+  - **改法（三语）**：`kimi-code/locales.ts`（zh + en）与 `locales-ru/kimi-code.ts` 同步新增 `capThinkingOnly` / `capEfforts` / `capThinkingOnlyFootnote` / `effortThinkingOnlyNote` / `effortNotOffered` / `quotaUnknown` / `cacheWrite` / `cacheWrite5m` / `cacheWrite1h` / `cacheWriteHint` / `unknownMetric`，并按官方口径重写 `cacheTtlHint`、`cacheTtlDefault`、`defaultReasoningEffortHint`；俄语包键集由 `Record<KimiCodeLocaleKey, string>` 在编译期强制，缺一个键 `tsc` 就红。
+  - **测试**：新增 `test/kimi-code-k31.test.ts`（17 例：两条条目的全部字段、thinking-only 语义、双值 wire 与视频按声明保留、卡片契约字段）、`test/kimi-code-k31-card-ui.test.tsx`（8 例）、`test/kimi-code-effort-ladder.test.ts`（6 例）与 `test/kimi-code-cache-write.test.ts`（9 例：chat wire 的 usage 三分解、Anthropic 不减、响应头分档、以及 thinking 闸门在 chat / Anthropic 两条 wire 上的行为）；`test/kimi-code-capability-ui.test.tsx` 补「未公布倍率」与「只支持思考 + 400 脚注」两例。
+  - **验证**：`npm run typecheck` 三工程 0 错误；全量 `npm test` 281 文件通过 / 2 skipped，4633 passed / 8 skipped / 0 failed（删掉的用例全部只属于已撤除的 Responses 分支）。
+  - **文档**：README 的线路总览把 Kimi 的协议列改为「OpenAI 兼容 Chat Completions（可选 Anthropic Messages）」，模型目录由四款改为六款，补缓存写入那一行、倍率表里的两个「未公布」，并明确「本线路对全部模型使用 OpenAI 兼容 chat completions（与官方 agent 的 `type = "kimi"` 一致）」、视频清单加入 `k3.1-pro`，以及设置步骤里「默认思考档位跟随模型声明」。
+
 ## 0.37.0 - 2026-10-23
 - **[progress-updates] 进展更新补上「开局」与「收尾」两条硬要求**
   - **现象**：任务开始和结束都没有进展条目，整场只在被催到的时候冒出两三条；面板看着像「只有出结论才有动静」。

package/README.md

@@ -36,7 +36,7 @@
 | Provider ID | 订阅 | 协议 | 登录方式 | 模型目录来源 |
 | --- | --- | --- | --- | --- |
 | `codex-chatgpt` | ChatGPT（Plus / Pro / Business…） | Responses | 浏览器 OAuth（localhost:1455 回调），或导入本机 Codex CLI 登录 | **实时** `/backend-api/codex/models` |
-| `kimi-code` | Kimi 会员 | Anthropic Messages | **设备码**（RFC 8628） | 实时 `/v1/models` + 本地兜底 |
+| `kimi-code` | Kimi 会员 | OpenAI 兼容 Chat Completions（可选 Anthropic Messages） | **设备码**（RFC 8628） | 实时 `/v1/models` + 本地兜底 |
 | `command-code` | Command Code | Anthropic / OpenAI 双轨 | 浏览器 OAuth 或粘贴 API Key | 实时 `/provider/v1/models` |
 | `claude-subscription` | Claude Pro / Max | Anthropic Messages | 手动粘贴 / loopback 回调 | 实时 `/v1/models` + 本地兜底 |
 | `minimax-code` | MiniMax Code 编程订阅 | Anthropic Messages | **复用桌面端登录态** 或设备码 | **硬编码**（见下） |
@@ -119,23 +119,26 @@
   - 真正的 429 背压（`too many requests` / `engine is currently overloaded`）、连接失败与流停滞；
 - **不重试**，直接给出可操作提示（换模型 / 降上下文 / 等窗口重置 / 重新登录）：配额耗尽型的 429、403 的账号额度上限、401 里的套餐权限不足、400 请求格式错误；
   - 服务把这些含义压进**同一个状态码**，因此分类读响应正文而不只看状态码；
-- 模型目录为订阅侧的四款模型：`k3`（1M 上下文，需 Allegretto+；Moderato 上限 256K，故默认按 256K 计算，可用上下文覆盖升到 1M）、`k3-256k`、`kimi-for-coding`（K2.8 Preview）、`kimi-for-coding-highspeed`（约 6× 速度、3× 额度），运行时以 `GET /v1/models` 为准；
+- 模型目录为订阅侧的六款模型：`k3`（1M 上下文，需 Allegretto+；Moderato 上限 256K，故默认按 256K 计算，可用上下文覆盖升到 1M）、`k3-256k`、`kimi-for-coding`（K2.8 Preview）、`kimi-for-coding-highspeed`（约 6× 速度、3× 额度）、`k3.1-pro`（K3.1 Pro，默认 256K、可覆盖到 1M，需 Moderato 及以上，1M 需 Allegretto 及以上）与 `k3.1-pro-highspeed`（K3.1 Pro Highspeed，1M 上下文、约 2 倍配额，需 Pro / Allegretto 及以上），运行时以 `GET /v1/models` 为准；
 - **K3 行为按其官方文档实现**：
   - 思考档位只发 `low` / `high` / `max`（其余写法收敛映射，未知档位不发送）；关闭思考发 `thinking:{type:"disabled"}`，开启时发 `thinking:{type,effort,keep:"all"}`；
   - **开启思考时每条 assistant 消息都回传 `reasoning_content`**（无推理则回传空串——服务要求的是空值而非省略，否则 400）；
   - 不发送 `temperature`（采样参数按模型固定，显式值会报错）；
   - 工具调用 id 截断到 64 字符；
   - `stop` 按上限裁剪为最多 5 条、每条 ≤32 字节，超长整条丢弃（截断的停止串会在错误位置终止生成）；
+  - **K3.1 Pro 只支持思考模式**：关闭思考（`none`）会被服务端以 `400` 拒绝，所以它的档位只有 `low` / `high` / `max`、默认 `max`；「默认思考档位」下拉只列出勾选模型真正声明的档位，任一勾选模型允许关闭思考时它才出现，被拒时卡片上直接写明原因；
+- **本线路对全部模型使用 OpenAI 兼容 chat completions**（与官方 agent 的 `type = "kimi"` 一致）：K3.1 Pro 系列与其它模型同一协议、同一端点（`/v1/chat/completions`），Anthropic Messages 只在实时目录为某个 id 声明时启用；视频输入按官方型号表声明走，K3.1 Pro 系列可用；
 - **K3 的长思考不会被截断**：输出上限跟随上下文窗口（保留 4096 余量），因为 `reasoning_content` 计入输出，固定 32K 会把 `max` 档的长推理中途截断并返回 `length`；调用方已知 prompt 规模时上限会被下调到放得下，未知时不做猜测；
-- **请求体超 2 MB 本地即拒绝**：该端点最常见的 400 是 `total message size N exceeds limit 2097152`，官方文案不给建议，这里直接按真实序列化体积拦截，并按「循环实际做了什么」给出处方（有图可丢但丢了也补不上缺口 / 图已丢完仍超限 / 本来无图，三种情况文案不同，不再声称发生了没发生的省略）；确有实测上限的部署（前置代理/网关）可设 `DSH_KIMI_CODE_MAX_BODY_BYTES` 指定该档上限，取值非正整数时**回落到默认值而不是关闭守卫**；带视频的请求走 64 MiB 档，不受该变量影响；**超限时报的是可恢复的溢出码**（`CONTEXT_WINDOW_EXCEEDED`）：DSH 会对该码强制压缩本轮历史并重试同一步，所以长会话的表现是「压缩一次后继续」，而不是整轮失败——官方 `kimi-cli` 从不特殊处理 `2097152`，它靠 85% 提前压缩避开，详见下文「上下文窗口」那条；
+- **请求体上限按模型分档：1M 档 8 MiB / 256K 档 2 MiB，本地即拒绝**：该端点最常见的 400 是 `total message size N exceeds limit 2097152`，但 `2,097,152` 来自官方文档的通用错误示例，**从未针对 1M 上下文档位实测**——1M 档的真实会话（中文正文 3–4 MB）会被本地守卫提前拦下，而宿主压缩也救不回来（压缩请求自己同样超限）；官方 `kimi-cli` 全仓库没有字节守卫，说明这个上限至少不是客户端必需的。现在按模型档位：`k3` / `k3.1-pro` / `k3.1-pro-highspeed` / `kimi-for-coding` = **8 MiB（8,388,608，待实测的上界）**，`k3-256k` / `kimi-for-coding-highspeed` = **2 MiB（保持原值，窗口与上限本就对齐）**。8 MiB 的依据是「1M 窗口的正文大小」：一个 1M token 的请求体按英文约 4 MB、按密集中文约 4.5 MB，8 MiB 留出近一倍余量，所以**字节上限不会成为 1M 会话的实际瓶颈**；真正先到的是模型自身的 token 窗口——服务端回 `Your request exceeded model token limit`，该措辞已被 `common/context-overflow.ts` 归一到 `CONTEXT_WINDOW_EXCEEDED`，压缩与重试照旧生效。拦截仍按真实序列化体积，并按「循环实际做了什么」给出处方（有图可丢但丢了也补不上缺口 / 图已丢完仍超限 / 本来无图，三种情况文案不同，不再声称发生了没发生的省略）；`DSH_KIMI_CODE_MAX_BODY_BYTES` 仍是**全局强制覆盖、优先级最高**，确有实测上限的部署（前置代理/网关）用它指定该档上限，取值非正整数时**回落到该模型的默认值而不是关闭守卫**；带视频的请求走 64 MiB 档，不受该变量影响；**超限时报的是可恢复的溢出码**（`CONTEXT_WINDOW_EXCEEDED`）：DSH 会对该码强制压缩本轮历史并重试同一步，所以长会话的表现是「压缩一次后继续」，而不是整轮失败——官方 `kimi-cli` 从不特殊处理 `2097152`，它靠 85% 提前压缩避开，详见下文「上下文窗口」那条；
 - **缓存是自动的，且无法手动干预**：
   - Kimi 按请求内容哈希命中前缀缓存。实测 `prompt_cache_key` 与 Anthropic `cache_control` 标记**均被忽略**（设与不设、同 key 与异 key 命中的是同一缓存），设备 id 与协议切换也不影响；
   - TTL 实测在 300–1800 秒之间，按 256 token 对齐；`/messages` 与 `/chat/completions` **共享同一缓存**；
   - 真正决定命中率的是**内容稳定性**：同一会话内 `system` 或工具列表一旦变化会使整个前缀缓存失效（实测归零）。因此应保持工具集合稳定、把新增内容追加在末尾；
   - 卡片会显示滚动命中率，方便验证效果；
   - **写入时长可手动选择**（设置页）：`prompt_cache_options`（OpenAI 兼容线路）或**顶层** `cache_control`（Anthropic 兼容线路）控制缓存**写入时长**，与上面的「无法干预」不矛盾——那一条说的是**缓存身份**（由内容前缀哈希决定），TTL 管的是另一回事；
-  - 档位在**首次写入时锁定**，之后无法改写、命中时按原档免费续期；1 小时写入约为 5 分钟的两倍价，只有同一前缀会在一小时内被反复读取才划算。不选择时不发任何缓存字段；
-- **视频输入可用**（`k3`、`kimi-for-coding`）：
+  - 档位在**首次写入时锁定**、之后无法改写，命中时按原 TTL 续期（官方口径：不传时按 **5 分钟档**写入，只有 5m / 1h 两档）；1 小时写入约为 5 分钟的两倍价，只有同一前缀会在一小时内被反复读取才划算。不选择时不发任何缓存字段；
+  - 设置卡的缓存区块把**写入**单独列成一行（总量 + 5 分钟档 + 1 小时档）：写入是独立计费项，折进「新处理 tokens」会让命中率说错话；某个分档是 0 时照实显示 0——响应头缺失只表示服务端没回报该档，不等于那里确实没写；
+- **视频输入可用**（`k3`、`kimi-for-coding`、`k3.1-pro`）：
   - DSH 的模态词表只有 `text`/`image`，但它是可合并扩展的接口，本插件用 TypeScript 模块增强把它扩到 `video`（**未改动 DSH 任何代码**），因此视频走 DSH 真实的能力通道，而不是只能显示在提示里；
   - 适配器把视频映射为服务文档的 `{type:'video_url',video_url:{url:'data:…'}}`。视频与图片**各有独立预算**（图片 1.5 MB、视频 48 MiB base64，最旧优先省略），请求体校验只在确实带视频时才放宽到 64 MiB；
   - 图片预算可用 `DSH_KIMI_CODE_MAX_IMAGE_BYTES` 覆盖（取值非正整数时回落到默认值）。视频预算**没有**环境变量出口，与 MiniMax 线路一致；
@@ -545,9 +548,9 @@ DSH 设置页的「Subagent」卡片会把勾选的模型写成会话级的允
 
 `kimi-code` 会像其他 Provider 一样出现在 DSH 模型选择器中。**上下文窗口**默认取模型目录值，可逐模型覆盖（用于 DSH 的压缩与溢出判断，支持 `1M` / `256K` / `200000` 等写法）——注意 `k3` 的 1M 上下文需要 Allegretto 及以上套餐，因此默认按 256K 计算，升级后再在此覆盖为 1M。
 
-**申报的窗口默认就是目录值或你的覆盖值，不做折算**——`k3` 覆盖成 1M 就按 1M 申报。撞上 2 MB 请求体上限时，本地守卫抛的是 `CONTEXT_WINDOW_EXCEEDED`：DSH 会对该码**自动压缩本轮历史并重试同一步**，所以表现是「压缩一次后继续」，不是整轮失败。想要「撞墙之前就自动压缩」，可设 `DSH_KIMI_CODE_BYTES_PER_TOKEN` 启用窗口折算：申报值 = `min(声明值, floor(2MB / d))`。取值按内容密度选——DSH 的 token 计量是固定密度（4 字符/token，见 `@deepseek-ai/dsh-token-meter`），看不见中文占 3 字节，所以「一个计量 token 占多少字节」= 4 × 每字符字节数：纯 ASCII 约 4、中英混合约 8、密集中文约 12；对应的字节墙分别是 524288 / 262144 / 174763 计量 token。实测：`d=4` → 524288（代码为主的会话在 1.68 MB 处压缩）、`d=8` → 262144（混合）、`d=12` → 174762（中文，三种密度都在墙前）。压力阈值是 `min(floor(0.8 × 窗口), 窗口 − 65536)`（`compaction-basic`：`thresholdRatio` 默认 0.8、`headroomTokens` 默认 65536、本线路不申报 `defaultMaxTokens` 故无输出预留）。该变量是**可选的提前压缩开关**而不是安全守卫：不设或拼错等于不启用，真正兜底的是上面那个恢复码。**默认思考档位**只提供 `low` / `high` / `max` 三档与「关闭思考」（服务对这三档以外的取值直接报 400）；切换模型或切换档位都会使上下文缓存失效，建议在同一会话内保持一致。
+**申报的窗口默认就是目录值或你的覆盖值，不做折算**——`k3` 覆盖成 1M 就按 1M 申报。撞上本档请求体上限时（1M 档 8 MiB、256K 档 2 MiB，见上一条），本地守卫抛的是 `CONTEXT_WINDOW_EXCEEDED`：DSH 会对该码**自动压缩本轮历史并重试同一步**，所以表现是「压缩一次后继续」，不是整轮失败。想要「撞墙之前就自动压缩」，可设 `DSH_KIMI_CODE_BYTES_PER_TOKEN` 启用窗口折算：申报值 = `min(声明值, floor(上限 / d))`——这里的「上限」是与模型无关的那个 2 MiB 守卫值（设了 `DSH_KIMI_CODE_MAX_BODY_BYTES` 则取它），它**刻意不跟随上面的按模型档位**：这个开关只决定「提前压缩落在哪里」，而真正兜底的仍是按模型档位的请求体守卫。取值按内容密度选——DSH 的 token 计量是固定密度（4 字符/token，见 `@deepseek-ai/dsh-token-meter`），看不见中文占 3 字节，所以「一个计量 token 占多少字节」= 4 × 每字符字节数：纯 ASCII 约 4、中英混合约 8、密集中文约 12；对应的字节墙分别是 524288 / 262144 / 174763 计量 token。实测：`d=4` → 524288（代码为主的会话在 1.68 MB 处压缩）、`d=8` → 262144（混合）、`d=12` → 174762（中文，三种密度都在墙前）。压力阈值是 `min(floor(0.8 × 窗口), 窗口 − 65536)`（`compaction-basic`：`thresholdRatio` 默认 0.8、`headroomTokens` 默认 65536、本线路不申报 `defaultMaxTokens` 故无输出预留）。该变量是**可选的提前压缩开关**而不是安全守卫：不设或拼错等于不启用，真正兜底的是上面那个恢复码。**默认思考档位**的选项跟随勾选模型自己声明的档位——`low` / `high` / `max`，以及在允许关闭思考的模型上才出现的「关闭思考」（服务对这些以外的取值直接报 400）；K3.1 Pro 系列只支持思考模式，硬关会被拒（400），所以勾选它时这一档不出现，卡片上会写明原因；切换模型或切换档位都会使上下文缓存失效，建议在同一会话内保持一致。
 
-**额度倍率**取自官方模型表并显示在设置页模型能力表的「说明」列（悬停可一并看到）：`k3` = **2×**、`k3-256k` = **1×**、`kimi-for-coding` = **1×**、`kimi-for-coding-highspeed` = **3×**。倍率绑定**模型 id**，与上下文长度、缓存命中率都无关——选 `k3` 就是 2×，哪怕只用几千 token。注册表不认识的新模型 id 显示为**未知**而不是猜成 1×。
+**额度倍率**取自官方模型表并显示在设置页模型能力表的「说明」列（悬停可一并看到）：`k3` = **2×**、`k3-256k` = **1×**、`kimi-for-coding` = **1×**、`kimi-for-coding-highspeed` = **3×**；`k3.1-pro` 与 `k3.1-pro-highspeed` 官方未公布相对倍率（后者只说了「约为常规版 2 倍」），因此显示为**未知**而不是猜成 2×。倍率绑定**模型 id**，与上下文长度、缓存命中率都无关——选 `k3` 就是 2×，哪怕只用几千 token。注册表不认识的新模型 id 显示为**未知**而不是猜成 1×。
 
 **区域**：默认使用中国大陆主机（`auth.kimi.com` / `api.kimi.com`）。国际账号可设置 `DSH_KIMI_CODE_OAUTH_HOST=https://auth.kimi.ai` 与 `DSH_KIMI_CODE_BASE_URL=https://api.kimi.ai/coding` 后重新登录；环境变量同时会钉住区域，设置页会显示当前解析到的主机。
 
@@ -1201,7 +1204,7 @@ npm pack --dry-run
 
 Kimi Code、MiniMax Code、Command Code、Claude 遇到“输入加输出预留超限”时，插件可在 HTTP 400/422 的完整 token 计数证明输入仍能放下、且上游确实采用了请求输出上限的情况下，仅降低输出上限重试一次。消息、工具和历史保持不变，摘要请求也适用。降低后的输出仍可能截断，截断不会冒充完整摘要。Codex 不支持该输出参数，不走此恢复；输入本身超限、模糊错误或流内错误仍交给 Harness 处理。这不是对所有压缩故障的通用修复。
 
-MiniMax、Kimi、Codex、Claude、Command Code 和 Antigravity 的错误处理会将明确的上下文超限错误交给 Harness 的溢出恢复机制。该机制需要宿主启用压缩后端；它不是无条件重发同一个超限请求。认证、配额和输出截断不会因此被当作上下文超限。**请求体字节限制是唯一按线路区分的**：Kimi Code 把「请求体超过 2 MB」的本地拒绝与网关原文 `total message size N exceeds limit 2097152` 都归入该码（压缩确实能缩小请求体，实测这是长会话最常见的 400），其余线路的请求体拒绝仍按普通错误呈现。手动压缩仍需生成完整摘要；如果摘要请求本身超限、被截断或缺少正文，修正错误分类也不能保证它成功。请保留失败会话中的 `compaction/end` 错误、provider/model、宿主及插件版本，以便定位。
+MiniMax、Kimi、Codex、Claude、Command Code 和 Antigravity 的错误处理会将明确的上下文超限错误交给 Harness 的溢出恢复机制。该机制需要宿主启用压缩后端；它不是无条件重发同一个超限请求。认证、配额和输出截断不会因此被当作上下文超限。**请求体字节限制是唯一按线路区分的**：Kimi Code 把「请求体超过本档上限（1M 档 8 MiB / 256K 档 2 MiB）」的本地拒绝与网关原文 `total message size N exceeds limit 2097152` 都归入该码（压缩确实能缩小请求体，实测这是长会话最常见的 400），其余线路的请求体拒绝仍按普通错误呈现。手动压缩仍需生成完整摘要；如果摘要请求本身超限、被截断或缺少正文，修正错误分类也不能保证它成功。请保留失败会话中的 `compaction/end` 错误、provider/model、宿主及插件版本，以便定位。
 
 | 现象 | 处理 |
 | --- | --- |