feat(deepseek): register deepseek-v4-pro and deepseek-v4-flash models

[naorpeled]

What

Adds the new DeepSeek V4 model names to the MAX_TOKENS registry in pr_agent/algo/__init__.py:

'deepseek/deepseek-v4-pro': 1000000,    # 1M context
'deepseek/deepseek-v4-flash': 1000000,  # 1M context

Why

DeepSeek is deprecating the deepseek-chat and deepseek-reasoner model names on 2026-07-24, replacing them with deepseek-v4-pro and deepseek-v4-flash (API docs). Both V4 models ship with a 1M-token context window.

Without these entries, get_max_tokens() raises an exception for the new model names unless the user manually sets config.custom_model_max_tokens. This complements the docs update in #2472, which points users at the deepseek-v4-* names — that example would otherwise fail out of the box.

The existing deepseek-chat / deepseek-reasoner entries are left in place for backward compatibility until the deprecation date.

Notes

The V4 models are unified chat/reasoning models (standard ChatCompletions, support temperature), so unlike deepseek-reasoner they are intentionally not added to USER_MESSAGE_ONLY_MODELS or NO_SUPPORT_TEMPERATURE_MODELS.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Register DeepSeek V4 model names with 1M-token context limits
✨ Enhancement 🕐 Less than 5 minutes

Description

• Add DeepSeek V4 model names to the MAX_TOKENS registry for out-of-box support.
• Preserve legacy DeepSeek model entries for backward compatibility ahead of deprecation.
• Prevent get_max_tokens() exceptions when users switch to deepseek-v4-* model names.

Diagram

graph TD
  A["Model selection"] --> B["get_max_tokens()"] --> C["MAX_TOKENS registry"] --> D["deepseek-v4-pro (1M)"]
  C --> E["deepseek-v4-flash (1M)"]
  C --> F["deepseek-chat / reasoner (legacy)"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Prefix-based defaults for provider models

• ➕ Reduces churn from frequent model renames (e.g., deepseek-v4-*).
• ➕ Allows safe fallback behavior when a specific model key is missing.
• ➖ Risk of incorrect limits when models under a prefix diverge.
• ➖ Adds ambiguity/hidden behavior compared to explicit registry entries.

2. Provider capability discovery (dynamic max tokens)

• ➕ Always up-to-date with vendor changes; avoids manual registry updates.
• ➕ Can reflect per-account or per-region limits if exposed.
• ➖ Requires network calls/caching and error handling.
• ➖ Depends on vendor APIs exposing reliable context window metadata.

Recommendation: Keep the explicit MAX_TOKENS entries as implemented: it’s the lowest-risk and most consistent approach with the existing design, and it directly fixes the immediate failure mode (exceptions for new model names). The alternatives add complexity and/or ambiguity that isn’t justified for a simple model-name transition.

Files changed (1) +2 / -0

Enhancement (1) +2 / -0

__init__.pyAdd DeepSeek V4 model identifiers to MAX_TOKENS +2/-0

Add DeepSeek V4 model identifiers to MAX_TOKENS

• Registers deepseek/deepseek-v4-pro and deepseek/deepseek-v4-flash with 1,000,000 max tokens. Keeps existing DeepSeek entries unchanged to preserve backward compatibility while enabling the new names to work without custom_model_max_tokens overrides.

pr_agent/algo/init.py

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

• Author self-review: I have reviewed the code review findings, and addressed the relevant ones.