dsh-our-free-model

dsh-our-free-model

简体中文 | English

亮点

• 开箱即用，无配置环节——不需要账号、不需要 Key、不需要在后台申请配额。
• 上游来源公开透明——免费车道来源为 OpenCode 的 Zen 网关（https://opencode.ai），Kilo 渠道来源为 Kilo AI 的公共网关（https://kilo.ai），均直连、不经任何第三方中转。请求由谁处理、数据发往何处，见「上游是哪些源」与「免责声明」。
• 清单跟随上游——模型集合、上下文长度与能力在每次刷新时向上游重新拉取，插件内不保存静态快照。
• 选择器只广播可用的模型——上游清单已声明但网关明确拒绝路由的模型（返回 Model is unavailable、或 404 找不到该 id）从下拉框移除，仅在设置页保留记录并注明拒因；网关自身故障（5xx）、配额限制（429）、超时与断网不属于对模型的判定，一律保持可达；被地区策略拦截的模型归入 region-limited 分组。整轮探测全部被拒时同样保留，选择器不会为空。
• 公告中心 + 实时推送——仓库维护者在仓库中编辑 JSON 并推送后，所有已安装实例最迟在一个轮询周期内收到；正文为白名单约束下的 HTML，支持图文排版；urgent 级别触发全屏弹窗；可选系统级通知。
• 应用内升级——设置页一键升级：下载 → SHA-256 校验 → 备份 → 原子替换 → 校验回读 → 热重载，任一步失败自动回滚至上一版本。
• 热重载——升级与代码变更即时生效，无需重启应用；也可在设置页手动触发，或启用文件监视自动重载。
• 按响应体形状判定流式响应——网关在高负载下会以 application/json 的 content-type 返回完整的 SSE 帧序列。插件按响应体形状判定，并将已嗅探的字节重新注入流，既不会导致整轮失败，也不会因 header 与实际内容不符而将可用模型判为不可用。
• 思考强度实际生效——Light / Balanced / Deep 对应输出 token 预算 2 048 / 8 192 / 模型上限，且逐次调用留痕。思考不可关闭的模型（MiMo V2.6 等）三档整体翻倍为 4 096 / 16 384 / 模型上限，因为思考与正文共享同一输出额度；设置页每张模型卡均标注该档位实际下发的上限。该能力通过硬性输出上限实现，不依赖上游的 effort 参数（原因见「为什么用预算，而不是 reasoning_effort」）。
• 不依赖浏览器界面——插件仅将 llm 作为硬依赖，在没有 web server 的 composition（如 dsh-tui）中同样完成启动并输出模型；看板模块挂载在独立的 fiber 上，待 webServer 就绪后再注册路由，因此既不会阻塞模型车道，也不会因插件先于 web 服务加载而永久丢失设置页。
• 用量看板，数据全部留在本机——Token 热力图、总量曲线（支持总计与单模型视图）、输出速度与首字延迟逐次采样。不上传任何数据。
• OpenAI 兼容转发端口——本机其它工具通过 base URL 与 Key 即可调用这些模型。
• EAC 渠道（桌面端专属）——在 DeepSeek Harness 桌面端与 DSHEAC AIO 桌面端中自动解锁一条协付通道，模型以 EAC 前缀显示（如 EAC DeepSeek V4.1 Flash）；凭据加密密封，由宿主指纹闸门把守；该渠道在服务器侧校验 GitHub 授权（登录并 star 本仓库）后才放行对话；在命令行及其它宿主中该通道完全不存在。详见「EAC 渠道」。
• Kilo 渠道（免密免费池）——内置 Kilo AI 公共网关的免费模型池（isFree 清单实时拉取，含 kilo-auto/free 自动路由），无需任何账号或 Key；模型卡带 Kilo 徽章。思考强度与 EAC 渠道同款：模型自身的档位菜单（Off / Low / Medium / High，默认 High），经网关统一的 reasoning 参数真实下发——Off 已逐家族实测将思考归零（nemotron、ling、dots、poolside、apodex、cohere）；stepfun 与 liquid 端点强制思考（对关闭请求返回 400）、两个自动路由不透传关闭，这些模型的菜单不含 Off 档。该池由上游免费提供，上游会在其模型卡中声明 prompt 可能被记录用于改进服务——请勿发送敏感内容，详见「免责声明」。
• 聚合渠道，自带 Key——设置页新增一页，把第三方端点接进同一条模型清单：注册表内置 76 家提供商（NVIDIA NIM、OpenRouter、Groq、Cerebras、SambaNova、Gemini、DeepSeek、Mistral、Together、Fireworks、SiliconFlow、Nebius、Chutes、Hugging Face、Cloudflare、Z.ai、Kimi、MiniMax、QwenCloud/Alibaba、Bedrock、Vertex、Vercel AI Gateway、Azure OpenAI，以及无需账号的 Ollama、LM Studio、llama.cpp），写入 Key（本机免账号的提供商不需要）后其模型即以 provider/model 出现在选择器里，也可经本地网关调用。Key 只写入本机 0600 的 settings.json，API 只回显 hasKey 与 …abcd 指纹；每家可单独启停、测试（列表探测，不花一次生成）、发现模型、覆盖 Base URL 与模型清单。OAuth 与 ADC 认证的提供商照常列出，但标注为不可驱动。
• 省 Token——三件事：工具输出压缩（RTK）在请求发出前就地重写 tool_result（git diff / status / log、grep、find、ls、tree、构建日志、编号转储、搜索清单、重复日志行），实测 40 KB 的 git diff 移除 90% 的字节且模型仍能就它作答；提示词瘦身有 caveman 与 ponytail 两族、默认全关；另有五个不占用上游请求的本地应答。设置页用与用量图表同一批统计行显示压缩前后字节、节省比例、压缩块数与统计调用数。
• 路由（降级链）——把任意车道的模型串成一条命名链，以 combo:<name> 作为虚拟模型出现在选择器与网关上；fallback 固定从链首开始，round-robin 轮换起点并连续 N 轮粘滞。链接在输出任何正文之前失败会被整段丢弃，切换对调用方不可见；思考增量不算正文，因此「想了很久才撞上配额墙」正是降级最有价值的场景。
• 本地网关原生说 Anthropic——新增 POST /v1/messages（流式与非流式，含 thinking / tool_use 块、真实 stop_reason 与流内 error 事件）与 POST /v1/messages/count_tokens（本地估算）；/v1/models 广播全部车道，含聚合行与链路。网关页新增「接入客户端」分区，按实际绑定的端口与真实要求的密钥生成 Claude Code、Codex、OpenAI SDK、Anthropic SDK、curl 与局域网的可复制配方。
• 接口具备鉴权围栏——插件 HTTP 路由优先级高于内核 /api，因此内置与内核一致的信任检查（优先复用 composition 的 connection 服务，缺失时退回结构化围栏）。
• 十三个白嫖渠道，一体接入——CodeArts（华为云）、CodeBuddy / WorkBuddy（腾讯）、LobsterAI（有道）、Qoder / Qoder 中国版（阿里系）、TRAE（字节）、Cline、Loomy（讯飞）、Raccoon（商汤）、MiniMax Code、ZCode（智谱）、Gemini（Google Code Assist）十一个账号渠道开箱即用，外加 Kilo 免费车道与原匿名免费通道；OpenCode 账号渠道在本插件中默认停用。各渠道的登录流程、账号池、每日积分领取、模型黑名单与其本地 OpenAI 网关（Chat Completions + Responses，默认 127.0.0.1:8326）原样挂载与运行；凭据只写入宿主凭据库，浏览器永远拿不到明文。
• 九页毛玻璃界面——设置页顶部导航扩为九个页面：原有六页（免费模型（鱼缸水位 = 可用模型占比）、EAC 模型（鱼缸水位 = 协付池压力）、白嫖模型接入（十三张渠道卡：登录、账号、模型开关、一键领取积分）、数据看板（今日/全部 Token 消耗、平均生成速度、缓存命中率、成功率，账号透视与模型性能表、最近请求总览）、运行日志（逐请求明细：结果、耗时、首字、速度、Token 细分，失败原因悬停可见）与网关设置（网关开关/端点/密钥；局域网转发中继：监听地址、端口与独立中继密钥）），新增聚合渠道（提供商注册表、Key、测试、发现模型、Base URL 与模型清单覆盖）、省 Token（压缩开关、两族提示词档位、五个本地应答与节省统计）与路由（降级链编辑器）三页；网关设置页另增「接入客户端」分区。页面切换与卡片入场为 150–250 ms 短动效，prefers-reduced-motion 下整体关闭。每页都有直达 GitHub 仓库的 Star 按钮。
• 局域网转发中继——渠道网关本身只监听本机（上游的安全选择）；本插件提供自己的转发门：调用方用插件签发与轮换的中继密钥，转发跳由宿主换用网关凭据（凭据不出宿主进程），仅放行 /v1/* 模型接口并带环路保护。

你会看到什么

输入框的模型选择器

被判定为「已声明但不路由」的模型不出现在任何分组中——它们仅在设置页的「不在选择器中」分组保留记录， 附带拒因与探测时间；后续探测重新通过后自动回到选择器。

设置页 设置 → Our Free Model，包含七个分区：

• 模型清单——各模型的可用性、是否支持视觉、上下文窗口、最长输出、各思考档位实际下发的输出上限、实测首字延迟，以及单次调用基准测试按钮。
• EAC 渠道授权——一键发起 GitHub 登录（自动打开浏览器，无需复制粘贴）、显示登录名与 star 校验状态、重新检查、退出登录；未授权时模型卡带锁标记。免费车道的模型不受影响。
• 公告中心——仓库维护者推送的公告流：未读计数、紧急徽章、单条/全部标记已读、检查新公告按钮、系统通知开关。公告正文按白名单渲染 HTML。
• 用量看板——总览计数、17 周 Token 热力图、总量曲线（Token / 请求数切换，总计与单模型切换）、速度迷你图、按模型汇总表。
• 本地转发——开关、监听地址与端口、复制 base URL、显示 / 复制 / 轮换 API Key，并提供可直接执行的 curl 示例。
• 插件设置——总开关、是否展示地区受限模型、探测间隔、默认输出上限，以及当前探测到的出口 IP 与国家。
• 插件升级——当前/最新版本、检查更新、一键升级（含进度与失败原因）、最近一次升级历史、热重载按钮与文件监视开关。
• 首次启动公告——分 5 页（前言 / 模型清单 / 使用步骤 / 功能介绍 / 公告与升级），确认一次后不再弹出，除非文案版本号被提升。

独立本地服务（开发中）

仓库现在提供两个入口：下文安装的是 DSH 插件；packages/standalone 是 无需安装 DSH 的独立本地服务。从完整源码仓库运行：

npm run start:standalone

独立服务默认使用 ~/.our-free-model 和端口 18900，拥有自己的 API Key， 不读取插件数据。支持匿名/Kilo、EAC 和原有十三个账号渠道，提供 Chat Completions、Responses API，以及独立网页管理（模型、统计、渠道、EAC、设置、API Key）。 启动后打开终端打印的一次性管理链接即可使用；账号在独立页面登录，也可手动导入插件账号备份。 启动、参数与验证见 独立服务说明。 独立服务的安装制品与 Release 尚未发布。

安装

命令行（纯 dsh web）

dsh plugin --profile web add /绝对路径/dsh-our-free-model

安装完成后重启应用一次。--profile 填写实际使用的 profile 名称。

DSHEAC AIO / 桌面端：请先阅读本节

桌面端在启动 web 服务之前会执行一道 profile 闸门。其扫描器仅放行 dsh 自身在 .dsh-module-fallback 下生成的链接；profile 目录树中出现任何其它符号链接或目录 junction，应用将拒绝启动并报错：

PROFILE_UPGRADE_REQUIRED: offline dependency migration is not yet available

因此桌面端不要使用 link: 依赖安装，也不要创建 junction。请使用应用内的插件管理器， 或放置一个真实目录。

以真实目录手工安装时，在 /profiles// 下完成三项操作：

1. 将发布文件复制至 node_modules/dsh-our-free-model/ （index.js、client.js、adapter/、src/、locale/、icon.svg、cordis.patch.yml、package.json——adapter/ 不可遗漏：index.js 首行即 import 该目录）
2. 在 dependencies 中加入 "dsh-our-free-model": "2.1.0"——该版本号跟随仓库 package.json 的 version（版本变更时同步，当前为 2.1.0），不要沿用旧值，也不要写为 link:
3. 在 dsh.profile.bundles 末尾追加 "dsh-our-free-model"

不要再向 cordis.patch.yml 添加条目。被 dsh.profile.bundles 引用的包，其自带的 patch 层会自动生效；两处同时注册将报错 duplicate loader entry id: our-free-model。

整合包（托管安装）

插件由整合包（EAC 整合包、Mojobox 等）安装时，更新时机与文件字节由安装方控制： 安装时将 bundle config 设为 distribution: 'managed'（或向 settings.json 写入 同一字段），插件的应用内升级、公告 feed 与热重载即全部停用——两个写入方同时操作 同一安装目录只会导致目录损坏；模型 lane 不受影响。相关验收见 scripts/offline-test.mjs；目录就绪记录（manifest 0.15 / 出处 / 许可 / 完整性） 位于 catalog/ 下。

启动桌面端前的自检

可直接调用桌面端自身的闸门代码进行自检：

node -e "
const g = require('/sidecar/dist/lib/profile-upgrade.js');
const app = '', profile = '/profiles/';
console.log(g.planProfileUpgrade(app, profile));
g.assertProfileStartup(app, profile);
console.log('startup gate: PASS');
"

预期输出为 status: 'compatible'、mismatches 为空数组，随后输出 PASS。 若仅需确认 bundle 组合是否正确而不启动界面：

DSH_HOME= dsh --profile  --dump-config | grep our-free-model

应当只出现一个 id: our-free-model。

安装失败：ERR_PNPM_VIRTUAL_STORE_DIR_MAX_LENGTH_DIFF

该问题源于目标 profile 的 pnpm 状态，与插件仓库无关（报错发生在下载插件之前）：profile 中已有的 node_modules 由旧版 pnpm 生成，dsh 更新后内置的 pnpm 版本发生变化，pnpm 拒绝在旧参数上继续安装。 关闭 dsh，删除该 profile 的 node_modules 与 pnpm-lock.yaml 使其重建，然后重新安装：

rd /s /q "%DSH_HOME%\profiles\web\node_modules"
del "%DSH_HOME%\profiles\web\pnpm-lock.yaml"

同时出现的 Ignoring broken lockfile 警告会随重建一同消失。

安装失败：git ls-remote "git+ssh://git@github.com/..."（插件市场自动安装）

插件市场（dsh-plugin-hub）对 git 源的自动安装会把 GitHub 地址交给 pnpm 解析，pnpm 再调用本机 git 执行 git ls-remote。若本机 git 配置了 insteadOf 重写（常见于把 https 改写为 ssh 的 url."git+ssh://git@github.com/".insteadOf 规则），或 SSH 密钥未配置，这一步会在下载任何插件 文件之前失败。处理方式二选一：

• 修正本机 git 配置（git config --global --get-regexp insteadof 查看重写规则），保证终端里 git ls-remote https://github.com/Ebony-Vinyl/dsh-our-free-model.git 能成功；
• 改用本地安装：从 Releases 下载发布包解压后 dsh plugin add <解压目录>，绕开 git 解析。

安装失败：profile "desktop" is managed exclusively by the Electron application

这是宿主自身的保护，不是插件问题：桌面端（Electron）的 profile 只允许桌面应用自己管理， 命令行 dsh plugin add 无法写入。请在桌面端的插件管理器（设置 → 插件）里完成安装或升级； 命令行安装仅适用于纯 web profile（dsh web）。

使用说明

选择模型：打开输入框的模型选择器，选择 Our Free Model 分组下的任意模型。选择结果按会话持久化。

调整思考强度：同一菜单中的 Effort，共三档 Light / Balanced / Deep。档位越高，思考占用的 输出预算越多；上限为强制下发，因此档位之间存在可测量的差异。思考与可见回答共享同一输出额度， 因此思考不可关闭的模型会将三档整体上移（设置 → Our Free Model 的模型卡上标注了每档的 实际数值）。若回答被截断，可切换至 Deep，或调高设置中的单次输出上限。

供本机其它工具调用：设置 → Our Free Model → 本地转发，启用后复制 base URL 并生成 Key。支持：

• GET /v1/models
• POST /v1/chat/completions（流式与非流式）
• POST /v1/responses
• POST /v1/messages（流式与非流式，Anthropic Messages）
• POST /v1/messages/count_tokens（本地估算，插件不含 tokenizer）

端口被占用时插件不会静默失效：先在同一端口重试数轮（刚关闭的监听、刚删除的 portproxy 规则通常在数百毫秒内释放），仍被占用则顺延至下一个可用端口，并在设置页标注 "请求的 18899 不可用，实际监听 18900"，落盘的也是该实际端口。Windows 上最常见的占用 来源是一条 netsh interface portproxy 规则（由 IP Helper 服务承载）：其对 0.0.0.0 的 监听会导致回环绑定直接返回 EACCES（区别于 EADDRINUSE）。netsh interface portproxy show all 可列出规则，netsh interface portproxy reset 可清除规则。

转发端点为全流式：除 data: 帧外，思考期间的静默由周期性写出的 SSE 注释帧 （以 : 开头）填充，客户端的 idle 超时因此不会将"上游仍在推理"误判为"连接已断开"。思考内容按 reasoning、reasoning_content、reasoning_text 三个字段识别——同一段思考若被上游同时 写入两个字段只计一次——reasoning_details 数组同样识别。上游本身不流式输出思考的模型，此处 也不会产生思考帧，详见「已知边界」。

供同一网络中的其它设备使用：同一面板下方还提供"局域网访问"。该功能默认关闭；启用后中继绑定一个可路由地址（默认 0.0.0.0），并要求使用独立的局域网 Key——与上述本机 Key 互不通用，因此任一泄露只需轮换对应一侧，本机已配置的工具不受影响。中继将请求原样转发至本机监听，模型清单、流式行为与错误语义与本机完全一致。端口填 0 表示自动分配（本机 18899 常已被占用或被端口代理占用），启用后面板会显示实际端口与局域网地址。局域网地址按本机网卡实时读取：面板在开启期间每 15 秒重读一次，切换到别的网络后不必重开面板。同一台机器常同时持有多张网卡上的私网地址——路由器分配的 192.168.x.y，以及虚拟交换机（WSL/Hyper-V/Docker）、VPN 或隧道适配器上的地址——面板把物理网卡的地址排在前面并作为可直接复制的那一条，其余地址列在其下；中继绑定的是所有接口，但某个地址能否被同网段的另一台机器拨通，取决于该地址所属的那张网卡。启用期间，任何能够访问该主机的用户均可使用此 Key 消耗本机的免费额度，因此请仅在可信网络中启用，必要时通过防火墙限制来源网段。

重新核对地区：点击"重新探测可用性"，将按当前出口重新执行探测。切换 VPN 状态后再执行一次， 地区受限模型会在两个分组之间自动迁移。

接收公告：全自动。仓库维护者推送新公告后，运行中的插件在一个轮询周期内（默认 30 分钟，也可在公告中心点击"检查新公告"立即拉取）收到通知：普通公告弹出 toast， urgent 级别直接触发全屏弹窗，两者均会进入公告中心并保留未读标记。如需同时接收 系统级通知，在公告中心点击"开启系统通知"。

升级插件：设置 → Our Free Model → 插件升级 → 检查更新 → 立即升级。全流程 在应用内完成（下载 → 校验 → 备份 → 替换 → 热重载），无需重新安装，也无需 重启应用。升级失败会自动回滚至上一版本并给出失败原因。

Gemini 与 Cline 的代理连接

Gemini 登录需要访问 accounts.google.com、oauth2.googleapis.com、www.googleapis.com，模型请求还需访问 Google Code Assist 服务。浏览器能打开授权页，只说明浏览器的网络可用，插件仍需能访问这些端点。

Gemini 的登录、续期、项目探测和推理，以及 Cline 的登录、续期和推理，共用逐请求代理：优先使用已运行的插件出口代理，其次读取 HTTP_PROXY / HTTPS_PROXY / ALL_PROXY，最后在 Windows 读取当前用户的手动系统代理；没有代理时直连。环境代理遵守 NO_PROXY，系统代理遵守 ProxyOverride；回环请求不自动使用代理。无需为这两条渠道设置 NODE_USE_ENV_PROXY，也不会改动宿主的全局代理。

Windows 自动检测只支持手动代理，不执行 PAC 自动配置脚本；系统设置最多缓存 30 秒。仅配置 PAC 时，请改用插件出口或环境代理。网络失败会显示所选路径及 UND_ERR_CONNECT_TIMEOUT、ENOTFOUND 等底层错误码；代理连接失败不会自动重试直连。浏览器回调未到达的授权超时仍需检查本机回调地址和端口是否可达。

聚合渠道、省 Token、路由与本地网关

聚合渠道：自带 Key 的 76 家提供商

设置页的聚合渠道一页把第三方端点接进同一条模型清单。提供商注册表内置 76 家（src/providers/registry.json，分类为 free | free-tier | apikey | oauth | local），包括 NVIDIA NIM、OpenRouter、Groq、Cerebras、SambaNova、Gemini、DeepSeek、Mistral、Together、Fireworks、SiliconFlow、Nebius、Chutes、Hugging Face、Cloudflare、Z.ai、Kimi、MiniMax、QwenCloud/Alibaba、Bedrock、Vertex、Vercel AI Gateway、Azure OpenAI，以及本机、无需账号的 Ollama、LM Studio、llama.cpp。注册表数据来自 free-claude-code 的提供商目录与 9router 的提供商注册表。

写入 Key（本机免账号的提供商不需要）后，该提供商的每个模型以 provider/model 成为清单行：在选择器里可选，也可经本地网关调用。三种线协议按提供商各自声明：OpenAI Chat Completions、OpenAI Responses 与 Anthropic Messages（后两者用于只提供这两种协议的上游）。

Key 只写入插件自己的 0600 settings.json，接口永不回显——页面只显示 hasKey 与 …abcd 指纹；字段缺省表示保留已存 Key，空字符串表示清除。每家提供商提供：启用/停用、测试、发现模型、Base URL 覆盖（Azure / Cloudflare / Vertex 没有可用默认值，必须覆盖）、模型清单覆盖与移除。测试按钮是列表探测：它用提供商的模型列表验证 Key，不花一次生成；提供商声明没有列表接口时，按钮如实说明。OAuth 与 ADC（Google ADC）认证的提供商照常列出并标注「不可驱动」——本车道无法替它们完成交互式登录或云侧凭据流程。

省 Token：工具输出压缩、提示词瘦身与本地应答

工具输出压缩（RTK） 在请求发出之前就地重写 tool_result / role:"tool" 内容：git diff、git status、git log、grep、find、ls、tree、构建与包管理器日志、带行号的文件转储、Cursor 搜索清单，以及成串重复的日志行。实测：40 KB 的 git diff 移除 90% 的字节，模型仍就这份 diff 作出了回答。安全规则：报错的工具结果永不触碰，小于尺寸下限的内容不碰，替换结果永不大于原文，过滤器抛错时原样放行，且整条管线幂等。该压缩对全部车道生效（含本地网关），默认开启。

提示词瘦身 有两族可选项与档位：caveman（电报体回复：off/lite/full/ultra/wenyan-lite/wenyan/wenyan-ultra）与 ponytail（YAGNI 最小实现：off/lite/full/ultra）。它们改变助手的说话方式，因此所有档位默认 off。注入是幂等的、按线协议进行的（chat 的 system 消息、Anthropic 的 system（含块数组形式，且插在最后一个 cache_control 之前）、Responses 的 instructions/input 项），并且可以撤销。

节省统计 显示压缩前字节 → 压缩后字节、节省字节、节省比例、压缩块数与统计调用数——数据取自用量图表所用的同一批统计行。

五个本地应答（自 free-claude-code 移植，各自独立开关，默认全开）不调用任何提供商：额度探测（max_tokens:1 + "quota" → Quota check passed.）、shell 命令前缀识别（<policy_spec> + Command: → 前缀，检测到命令注入时拒绝）、会话标题生成（→ Conversation）、建议模式（→ 空字符串）与文件路径提取（→ <filepaths> 块）。它们由本地网关在进程内直接应答。

路由：命名降级链（combo）

一条命名、有序的模型 id 列表，跨全部车道，以 combo:<name> 出现在选择器与网关上，如同一个虚拟模型。两种策略：fallback（固定从链首开始）与 round-robin（轮换起点，连续 N 轮粘滞）。链会逐个链接尝试直到有一个产出输出；在任何正文增量之前失败的链接被整段丢弃，因此切换对调用方不可见。思考增量刻意不算正文——「想了一分钟，然后撞上配额墙」正是最值得降级的场景。一旦已有正文增量交付，之后的失败按正常方式结束该回合（单模型检查点恢复仍先获得它的续写尝试）。链路容量取交集（只有每个链接都支持视觉，链才声明视觉；上下文窗口取最小值），全部链接当前不可用的链会被原样保存并标注为不可用，而不是被静默丢弃。

本地网关：原生 Anthropic 接口与接入配方

新增端点 POST /v1/messages（流式与非流式，message_start / content_block_* / message_delta / message_stop 正确成帧，含 thinking 块、tool_use 块、真实 stop_reason，以及响应头发出之后才失败时的流内 error 事件）与 POST /v1/messages/count_tokens（本地估算——插件不含 tokenizer）。Claude Code 与 Anthropic 各 SDK 因此可以直接指向本插件。原有的 /v1/chat/completions 与 /v1/responses 不变，/v1/models 现在广播全部车道，含聚合行与链路。网关页新增「接入客户端」分区，按实际绑定的端口与真实要求的密钥生成可复制的配方：Claude Code 环境变量、Codex config.toml、OpenAI SDK、Anthropic SDK、curl，以及中继开启时的局域网版本。

顺带修掉一个假成功：一轮只产出了一个调用方从未声明的工具调用时，过去会以干净的空成功收尾；现在会如实报告发生了什么——压缩器自己追加的 [full diff: rtk git diff --no-compact] 提示就可能让模型去调一个调用方没有的工具。

实现结构

index.js Host 半身：适配器注册、清单与可用性探测、设置/用量存储、
 webServer 路由、转发端口生命周期、公告/升级/热重载接线
adapter/ 内核接缝：全包唯一允许 import @deepseek-ai/* 的位置
 （kernel.js：attribution User-Agent，失败降级为字面量）
src/adapter.js 结构性 LlmAdapter：providerInfo、listModels、resolveModel、
 prepareCall、stream、providerRetryPolicy
src/upstream.js 网关身份：凭据、session/request id 铸造、工具指纹、按线协议选端点
src/stream.js 三种线协议解码（chat / messages / responses）归一为 harness StreamChunk，
 并做不相交的 token 计数
src/messages.js harness 消息 -> 各线协议形态，外加工具调用配对修复
src/effort.js 思考档位 -> 输出预算
src/forward.js 独立的 OpenAI 兼容监听器（另含 Anthropic Messages 端点）
src/providers/registry.json 聚合车道注册表：76 家提供商的分类、认证、线协议与端点
src/providers/index.js 注册表读取与 provider/model 复合 id 解析
src/aggregate.js 聚合车道：清单行、凭据解析、Key 脱敏、列表探测、按线协议发送
src/anthropic.js /v1/messages 的 Anthropic Messages 编解码与本地 token 估算
src/token-saver/index.js 压缩管线：提示词注入 -> 工具输出压缩，按字节留痕、失败开放
src/token-saver/inject.js chat / messages / responses 三线的幂等注入与撤销
src/token-saver/prompts.js caveman / ponytail 两族提示词与档位
src/token-saver/rtk/ 工具输出过滤器：git diff/status/log、grep、find、ls、tree、
 构建日志、编号转储、搜索清单、重复日志行
src/local-optimize.js 五个本地应答：额度探测、命令前缀、会话标题、建议模式、文件路径
src/combos.js 降级链：虚拟清单行、两种策略、容量取交集
src/route/classify.js 全车道统一的失败词汇与冷却策略
src/trust.js 插件路由的请求信任围栏（connection 服务桥 + 结构化围栏）
src/push.js SSE 推送枢纽：公告到达、更新可用、升级完成
src/feed.js 远程公告 feed：多源拉取、校验、缓存、到达检测
src/updater.js 应用内升级：清单校验、SHA-256 分级校验、备份、原子替换、回滚
src/reload.js 自热重载：镜像内核 HMR 的缓存清除 + 重导入 + 重注册 + 回滚序列
client.js 浏览器半身：手写 ModuleLoader bundle，无构建步骤

几个值得了解的架构决定：

一个适配器，两条 provider 路由。 harness 的模型选择器严格按 provider 路由分组， 而清单的线格式中并不存在 group / tag / badge 字段。因此要呈现独立的 region-limited 标题，唯一方式是再注册一条路由；又由于客户端会丢弃空分组，一旦地区限制解除， 两个分组会自动合并为一个。

以结构化方式实现适配器，不 import @deepseek-ai/dsh-llm。 内核从不执行 instanceof 检查，因此鸭子类型即可满足。这使插件不必将依赖固定在特定内核版本上，也是同一份代码能同时 运行于 0.1.5 与 0.1.7 的原因。

使用自有 JSON 存储，不接入 settings seam。 settings 注册 API 在两版内核间不一致； 私有 JSON 存储行为一致，且转发 Key 存放于 0600 权限文件中，不进入任何共享设置文档。

Token 压缩跑在唯一收口上，且失败开放。 提示词注入与工具输出压缩在 payload 完成全部 改写之后执行——指纹改名、档位补丁、密封车道的节奏提示都已落定——收口在 payloadFor()： 适配器自己的派发与本地网关（它同样经适配器发起）都从这唯一一处经过，因此每条车道、每一段 恢复请求都同样压缩。每一步都失败开放：压缩器抛错就跳过，过滤器抛错就原样放行，形态不认识 就不动——一个请求绝不能因为一个「本来是为了让它更便宜」的环节而失败。

combo 是一条虚拟清单行，降级在适配器里解析。 链路以 channel:'combo' 加一串真实模型 id 并入合并后的清单，因此选择器照常广播它、本地网关照常按名调用它；链的展开与推进判定发生 在适配器的 runStream() 内，于是两个调用方都不必知道降级这件事。

为什么用预算，而不是 reasoning_effort

实测结论：在该车道上向上游传递 reasoning-effort 字符串为无效操作——对三个不同名义档位 反复采样，思考 token 数量在统计上无法区分。提供一个无效控件比不提供更糟， 因此思考强度实现为硬性输出 token 上限，该上限确实产生约束：留痕的思考 token 随档位单调上升。

三个实际消耗过调试时间的内核行为

此处列出是因为编写 provider 插件时通常会遇到：

providerRetryPolicy() 会被原样保存并使用。 两版内核均不解析其返回值，而退避调度器读取的是 顶层的 initialDelayMs / maxDelayMs / jitterRatio。将这三项嵌套在 backoff:{} 中， 调度器读到 undefined，于是 undefined * 2ⁿ = NaN，而持久会话日志会直接拒绝非有限数值—— 一个本可恢复的瞬时故障因此导致整轮对话报废。应返回已解析完毕的扁平策略。

一次被中断的工具调用会永久污染该会话。 缺少对应结果的工具调用在重放时，上游返回 400 invalid_request_error，此后该会话中的每一次请求都会失败。本插件在发送前修复配对， 三种线协议共用同一处修复逻辑。

未在 inject 中声明的服务，属性直读会抛错（与返回 undefined 不同）；而 ctx.get() 在服务 "尚未被 provide 出来"时返回 undefined。 这两条本轮各自触发过一次问题：将 inject 缩减为仅剩 llm 之后，typeof ctx.interval === 'function' 直接抛出 cannot get property "timer" without inject（ctx.interval 是 timer 服务上的 mixin），插件在所有 composition 中 均不再激活；改用 ctx.get('webServer') 后返回 undefined——原因不在于缺少 web server，而在于插件先于 web 半身加载——导致设置页路由全部未注册。正确做法是 ctx.inject(deps, callback)：为所需服务开启一条独立的 fiber 使其待命， 避免在加载瞬间做一次性判断。

为什么按 body 的形状而不是 Content-Type 读响应

该车道会在高负载下以 200 + application/json 返回完整的 SSE 帧序列。旧实现依赖 header， 于是 await response.text() 将整条流读成字符串、JSON.parse 失败、整轮报废——而该 错误对象携带 status: 200，还会使可用性探测将完全可用的模型判为"不可路由"， 使其在下拉框中消失一轮。当前实现先嗅探首块（≤4 KB）按形状分流，再将已读取的字节 重新注入流中，实时性不受影响；src/http.js 的 sniffBody 为唯一判据。

为什么速度那一栏会显示 —

早期版本曾为一条实际仅 ~40 tok/s 的车道报告出 2 941 tok/s。问题不在网关——直连 读包的探针显示 64 个帧跨越 5.6 秒，确为增量投递——而在于分子与分母度量的不是同一段 时间：一次调用计费 422 个输出 token，其中 291 个是未流出任何帧的 reasoning token， 它们在第一个可见 token 之前即已生成完毕，而窗口起点正是该 token。以整段 以整段 completion 耗时除以答案文本落地所用秒数，无法反映解码速度。

因此当前实现仅在"能够容纳分子的那段时间"内输出速率：windowTokens() 将未流出的 reasoning token 从分子中剔除，decodeWindow() 拒绝过短以至于无法计时的窗口以及不真实的 高速率，看板与模型表均改为 Σtoken / Σ秒，不再对各次速率取平均——曾有一个 1 ms 的窗口将 26 次调用的均值抬高了三个数量级。因此答案集中在一两个大帧中落地的模型， 不具备可测量的输出速度，该栏显示 —。

长思考截断后的自动恢复（issue #12）

所有模型默认启用一次有界恢复，Chat Completions、Messages、Responses 三种上游协议 共用该行为。触发条件为：首段仅有非空思考、无正文且无工具调用，且上游在未发送正常 结束帧的情况下直接关闭流；或上游发送了正常 stop 收尾、但同样只有思考而无正文——宿主会将 此类「空停」回合判定为空响应，恢复流程会继续请求一次正文。以下情况不触发恢复：用户取消、 已输出正文或工具调用的正常结束、达到输出上限、明确的上游错误。

插件将已收到的思考作为检查点文本，与原始输入一起发起新请求，要求直接输出整理后的回答。 该机制基于检查点重新发起请求，与上游原生 resume 无关，也不会重放已显示的思考内容。恢复段禁用工具调用；已输出 正文或已开始调用工具的截断回合不执行恢复，以避免内容重复或工具重复执行。

为避免重复长思考，恢复提示要求结论优先、最多 800 词；此为提示层面的约束（非硬性 token 限制），模型可能不遵守。恢复属于降级回答，原始请求中的长篇或逐步分析可能被简化。

每个逻辑回合最多两次物理请求：原始请求加一次恢复。默认总时限 900 秒（15 分钟），恢复段最多 300 秒，且受剩余总时长约束；恢复输出上限 8192 tokens，并继续受用户与模型的上限 约束。首段已知的输出 tokens 会从原始预算中扣除，恢复预算不足 512 tokens 时不发起恢复。 检查点最多 131072 字符，且必须通过基于文本字节的保守上下文余量估算；该估算不计算图片 token，不等同于精确的 tokenizer 校验。超出限制即停止恢复，不会无限续接。恢复必须正常结束且 产生非空白正文方为成功；失败返回 STREAM_CUT，宿主不会将该回合整轮重发，用户取消 则保持 aborted / ABORTED。

可通过本机 settings.json 的 streamRecovery: false 关闭恢复；也可通过对象的 enabled 开关及数值限制收窄边界，数值只能低于或等于默认上限。默认不限制模型名单。

用量看板将物理请求与逻辑回合分开统计。上游请求数与请求失败数按实际发出的请求次数计数； 对话回合数、回合失败数与已恢复数按一次适配器调用的最终结果计数。例如首段中断、 续写成功会记为 2 次上游请求、1 次请求失败，同时记为 1 个对话回合、0 次回合失败、 1 次已恢复。每段样本仍包含恢复关联、段序号与 noUsage 等标记；通过 recoveryId 关联各段的 noUsage 以判断缺失情况。最终上报宿主的 usage 仅汇总上游实际报告的已知值； 缺少某段 usage 时，该值不等于整轮完整 token 总量。思考检查点不写入统计文件。

升级前的旧统计仅包含物理请求记录，迁移后展示的回合数与失败数为基于这些记录的推算值， 看板会明确标注；升级后的回合按最终结果精确记录。 请求数、回合数与 Token 总量为累计值；速度、首帧延迟与热力图使用本机保留的历史窗口。

已在一次真实 MiMo V2.6 Flash · Deep 请求中恢复成功；此前一次恢复曾在 480 秒 截止时失败。这不代表全部模型均已实测，也不保证每个长思考回合都能生成答案。 下一节列出的 v1.3.1 记录描述的是恢复功能引入前的行为。

验收情况

在 Windows 环境下针对真实上游实测。本节按轮次记录，并注明每项的验证方式——仅标注 「真实上游」与「实机点击」的条目才对应用户在界面上可见的行为。

Issue #12：验收状态

恢复实现、离线回归与真实上游结果单独记录在 docs/issue-12-recovery.md。合并前 review 修复了一处告警 重复累积的缺陷并补充回归用例，recovery 99/99、truncation 35/35、fingerprint 新增 11 项与 typecheck 均已通过；其中 12 项使用真实插件与本地 HTTP 验证转发成功、失败、客户端断开与统计落盘。最终全量结果以技术文档为准。 真实 MiMo Deep 首段在 304.161 秒自然 EOF， 恢复段 32.777 秒生成 4264 字符正文，以 stop / usage / [DONE] 正常结束；共两次 请求、336.942 秒。首段无 usage，汇总值仅为已知用量。首次 480 秒恢复失败记录 保留在技术文档中；真实 dsh UI 与其它模型尚未逐一验收。

历史：v1.3.2（对应 issue #11、#13、#19、#20、#21）

全部 20 个离线套件（含新增 forward-test）与 tsc --noEmit 通过；host-selftest 需真实出网并消耗免费额度，未随本轮运行。

历史：v1.3.1（对应 issue #8、#9、#10）

前往 GitHub