星桥免费模型预设 SZYTree0312/dsh-opencode-free

星桥模式（opencode-free）

挂在 DeepSeek Harness（dsh）上的 agent preset，为 OpenCode 的免费模型这条路线做前缀稳定与载荷控制。
不是独立运行时、不是 fork。

前置依赖：社区插件 dsh-opencode-xdbridge （XDTrees）。它把 OpenCode 的免费模型通过隔离的 opencode 运行时接进 dsh，注册成 provider opencode-xdbridge。本 preset 只做 agent 侧的行为策略，不替代那个插件。

上游基线：0.2.0-rc.2（必须 pin，上游明示会有破坏性变更）。

名字从「星」与「桥」：星是那批免费模型（space-bunny、big-pickle…），桥是 xdbridge 这座桥。

如果安装，一定要仔细阅读README的安装部分，或者是交给任意Agent

最重要的一件事：这条路线不省钱

dsh-opencode-xdbridge 在 adapter.js 里硬编码：

/** These models are free, so per-token pricing is zero by definition. /
const NO_COST = { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }

插件也只在运行时上报的每一个计费维度都为 0 时才把模型列出来。

所以「省 token」在这里不是目标。 真正的硬约束是三个：

| 约束 | 表现 | preset 怎么应对 |
| 免费额度的速率限制 | 请求数是最直接的消耗 | 推动并行调用、少绕弯、压缩尽量不触发（一次摘要 = 一次额外请求）|
| 每轮延迟 | 四层转发，且整段对话每轮重发 | 控制载荷增长，保住缓存前缀 |
| shim 的 8 MB 请求体上限 | 超了是失败，不是变慢 | 收紧 tool-fs 读上限、收紧裁剪阈值、长输出重定向到文件 |

一句话原理

这条路线每回合新建一个上游会话（backend.js 里 POST /session），服务端不保留任何状态 —— 整段对话每回合都要重新发一次。

于是：

1. 载荷随历史线性增长，请求体大小由会话长度决定，而不是单轮输入。
2. 前缀匹配是唯一的省算力途径，而且它确实存在（bridge 会把 cached_tokens 回传成 prompt_tokens_details.cached_tokens）。
3. 收益落在延迟与额度上，不是钱。

工具目录为什么必须全程固定

百炼成金模式里，这条规则来自上游 plan-mode 提示词里的一句话。
在这里它是可以读出来的字符串拼接 —— protocol.js 组装 system 时：

Available external tools: ${JSON.stringify(choice === 'none' ? [] : tools.map(t => t.function))}

工具集合或顺序一变，system 就变，缓存前缀当场失效。
所以 tool-plugin-manager 必须保持 disabled —— 它是唯一能中途增删工具的组件。

同一段代码还意味着：tool_choice 与 parallel_tool_calls 也会改变 system 的末尾几行，所以应当避免那些会让它们逐轮翻转的模式。

完整证据见 docs/how-the-bridge-shapes-the-request.md。

与百炼成金模式的差异

两者形态相同（一个 @deepseek-ai/dsh-agent-preset 声明），但目标函数不同，所以同一批旋钮拧的方向也不同：

| 旋钮 | 百炼成金（省钱）| 星桥（省额度/延迟/载荷）| 为什么反着来 |
| agent-instructions.maxBytes | 131072（比上游 65536 加倍）| 32768（比上游减半）| 那边常驻内容吃缓存价，便宜；这里每字节都在每轮重发的数据块里 |
| tool-result-pruner | 8192/4096/1024（上游默认）| 4096/2048/512 | 这里多一条硬闸：8 MB 请求体上限 |
| compaction.headroomTokens | 不动（65536）| 32768 | 免费模型窗口常只有 128K，65536 的余量会把触发点压到 30464 |
| summarizationModel | 钉 qwen3.8-flash | 留空 | 免费名单随时轮换，钉死 id 会在模型撤下那天让压缩失败 |
| modelPolicies | 按模型覆盖 | 留空 | 同上，按 id 精确覆盖是定时炸弹 |
| tool-fs 读上限 | 不设 | 收紧到 800 行 / 1000 字符 / 24 KiB | 这里载荷是真金白银的约束 |

相同的是三条核心纪律：工具目录全程固定、历史只追加、动态状态推尾部。

目录

presets/opencode-free.patch.yml preset 定义，主产物 docs/how-the-bridge-shapes-the-request.md 源码级证据：桥怎么组装请求

接入

本 preset 不含 xdbridge，也不会替你装它

两个包是分开的，各有各的作者：

| 部分 | 层级 | 作者 | 管什么 |
| dsh-opencode-xdbridge | Host（provider）| XDTrees | provider 注册、模型目录、隔离运行时、8 MB 上限 |
| 本 preset（dsh-opencode-free）| Agent | 本仓库 | 工具面、提示词、压缩策略、载荷控制 |

为什么不打包进去：

1. 不替别人分发代码。 那是 XDTrees 的项目，MIT 也不该由我这边再发一份。
2. 打包就等于钉死版本。 桥接插件依赖 OpenCode 的客户端接口（不是官方开放 API），OpenCode 一更新它就可能要跟着改。装成独立插件，更新由上游直接推给你；打进本仓库，就得等我发新版 —— 那才是真的跟不上。

3. 写进 patch 会出事。 在 presets/opencode-free.patch.yml 里加一行 - id: llm-opencode-xdbridge 去注册 provider，等于引用一个可能没安装的包，加载期直接失败，可能连累整个 profile。别这么干。

反过来也是安全的： 本 preset 的 YAML 里没有一行引用 opencode-xdbridge（全文件搜 opencode 只出现在注释、preset id 和描述里，插件 name: 全是 @deepseek-ai/）。所以：

- 没装桥接插件也能装本 preset —— 只是选不到那些模型，不会报错、不会拖垮 profile。
- 本 preset 的调参思路（载荷要小、前缀要稳、压缩要晚）对任何「按上下文线性付费、且每轮重发整段对话」的路线都成立，换 provider 也能用，只是数值要重新看。

⚠️ 本 preset 的结论会随桥的实现变化

上面每一条非常规设定都对应 dsh-opencode-xdbridge v0.1.0 源码里的具体一行（见 docs/how-the-bridge-shapes-the-request.md）。如果上游改了任意一处，对应的设定就该重新看：

| 若上游改了 | 需要复查 |
| protocol.js 的 system 组装（尤其工具目录那段）| 「工具目录必须固定」这条还在不在 |
| backend.js 的会话策略（不再每回合新建）| 载荷是否还线性增长、8 MB 上限还构不构成威胁 |
| adapter.js 的 NO_COST / 窗口上报 | 压缩参数与 modelPolicies 留空的理由 |
| shim 的请求体上限 | tool-fs 读上限与裁剪阈值的激进程度 |

安装

先装插件（上游的）：

dsh plugin --profile web add github:XDTrees/dsh-opencode-xdbridge

再装本 preset：

dsh plugin --profile web add github:SZYTree0312/dsh-opencode-free

装完后在会话预设选择器里选 星桥模式。卸载：

dsh plugin --profile web remove dsh-opencode-free

插件的 peer 范围写的是 dsh >=0.1.1-rc.1 <0.2.0，而本 preset 按 0.2.0-rc.2 的 preset 机制写。本机两者并存且可用，但那是 peer 声明没跟上，升级后留意。

撞限流时的调整顺序

从最有效到最伤能力：

1. 关网页抓取：tool-web 的 fetch: false（搜索保留）
2. 关子代理与 workflow：tool-subagent / tool-subagent-fork / workflow-ptc / tool-workflow 置 disabled: true —— 它们成倍增加请求数
3. 再压 tool-fs 的读上限（500 行 / 800 字符 / 16 KiB）
4. 降推理档位：profile 里 agent-default-model.reasoningEffort 从 max 往下调 —— 推理 token 是按输出算的，max 意味着最多

readLimit 这类上限收得太狠会逼模型分块重读，反而多花回合。先跑几次真实会话看会不会明显多出重读，再决定。

状态

- [x] 源码级验证：桥的请求装配方式、缓存回传、每回合新建会话、8 MB 上限（见 docs/how-the-bridge-shapes-the-request.md）
- [x] preset 第一版
- [ ] 实机验证：装进 profile 跑一次完整会话 —— 命中率、载荷增长曲线、8 MB 上限在多久的会话后构成威胁，都还没有数字
- [ ] 各免费模型的实际窗口/输出上限核对（目录每次启动重读，随时可能变）

尚未实机验证。 本 preset 的结论全部来自读 dsh-opencode-xdbridge 的源码与 README，与百炼那边的「实测」性质不同。装进 profile 跑几次再回来补数字。