Support for deepseek-v4-pro/flash Preview and optimal configuration for reasoning models

[gtonu]

Hi everyone,
With DeepSeek's official release of the DeepSeek V4 model family, including deepseek-v4-pro and deepseek-v4-flash, I would like to inquire if the community plans to introduce native configuration support for these variants.

Given their aggressive pricing, 1M token context capacity, and optimized agentic coding benchmarks, integrating these variants would offer a highly cost-efficient alternative for PR reviews.

I am currently running pr-agent via GitHub Actions with the following workflow setup and configuration:

GitHub Actions Workflow:

pr-agent-job:
    if: \${{ github.event.sender.type != 'Bot' }}
    runs-on: ubuntu-latest

    name: Calling Pr-agent
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        
      - name: Setup Pr-agent
        uses: Codium-ai/pr-agent@e13da4fdda9903c8c7d1c9ba22f671b43f56039b
        env:
          OPENAI_KEY: \${{ secrets.OPENAI_API_KEY }}
          GITHUB_TOKEN: \${{ secrets.GITHUB_TOKEN }}

PR-Agent Config:

[config]
model = "gpt-4o-mini-2024-07-18"
fallback_models = []
#model_reasoning = ""
#model_weak = ""
temperature = 0.2
max_tokens = 1500

Context

• DeepSeek V4 Pro (deepseek-v4-pro): Exceptional for heavy code reasoning, multi-file context tracking, and high-complexity agentic workflows.
• DeepSeek V4 Flash (deepseek-v4-flash): Extremely low latency and low cost, perfect for quick PR summarizations, changelog generation, or as a fast utility fallback.

Currently, pr-agent accommodates custom OpenAI-compatible endpoints, but explicit naming configurations and specific handling for DeepSeek's native reasoning_content (interleaved thinking blocks) are necessary to maximize review quality and avoid token formatting errors.

Questions for the Community

1. Model Support & Identifiers: Are deepseek-v4-pro and deepseek-v4-flash already natively supported in PR-Agent? If so, what are the correct provider prefixes and identifiers to use in the configuration?
2. Reasoning Orchestration: If I decide to transition to these new models, how should I ideally structure the model_reasoning and model_weak parameters using the DeepSeek V4 family (e.g., mapping Pro to reasoning and Flash to weak)?
3. Task Allocation: How does PR-Agent internally decide which tasks to offload to model_reasoning versus the primary model when both are defined?
4. Performance vs. Efficiency: In terms of code review quality, is it better to route all tasks to a single strong model like deepseek-v4-pro, or does splitting tasks across model, model_reasoning, and model_weak yield a significant functional benefit?
5. Workaround Routing: If native integration isn't fully ready, what is the recommended fallback configuration to securely route these models using the general openai or custom endpoint provider setup in our current workflow?

Thank you for your help!

[richardchen874-sys]

This is a very relevant use case for DeepSeek in PR review workflows.

For PR-Agent, I would probably separate the configuration by task type instead of treating all requests the same:

• deepseek-v4-pro for heavy code reasoning, multi-file review, architectural comments, and complex bug detection
• deepseek-v4-flash for quick summaries, changelog generation, simple comments, and fallback/utility tasks

The harder part is not only whether the model names are accepted, but how PR-Agent handles reasoning output, streaming, tool/function calling, max token limits, and fallback routing.

For production GitHub Actions usage, I’d also watch:

1. latency on large PRs
2. token cost per review
3. failure rate / timeout behavior
4. whether reasoning_content is preserved or stripped correctly
5. whether fallback models actually trigger when one endpoint fails

I’m also looking at how indie devs and small AI teams use lower-cost model APIs like DeepSeek and BytePlus for coding/review workflows, so this is exactly the kind of integration question I’m interested in.

Curious — are you mainly optimizing PR-Agent for review quality, lower cost, or faster GitHub Actions runtime?