feat(core,cli,web,docs,skills): AgentHub 0.4.6 with the DeepSeek vision model

[hiyouga]

What this does

Upgrades @prismshadow/agenthub from 0.4.5 to 0.4.6 and adapts to the two changes it brings (agenthub #185).

deepseek-v4-flash-vision-exp joins the catalog, in two groups.

• DeepSeek group: 1M context, supportsVision: true, official off-peak CNY tier — cache hit ¥0.05 / cache miss ¥1.5 / output ¥4.5 per million tokens, i.e. V4 Flash's own price (pricing page). That matches agenthub's registry entry, which prices it identically.
• OpenRouter group: 1,048,576 context, usd(0.007, 0.22, 0.66) — read from the models API, which is authoritative over the model page per the catalog's own convention. DeepSeek is the only provider serving it there, so the two rows agree up to the catalog's 7:1 display conversion.

Both record the off-peak tier, the convention the existing DeepSeek rows already follow (issue #313). Peak hours — Beijing 9:00–12:00 and 14:00–18:00 — bill exactly double, and the cost centre uses one rate, so peak usage is under-counted 2x. The OpenRouter models API states the same thing structurally: the entry carries a pricing.overrides array whose two peak windows double every bucket, and the base pricing object is the off-peak rate this row stores.

DeepSeek moved onto the Responses protocol. DeepSeekV4Client now posts {base}/responses instead of {base}/chat/completions. The Web model dialog's base URL suffix is a display of exactly that path, so it had to follow: the deepseek group and an explicit deepseek-v4 client type now hint /responses. Gateway rows reselling DeepSeek pin openai-chat and are unaffected — that pin is already load-bearing for other reasons, and it keeps them on Chat Completions, which is what SiliconFlow serves.

resolveModelEnv needed nothing: it matches deepseek-v4 as a substring, which the new id contains, so it already resolves the DEEPSEEK_* pair.

Breaking

A model id containing deepseek-v4 with no client_type routes to the DeepSeek client by id alone, and that client's request path changed. Entries pointed at https://api.deepseek.com are fine — it serves both protocols. An entry pointed at a Chat Completions-only endpoint (self-hosted, a relay, a third-party DeepSeek-compatible gateway) starts failing on upgrade, and the fix is to set client_type = "openai-chat" on it. The changelog entry's ## Compatibility section says so, and the shipped agenthub-models skill now records which protocol the client speaks.

No compatibility code was added, so there is no backward-compatibility.md in this batch. A migration that stamps client_type = "openai-chat" onto existing DeepSeek-id entries in custom groups is possible if the break is judged too sharp — say the word and I will add it.

Verification

• pnpm install (lockfile now resolves 0.4.6), pnpm -r build, pnpm typecheck, pnpm format + pnpm format:check — all clean.
• Confirmed against the installed 0.4.6 registry that the new id is present with input_modalities: ["Text","Image"], a 1M window and V4 Flash's price, and that the two SiliconFlow rows moved to openai-chat upstream (ours already pinned it).
• Scoped tests, per the catalog's touch list: core model-catalog.test.ts (24), web protocol-path.test.ts / model-grouping.test.ts / protocol-detect.test.ts (56), server models.test.ts / models-vision.test.ts (26), skills package (24), docs skills-sync / search / content (33). All pass.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.