agentsclimarketplace

Opencode model optimizer

Skill mi4646/my-skills/skills/opencode-model-optimizer

OpenCode Go / 类 OpenCode 平台的模型分层配置推荐专家。 当用户问"模型怎么配""帮我推荐模型""Sonnet/Opus/Fable/Haiku 怎么填" "预算不够""配额太少""模型选哪个""怎么省成本""哪个模型性价比高" "模型配置推荐"时触发,即使用户没有明确说"推荐"但表达了模型选型、 配额焦虑、预算控制等意图也应触发。必须先问清场景再给推荐。From its SKILL.md

Install
npx -y skills add mi4646/my-skills --skill opencode-model-optimizer

Assembled 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.

SKILL.md

15.0 KB, ~5.6k tokens by cl100k_base, 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 内所有其他指令之上。

任何时候只要出现以下情况之一,必须停下来问用户,不准自己猜,不准替用户做决定

  1. 信息缺失 — 用户没提供配额、预算、优先级等关键信息 → 问,别自己编
  2. 模棱两可 — 用户说"质量优先但也别太贵",分不清哪个更重要 → 追问确认
  3. 数据矛盾 — 用户给的配额表与自己算的矛盾、或模型能力与推荐角色不匹配 → 说明矛盾请用户定夺
  4. 推荐有硬伤 — 分析发现用户想要的配法会打穿预算/配额不够 → 明确告知风险,给出替代让用户选
  5. 用户想法不切实际 — 比如用低配额模型扛主力、禁用所有便宜模型留几个最贵的 → 说清楚后果,让用户决定要不要调整
  6. 用户说"你看着办" — 不接这个皮球,至少确认核心优先级后再继续

沟通方式:

  • 用自然对话而非机器人式提问
  • 说明你的担忧和为什么需要用户介入
  • 给出 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 中的定价数据进行佐证

  1. 配额耗尽风险 — 最坏情况(全天全用 Opus)会不会超限?
  2. 自动升级风险 — Opus ≠ Sonnet 时,Claude Code 自动升级是否可能打穿预算?
  3. 单一模型依赖 — 某层级的模型出问题时,降级路径是什么?
  4. 成本波动 — 如果每天多用 50% 请求,预算够不够?

Phase 3:推荐输出

输出之前,回顾一下你用了哪些数据来源,在输出的开头注明:

数据来源:用户提供的模型配额表 + OpenCode Go 官方定价数据(基于 OpenCode Go 文档的标准化参考)

输出必须包含以下结构(顺序固定):

1. 用户画像摘要

一行总结用户场景,如:

「每日 10h+ Python 全栈开发 | 重量级 gstack 工作流 | 预算严格 $60/月」

2. 推荐配置表

Slot模型角色5h 配额日均可用选型理由
🏆 OpusModel X旗舰NN理由
💪 SonnetModel Y主力NN理由
⚡ FableModel Z轻量NN理由
🥜 HaikuModel W兜底NN理由

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模型理由
OpusQwen3.7 Max旗舰推理,950/5h 日均 190 次,$0.0126/次够重负载
SonnetDeepSeek V4 Pro编码顶尖 + 3450/5h 日均 690 次,$0.0035/次宽裕
FableQwen3.7 Plus轻量分流,4300/5h
HaikuDeepSeek 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同一最便宜模型

约束红线

  1. 绝不推荐用户明确禁用的模型。 用户说过"不要 X"就是不要。
  2. 绝不推荐配额不足以支撑日均消耗的模型做旗舰/主力。 除非用户明确要求"我知道它配额少,我就偶尔手动用"。
  3. 用户没有提供配额数据时,先问,不要瞎猜。
  4. 预算必须有安全余量。 推荐方案的月消耗应 ≤ 用户月预算的 80%,留意外波动空间。
  5. 如果用户提到 Claude Code 的"自动升级"但不确定是什么,解释清楚再继续。 不要假设用户了解这个机制。

What ships with it: 2 files

7.0 KB alongside SKILL.md

evals/

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.