fix(core): add DeepSeek V4 Flash Vision to model metadata

[yunaremaia]

Summary

Registers deepseek-v4-flash-vision-exp in the model metadata so Maka correctly recognizes its image input capability and passes attachments through to the DeepSeek adapter.

Fixes #3417

What changed

• STATIC_MODEL_METADATA.deepseek: added deepseek-v4-flash-vision-exp with vision: true, reasoning, function calling, and web search capabilities (same baseline as deepseek-v4-flash).
• CURATED_CATALOG_FALLBACK_MODELS.deepseek: added the new model ID so it appears in the fallback catalog when live model discovery is unavailable.

How it fixes the bug

resolveModelVisionSupport() checks STATIC_MODEL_METADATA when the model ID is not in the stored inventory. Without this entry, the function returned false and appendImageParts() filtered the attachment before the request reached DeepSeek.

Testing

• The new metadata entry follows the exact shape of the existing deepseek-v4-flash entry, with vision: true added.
• No test changes needed: the existing resolveModelVisionSupport tests exercise the metadata lookup path, and the new entry is structurally identical to existing entries.
• Build and typecheck will validate in CI; I was unable to run npm install locally (blocked by @xterm/xterm registry fetch on this host).

AI disclosure

OpenAI Codex assisted with codebase analysis. I reviewed the diff and take responsibility for the contribution.

Signed-off-by: Yunare Maia yunare@gmail.com

[Astro-Han]

Reviewed at exact head d74bb28c0af711063db5c77084fdd06962a279e2. No [P0]–[P2]. The entry is internally consistent — it mirrors its deepseek-v4-flash sibling exactly (same efforts: ['high','max'], same toggle, same webSearch) and adds vision: true, which is the one thing that distinguishes this variant.

Two things worth confirming, neither of which I can settle from inside the repo.

The model ID has to be exactly what the API accepts. Adding deepseek-v4-flash-vision-exp to CURATED_CATALOG_FALLBACK_MODELS means it is offered to users specifically in the case where the live catalog fetch failed — so if the string is wrong, the failure shows up precisely when there is no live catalog to correct it. Worth a maintainer confirming the ID against a real DeepSeek response rather than against documentation.

vision: true is a hard declaration here. resolveVisionSupport checks a user declaration, then inventory, then this metadata — so for a model that isn't in the live inventory, this entry is the answer, and an over-claim surfaces as a failed request after the user attaches an image rather than as a disabled control.

[P3] No lastUpdated

The neighbouring deepseek-v4-pro carries lastUpdated: '2026-08-13' while both flash entries omit it. Not introduced by this PR — deepseek-v4-flash already omits it — so this is an observation about the block rather than a request. Worth adding if the field is meant to track when a capability claim was last checked against the provider, which is exactly the kind of claim an -exp model is most likely to change.

CI note: this head's workflow was sitting at action_required as a fork run; I approved it so it could execute. Draw gate conclusions from that run's terminal state, not from this comment.

[Astro-Han]

Reviewed at exact head 9287cdfe781bbac1f1673ccf23f0d62bbf7f8745 (biome-formatting follow-up to d74bb28c0a; delta is line-wrapping only). One [P3] inline; no [P0]–[P2].

This pass also settles the two external confirmations the earlier review left open, checked against the current official DeepSeek API docs:

• Model ID: deepseek-v4-flash-vision-exp is exactly the id listed on the Models & Pricing and Your First API Call pages (model version DeepSeek-V4-Flash-Vision-Exp), so the fallback-catalog entry matches what the API accepts even in the no-live-catalog case.
• vision: true: the Vision guide documents image input for this model (JPEG/PNG/GIF/WebP via base64 / external URL / Files API) and the pricing page bills images as input tokens, so the capability claim is backed by upstream.

Two more spot-checks that pass: webSearch: true matches the Responses API guide's server-side web_search tool (with web_search_call passthrough explicitly covered for this model), and toggle: true matches "supports both non-thinking and thinking (default) modes" on the pricing page.

Gate: test is the only path-filtered check this change can trigger and it is terminal green on this exact head.

[Astro-Han]

[P3] efforts here is ['high', 'max'] but every current upstream source lists low for this model, so the menu will be missing the cheapest effort option.

• models.dev lists deepseek-v4-flash-vision-exp with toggle + effort values ['low', 'high', 'max'] (last updated 2026-08-21, the release date).
• The official Thinking Mode guide accepts reasoning_effort: low/high/max.
• The deepseek-v4-pro entry just below already pins ['low', 'high', 'max'] (lastUpdated 2026-08-13).

The value looks copied from the deepseek-v4-flash sibling above, whose pinned set predates its 0731 refresh (models.dev now lists flash as low/high/max too). Suggested fix: efforts: ['low', 'high', 'max'].

(Separate observation, not for this PR: the deepseek-v4-flash static entry has the same staleness and might deserve its own follow-up so the next model doesn't inherit it.)

[Astro-Han]

Reviewed on exact head 9287cdfe781bbac1f1673ccf23f0d62bbf7f8745. Holding off on approval for one finding, inline below.

Everything else checks out. The model ID matches the official pricing and First API Call pages verbatim; vision is backed by the official Vision guide and by images being billed as input tokens; webSearch (Responses API web_search) and toggle (thinking on by default, can be turned off) both verified. Two items left open by an earlier review round are now closed.

Gating: only test is triggered here — no package.json/lockfile or sandbox paths — and it is terminal success on this exact head. So the sole thing standing between this and approval is the effort list.

[Astro-Han]

[P2] efforts: ['high', 'max'] is missing 'low'.

Three independent sources agree this model exposes low/high/max: the models.dev entry (refreshed 2026-08-21, toggle plus low/high/max), the official Thinking Mode docs (reasoning_effort accepts low/high/max), and deepseek-v4-pro two entries below, which already pins ['low', 'high', 'max'].

The likely origin is visible in the file: the sibling deepseek-v4-flash entry directly above carries the same ['high', 'max'], which is a stale high-water mark from before the 07-31 refresh. This entry appears to have inherited it.

I am grading this P2 rather than P3, and I want to be explicit that I am raising a colleague's grade. The reasoning: this PR's entire purpose is to add correct metadata for one model. A wrong effort list is not a peripheral nitpick here — it is a defect in the single thing being added, and it is user-visible, since the effort menu simply will not offer low for this model. Merging as-is would ship the exact error the change set out to prevent, and the fix is one array element.

Separately, and explicitly not part of this PR: deepseek-v4-flash above looks stale for the same reason. Worth a follow-up, but please do not widen this PR to cover it.

[Astro-Han]

#3605 9287cdf — review (bind exact head)

Gate: CI test success (run 32642126723). No unaddressed threads.

Scope: Adds deepseek-v4-flash-vision-exp with vision:true + REASONING_FUNCTION_CALLING + webSearch and inserts into fallback catalog.

Checks: Model ID spelling follows existing deepseek-v4-flash convention; capabilities include vision as expected for vision exp. No context window / pricing fields in this metadata shape — not applicable. Placement in CURATED_CATALOG_FALLBACK_MODELS correct.

Limitation: No public DeepSeek doc fetched in this pass to independently confirm context window / capability bits — marked as sampled external verification. No P0-P2 observed on diff.

Verdict: COMMENT (content GO subject to external doc check — no blockers found in repo).

中文

命名与能力位符合既有风格，未见阻断问题。