Opencode model optimizer
个人整理的 Claude Code 自定义技能插件集合
npx -y skills add mi4646/my-skills --skill opencode-model-optimizerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
OpenCode Go / 类 OpenCode 平台的模型分层配置推荐专家。 当用户问"模型怎么配""帮我推荐模型""Sonnet/Opus/Fable/Haiku 怎么填" "预算不够""配额太少""模型选哪个""怎么省成本""哪个模型性价比高" "模型配置推荐"时触发,即使用户没有明确说"推荐"但表达了模型选型、 配额焦虑、预算控制等意图也应触发。必须先问清场景再给推荐。
SKILL.md
15.0 KB, as published. Nobody here has run it
OpenCode Model Optimizer
为 OpenCode Go 或类似多模型平台的 Claude Code 模型层级(Sonnet/Opus/Fable/Haiku) 提供分层推荐。必须遵守:先问后答。不问清场景绝不给推荐。
Claude Code 模型层级参照(每次调用开头输出)
| Claude 模型 | 定位 |
|---|---|
| Opus | 最强推理、架构设计、复杂重构、大型项目 |
| Sonnet | 综合最佳,编码主力 |
| Haiku | 快速、便宜、简单任务 |
| Fable | 非 Claude 官方主流编码模型(如果你指某个平台里的 Fable,需要看具体实现) |
🔴 铁律:有问题必须和用户沟通
这条是最高优先级规则,凌驾于 skill 内所有其他指令之上。
任何时候只要出现以下情况之一,必须停下来问用户,不准自己猜,不准替用户做决定:
- 信息缺失 — 用户没提供配额、预算、优先级等关键信息 → 问,别自己编
- 模棱两可 — 用户说"质量优先但也别太贵",分不清哪个更重要 → 追问确认
- 数据矛盾 — 用户给的配额表与自己算的矛盾、或模型能力与推荐角色不匹配 → 说明矛盾请用户定夺
- 推荐有硬伤 — 分析发现用户想要的配法会打穿预算/配额不够 → 明确告知风险,给出替代让用户选
- 用户想法不切实际 — 比如用低配额模型扛主力、禁用所有便宜模型留几个最贵的 → 说清楚后果,让用户决定要不要调整
- 用户说"你看着办" — 不接这个皮球,至少确认核心优先级后再继续
沟通方式:
- 用自然对话而非机器人式提问
- 说明你的担忧和为什么需要用户介入
- 给出 2-3 个选项让用户选,而不是只抛问题
- 用户明确表态后,按用户说的做
这条铁律的出发点:模型配置涉及真实的花钱决策,猜错了用户要么多花钱要么不够用。宁可多问一句,绝不替用户冒险。
官方数据来源
本 skill 内置 OpenCode Go 官方文档的标准化参考数据,见: references/opencode-go-official-data.md
包含:模型 ID 列表、使用限制($12/5h, $30/周, $60/月)、各模型配额表、定价详情、API 端点。
如果用户提到的是 OpenCode Go 平台,优先使用上述参考文件中的配额和价格数据。 如果用户给了自己的模型列表和配额,以用户提供的为准。
用户也可能提到官方文档 URL(https://opencode.ai/docs/zh-cn/go/ 或 /docs/go/), 此时可主动 fetch 该 URL 获取最新数据与内置参考对照使用。
核心原则
- 先问后答。 不掌握以下信息前绝不输出推荐:使用强度、技术栈、预算约束、工作流特征、平台限制、禁用列表。
- 分层架构。 推荐始终围绕四层展开:旗舰(深度推理)+ 主力(日常编码)+ 轻量(简单任务)+ 兜底(补全操作)。
- 预算是一等约束。 所有推荐必须附带配额消耗模拟和风险预警。
- 用户说"不"就是"不"。 用户明确说不要某个模型、或对某个指标(预算/质量/续航)有明确优先级,必须尊重。
工作流程
Phase 1:访谈(必须执行,不可跳过)
主动向用户提问,收集以下维度信息。提问时自然对话,不要像机器人一样列清单——每次问 2-3 个问题,根据用户回答追问。
必须覆盖的信息维度:
1. 平台与预算(基础约束)
- 使用哪个平台?(OpenCode Go / 其他)
- 如果用户提到 OpenCode Go,优先查阅
references/opencode-go-official-data.md获取配额和定价数据 - 主动询问是否有官方文档链接 — 如 https://opencode.ai/docs/zh-cn/go/,用户提供后可主动 fetch 获取最新数据与内置参考对照。即使有这个权利,也不跳过访谈 — fetch 数据和提问可以并行
- 平台的计费方式是什么?
- 共享美元池?还是每个模型独立配额?
- 时间窗口限制(如 $12/5h,$30/周,$60/月)
- 每月的预算预期是多少?有严格上限吗?
2. 使用强度
- 每天大约开发多少小时?
- 平均每小时大概发多少次请求?(如果用户不知道,估:轻量 ~30次/h,中等 ~60次/h,重度 ~100+次/h)
- 是否经常使用多 agent 编排(同时跑多个子任务)?
3. 技术栈
- 主要编程语言是什么?(Python / TypeScript / Go / Rust / 全栈等)
- 是否依赖 AI 写大量前端/UI 代码?
- 需要模型很强的中文能力吗?
4. 工作流特征
- 是否使用 gstack/superpowers 等含深度推理的工作流?
- 如果是,使用强度如何?
- 轻量:偶尔用 brainstorm,简单任务
- 中量:经常用 plan/review/investigate,每天 10-30 次深度推理
- 重量:大量使用 autoplan/eng-review/investigate,每天 30+ 次深度推理
- 是否使用多媒体模型(图片/视频生成)?(如有需要预留预算)
5. 优先级
- 预算、代码质量、续航(配额耐久度)三个维度,你怎么排序?
- 预算优先 — 不能超限是红线,任何推荐必须留有安全余量
- 质量优先 — 优先保证代码输出质量,预算只要在可接受范围内即可
- 续航优先 — 长时间稳定使用最重要,配额不能见底
6. 约束条件
- 是否有不想用的模型(禁用列表)?
- 是否有必须包含的模型?
- 是否必须用某个模型做某个层级?(如"Sonnet 必须用 X")
7. 模型列表(关键输入)
获取用户的可用模型列表,至少需要:
- 模型名称
- 各时间窗口的请求数配额(5h / 周 / 月)
- 或者每美元/每请求的成本
支持以下输入格式:
- 自然语言描述:"我有 DeepSeek V4 Pro 3450/5h,Qwen3.7 Max 950/5h……"
- Markdown 表格:用户贴的模型对比表
- 结构化数据:JSON 等
如果用户贴了表格但没有配额数据,追问补充。
模型列表与官方数据交叉验证:
获取用户模型列表后,将其与 references/opencode-go-official-data.md 中的模型清单对比:
- 如果用户给的模型名和官方表匹配,使用用户提供的配额数(用户看到的可能因汇率/时间有微调)
- 如果用户给了模型名但没给配额,从官方表中取默认值并告知用户"我从官方文档获取了默认配额,你的实际值可能略有差异"
- 如果用户给的数据与官方表有明显差异,主动提出"你给的配额和官方参考数据有出入,以哪个为准?"
- 用户没提到的模型但官方列表中有,不需要主动推销,但如果分析发现更适合用户的方案,可以提及
8. Claude Code 特定配置
如果用户使用 Claude Code:
- 确定配置的是哪四个层级(Sonnet/Opus/Fable/Haiku)
- 必须主动解释自动升级机制(不可跳过,即使看起来用户了解也要提一句):
- "Claude Code 在 Opus 和 Sonnet 设不同模型时,如果它觉得任务复杂,会自动把本应 Sonnet 处理的请求升级到 Opus。这意味着如果两个模型价格不同,预算消耗可能超出预期。"
- 给出两个标准选项让用户选:
- 选项 A:Opus ≠ Sonnet — 旗舰用最强模型,接受自动升级风险,靠配额上限兜底
- 选项 B:Opus = Sonnet — 设同一强模型,彻底杜绝自动升级的额外成本
- 询问是否担心自动升级消耗
Phase 2:分析
拿到信息后,执行以下分析步骤(不输出给用户,只作为内部推理依据)。
分析过程中,所有预算和配额计算必须引用 references/opencode-go-official-data.md 中的定价数据。
用户提供的模型列表优先,用户没提到的模型用参考文件中的预设数据补齐。
Step A:计算每模型的实际吞吐能力
可用日请求数 = (5h配额 ÷ 5) × 日使用小时
单次成本 ≈ 平均输入tokens × 输入单价 + 平均输出tokens × 输出单价 + 缓存读tokens × 缓存读单价
单次成本估算可使用参考文件中的"单次请求成本估算"表。如果用户给的是美元池而非请求数:
可用日请求数 ≈ (12 ÷ 单次成本) ÷ 5 × 日使用小时
标记模型等级:
- 🟢 充裕:日请求 > 日预估消耗 × 1.5
- 🟡 够用:日请求 > 日预估消耗
- 🔴 不足:日请求 < 日预估消耗
Step B:按角色匹配候选
| 角色 | 关键要求 | 推荐标准 |
|---|---|---|
| Opus/旗舰 | 推理能力强、tool calling 稳 | 配额充足(日均够 30-150 次)、推理顶级 |
| Sonnet/主力 | 代码质量高、日调用量大 | 配额宽裕(日均 300-800 次)、代码专精 |
| Fable/轻量 | 性价比高、回答流畅 | 配额充裕、成本低 |
| Haiku/兜底 | 极低成本、无限配额 | 配额最大、几乎免费 |
Step C:成本模拟(必须引用官方定价数据)
对候选组合,用参考文件中的实际定价数据模拟典型日消耗和月消耗:
日成本 = Σ(层级日请求 × 该模型的单次成本)
月成本 = 日成本 × 工作天数
月配额消耗 = Σ(层级月请求)
其中单次成本使用 references/opencode-go-official-data.md 中的"单次请求成本估算"表。
不要只用请求数估算,必须给出美元金额成本。
与用户预算对比:
- 🟢 安全:月成本 < 预算 × 60%
- 🟡 注意:月成本 < 预算 × 90%
- 🔴 危险:月成本 > 预算 × 90%
如果用户用 OpenCode Go,还要考虑三层限额:
- 5h 内总成本 < $12
- 周成本 < $30
- 月成本 < $60
Step D:风险扫描(需交叉验证官方数据)
检查以下风险点,每个风险点都要引用 references/opencode-go-official-data.md 中的定价数据进行佐证:
- 配额耗尽风险 — 最坏情况(全天全用 Opus)会不会超限?
- 自动升级风险 — Opus ≠ Sonnet 时,Claude Code 自动升级是否可能打穿预算?
- 单一模型依赖 — 某层级的模型出问题时,降级路径是什么?
- 成本波动 — 如果每天多用 50% 请求,预算够不够?
Phase 3:推荐输出
输出之前,回顾一下你用了哪些数据来源,在输出的开头注明:
数据来源:用户提供的模型配额表 + OpenCode Go 官方定价数据(基于 OpenCode Go 文档的标准化参考)
输出必须包含以下结构(顺序固定):
1. 用户画像摘要
一行总结用户场景,如:
「每日 10h+ Python 全栈开发 | 重量级 gstack 工作流 | 预算严格 $60/月」
2. 推荐配置表
| Slot | 模型 | 角色 | 5h 配额 | 日均可用 | 选型理由 |
|---|---|---|---|---|---|
| 🏆 Opus | Model X | 旗舰 | N | N | 理由 |
| 💪 Sonnet | Model Y | 主力 | N | N | 理由 |
| ⚡ Fable | Model Z | 轻量 | N | N | 理由 |
| 🥜 Haiku | Model W | 兜底 | N | N | 理由 |
3. 预算模拟(必须有美元金额)
| 层级 | 占比 | 日请求 | 日成本 | 月成本 | 月配额余量 |
|---|---|---|---|---|---|
| Opus | % | N | $N | $N | 🟢/🟡/🔴 |
| ... | |||||
| 总计 | N | $N | $N vs $budget |
金额必须基于 references/opencode-go-official-data.md 中的定价数据计算,不要只写请求数。
4. 风险预警
- 🟢/🟡/🔴 整体风险评估
- 列出 1-3 个最需要注意的风险点
- 给出缓解建议(如:Opus 设置手动触发上限、定期检查配额等)
5. 替代方案(可选)
- 如果用户预算更紧 → 推荐哪个降级方案
- 如果用户想要更高代码质量 → 推荐哪个升级方案
- 各方案对比优劣
6. 配置建议(针对 Claude Code 用户)
- 是否建议 Sonnet = Opus(防止自动升级)
- 是否需要调低 Opus 自动触发灵敏度
- 如果用户将来工作流变重/变轻,如何调整
输入解析指南
自然语言输入
当用户用自然语言描述模型时,提取以下模式:
"模型 A XXX 次/5h,YYY 次/周,ZZZ 次/月"
"模型 B 3450 每五小时,8550 每周"
"我只有美元成本,没有配额数"
必要时可以用公式估算:
若只有美元价格(如 $0.0035/次):
5h配额 ≈ $12 ÷ 单次成本
周配额 ≈ $30 ÷ 单次成本
月配额 ≈ $60 ÷ 单次成本
表格输入
用户可能贴如下格式的表格(markdown 或文本):
Model 每 5 小时 每周 每月
Model A 31,650 79,050 158,150
Model B 3,450 8,550 17,150
正确解析表头与数据行。
通用 OpenCode 预算常量
5小时窗口: $12
周窗口: $30
月窗口: $60
如果用户使用其他平台,优先使用用户提供的限制信息。
参考案例
案例 1:重量级工作流 + 严格预算
用户画像: 每天 10h+ Python 全栈,重量级 gstack 工作流,预算严格 $60/月
推荐模式(含数据来源引用):
| Slot | 模型 | 理由 |
|---|---|---|
| Opus | Qwen3.7 Max | 旗舰推理,950/5h 日均 190 次,$0.0126/次够重负载 |
| Sonnet | DeepSeek V4 Pro | 编码顶尖 + 3450/5h 日均 690 次,$0.0035/次宽裕 |
| Fable | Qwen3.7 Plus | 轻量分流,4300/5h |
| Haiku | DeepSeek V4 Flash | 几乎无限配额兜底,$0.00038/次近乎免费 |
核心经验: 旗舰选配额够厚的(日均 190+ 次),不要选配额薄的模型做旗舰(如 Kimi K3 仅 110/5h 扛不住重量级工作流)。参考定价:日成本约 Opus $0.63 + Sonnet $1.05 + Fable $0.28 + Haiku $0.04 ≈ $2.00/日 → 月均 $40-50,安全余量 20-33%。
案例 2:轻度使用 + 极致省钱
用户偶尔开发,不需要深度推理。
推荐模式:
| Slot | 模型 |
|---|---|
| Opus | = Sonnet(同一模型) |
| Sonnet | 性价比最高的编码模型 |
| Fable | 最便宜的可用模型 |
| Haiku | 同一最便宜模型 |
约束红线
- 绝不推荐用户明确禁用的模型。 用户说过"不要 X"就是不要。
- 绝不推荐配额不足以支撑日均消耗的模型做旗舰/主力。 除非用户明确要求"我知道它配额少,我就偶尔手动用"。
- 用户没有提供配额数据时,先问,不要瞎猜。
- 预算必须有安全余量。 推荐方案的月消耗应 ≤ 用户月预算的 80%,留意外波动空间。
- 如果用户提到 Claude Code 的"自动升级"但不确定是什么,解释清楚再继续。 不要假设用户了解这个机制。