Thanks for adding the 1M variants. The diff itself is clean — three lines into api/config.py to surface the new IDs in the DeepSeek dropdown, with the V4 entries reordered so the 1M variants sit next to their base counterparts and the legacy v3 / reasoner rows stay at the bottom.

One coupling concern worth flagging before merge:

The [1m] suffix is novel — no other model ID in the dropdown registry uses bracket characters today. The hermes-agent side normalizes V-series IDs through _DEEPSEEK_V_SERIES_RE, and on current master that regex is ^deepseek-v\d+([-.].+)?$, which does not match deepseek-v4-flash[1m]. So if this PR ships before the companion hermes-agent#18509 lands (which widens the regex to ^deepseek-v\d+.*$), selecting either new entry in the dropdown would silently normalize the model to deepseek-chat and the user would get the legacy V3 chat completion path instead of the 1M-context model they picked.

That makes hermes-agent#18509 a hard prerequisite. Two options to handle the ordering:

1. Hold this PR until hermes-agent#18509 is merged and a release is cut, then merge here. Cleanest from a "no broken intermediate state" angle.
2. Merge both close together and call out the agent-version requirement in the WebUI CHANGELOG entry (e.g. "requires hermes-agent ≥ X.Y.Z").

Either is fine, but the dropdown shouldn't list [1m] IDs while the agent silently strips them — that's a confusing failure mode for anyone who upgrades WebUI ahead of the agent.

Two small nits, neither blocking:

• The mirror entry in the opencode-go provider list at api/config.py:777-778 (which already has bare deepseek-v4-pro / deepseek-v4-flash) doesn't get the 1M variants in this PR. If OpenCode Go also exposes the 1M endpoints, those would want the same treatment for consistency.
• static/ui.js has a hand-maintained STATIC_LABELS map for the message header model badge. New IDs without an entry there fall back to showing the raw ID. Adding the 1M labels there would round out the cosmetics, but isn't required for the picker to work.

Otherwise this is good. Ping when hermes-agent#18509 lands and I'll take another look.

Status update — agent companion PR is #18534, not #18509

Quick correction on the agent-side dependency referenced in the PR description: the regex-widening companion is actually hermes-agent #18534 — "feat(deepseek): add deepseek-v4-pro[1m] and deepseek-v4-flash[1m] to canonical models". The number cited in the body (#18509) is an unrelated DeepSeek Anthropic-endpoint thinking-block fix.

Status: agent #18534 is still OPEN (not merged).

Putting this on hold until that lands. The reasoning from my earlier review still stands — without the regex widening, selecting deepseek-v4-pro[1m] or deepseek-v4-flash[1m] in the WebUI dropdown would silently normalize to deepseek-chat and route through the legacy V3 endpoint. That's a confusing failure mode worth avoiding.

When agent #18534 merges and a hermes-agent release is cut, ping me here and I'll re-open the review. Two non-blocking items to consider for that review pass:

1. The mirror in the opencode-go provider entries at api/config.py:777-778 already has bare deepseek-v4-pro / deepseek-v4-flash but doesn't get the 1M variants. Worth adding for consistency if OpenCode Go also exposes 1M endpoints.
2. static/ui.js::STATIC_LABELS map needs entries for the new IDs so the message-header model badge renders the friendly name instead of the raw [1m] ID.

Thanks again for the cleanup — V4 first, legacy at the bottom is the right ordering.