添加deepseek-v4-pro支持选择max思考深度#365
Conversation
Co-authored-by: Copilot <copilot@github.com>
📝 WalkthroughWalkthroughThe changes extend effort level support to include DeepSeek V4 Pro. Two files are updated: the effort command's help text mentions DeepSeek V4 Pro alongside Opus models, and the effort utility functions are expanded to recognize and validate DeepSeek V4 Pro for both standard and max effort levels. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
src/utils/effort.ts (3)
35-43: Consider using the 3P capability override mechanism instead of hardcodingdeepseek-v4-pro.
get3PModelCapabilityOverride()(already invoked on line 31) is the documented extension point for non-Anthropic models — users pin the model withANTHROPIC_DEFAULT_*_MODEL=deepseek-v4-proand setANTHROPIC_DEFAULT_*_MODEL_SUPPORTED_CAPABILITIES=effort,max_effort,.... Hardcoding a third-party brand name into the core allowlist couples this file to a specific vendor and skips that user-controlled config. The current 1P substring list (opus-4-6/opus-4-7/sonnet-4-6) is for first-party Claude models; this is the first 3P entry to be inlined.If hardcoding is intentional (e.g., a deployment-wide default for this fork), feel free to ignore — but please document the rationale in the
@[MODEL LAUNCH]comment block so future model launches don't accidentally expand the pattern.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/utils/effort.ts` around lines 35 - 43, The code currently hardcodes a third-party model substring ("deepseek-v4-pro") in the capability allowlist; instead, use the existing 3P override mechanism by consulting get3PModelCapabilityOverride() (already invoked near where m is compared) to determine whether the model supports the "effort" capability rather than inlining "deepseek-v4-pro". Update the logic in the block that checks m.includes(...) to first check the 3P override return for the current model identifier (m) and respect any configured supported capabilities, removing the hardcoded "deepseek-v4-pro" entry; if hardcoding is intentionally required, add a clear @[MODEL LAUNCH] comment explaining the rationale above the allowlist.
26-81: Recommend adding unit tests for the newdeepseek-v4-probranches.
modelSupportsEffortandmodelSupportsMaxEffortfeedconfigureEffortParamsinsrc/services/api/claude.tsand the clamp insrc/components/ModelPicker.tsx. A small test that asserts both returntruefordeepseek-v4-pro(and that themax → highclamp inresolveAppliedEffortdoes not trigger) would lock in the new behavior cheaply.Want me to draft a test case for the existing effort.test.ts (if one exists)?
#!/bin/bash fd -t f 'effort\.(test|spec)\.ts' rg -nP "modelSupports(Effort|MaxEffort)\s*\(" -g '*.{test,spec}.{ts,tsx}'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/utils/effort.ts` around lines 26 - 81, Add unit tests to cover the new deepseek-v4-pro branches: create/extend effort.test.ts to assert modelSupportsEffort('deepseek-v4-pro') and modelSupportsMaxEffort('deepseek-v4-pro') both return true, and add a test that calling resolveAppliedEffort/configureEffortParams (used by src/services/api/claude.ts and src/components/ModelPicker.tsx) with a deepseek-v4-pro model does not trigger the max→high clamp; use the same helpers/mocks as existing effort tests to set USER_TYPE/process env and 3P overrides when needed.
60-76: Optional: hoistmodel.toLowerCase()and tighten the doc comment.The function now calls
model.toLowerCase()three times. Also, the comment "max is Opus 4.6/4.7 only for public models — other models return an error. However, DeepSeek V4 Pro also supports max effort..." reads as self-contradicting — the new line could be merged into the same statement.♻️ Proposed cleanup
// @[MODEL LAUNCH]: Add the new model to the allowlist if it supports 'max' effort. -// Per API docs, 'max' is Opus 4.6/4.7 only for public models — other models return an error. -// However, DeepSeek V4 Pro also supports max effort when using Anthropic-compatible API. +// Per API docs, 'max' is supported on Opus 4.6/4.7 (public) and DeepSeek V4 Pro +// (via Anthropic-compatible API); other models return an error. export function modelSupportsMaxEffort(model: string): boolean { const supported3P = get3PModelCapabilityOverride(model, 'max_effort') if (supported3P !== undefined) { return supported3P } - // Support DeepSeek V4 Pro specifically (Anthropic-compatible API) - if (model.toLowerCase().includes('deepseek-v4-pro')) { - return true - } + const m = model.toLowerCase() if ( - model.toLowerCase().includes('opus-4-7') || - model.toLowerCase().includes('opus-4-6') + m.includes('opus-4-7') || + m.includes('opus-4-6') || + m.includes('deepseek-v4-pro') ) { return true }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/utils/effort.ts` around lines 60 - 76, Hoist the repeated model.toLowerCase() calls by creating a local const (e.g., const lc = model.toLowerCase()) at the top of modelSupportsMaxEffort so all subsequent checks use lc; update the if checks that call model.toLowerCase() to use lc instead. While here, tighten the function doc comment to a single clear sentence (e.g., "Per API docs, 'max' is only supported for Opus 4.6/4.7 public models; DeepSeek V4 Pro via the Anthropic-compatible API also supports max effort.") and leave the existing get3PModelCapabilityOverride(model, 'max_effort') behavior unchanged. Ensure references to modelSupportsMaxEffort and get3PModelCapabilityOverride remain intact.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/commands/effort/effort.tsx`:
- Line 172: The help text for /effort uses a comma in the "max" description
while getEffortLevelDescription('max') in src/utils/effort.ts uses a slash; make
them consistent by choosing one separator and updating the other to match:
either change the string in src/commands/effort/effort.tsx (the usage/help
message) to use "Opus 4.6/4.7/DeepSeek V4 Pro" or update
getEffortLevelDescription's 'max' return value to "Opus 4.6/4.7, DeepSeek V4
Pro" so both the /effort help and the getEffortLevelDescription('max') output
are identical.
---
Nitpick comments:
In `@src/utils/effort.ts`:
- Around line 35-43: The code currently hardcodes a third-party model substring
("deepseek-v4-pro") in the capability allowlist; instead, use the existing 3P
override mechanism by consulting get3PModelCapabilityOverride() (already invoked
near where m is compared) to determine whether the model supports the "effort"
capability rather than inlining "deepseek-v4-pro". Update the logic in the block
that checks m.includes(...) to first check the 3P override return for the
current model identifier (m) and respect any configured supported capabilities,
removing the hardcoded "deepseek-v4-pro" entry; if hardcoding is intentionally
required, add a clear @[MODEL LAUNCH] comment explaining the rationale above the
allowlist.
- Around line 26-81: Add unit tests to cover the new deepseek-v4-pro branches:
create/extend effort.test.ts to assert modelSupportsEffort('deepseek-v4-pro')
and modelSupportsMaxEffort('deepseek-v4-pro') both return true, and add a test
that calling resolveAppliedEffort/configureEffortParams (used by
src/services/api/claude.ts and src/components/ModelPicker.tsx) with a
deepseek-v4-pro model does not trigger the max→high clamp; use the same
helpers/mocks as existing effort tests to set USER_TYPE/process env and 3P
overrides when needed.
- Around line 60-76: Hoist the repeated model.toLowerCase() calls by creating a
local const (e.g., const lc = model.toLowerCase()) at the top of
modelSupportsMaxEffort so all subsequent checks use lc; update the if checks
that call model.toLowerCase() to use lc instead. While here, tighten the
function doc comment to a single clear sentence (e.g., "Per API docs, 'max' is
only supported for Opus 4.6/4.7 public models; DeepSeek V4 Pro via the
Anthropic-compatible API also supports max effort.") and leave the existing
get3PModelCapabilityOverride(model, 'max_effort') behavior unchanged. Ensure
references to modelSupportsMaxEffort and get3PModelCapabilityOverride remain
intact.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 7a302c34-18cd-4120-b0cf-00774f97d866
📒 Files selected for processing (2)
src/commands/effort/effort.tsxsrc/utils/effort.ts
| if (COMMON_HELP_ARGS.includes(args)) { | ||
| onDone( | ||
| 'Usage: /effort [low|medium|high|max|auto]\n\nEffort levels:\n- low: Quick, straightforward implementation\n- medium: Balanced approach with standard testing\n- high: Comprehensive implementation with extensive testing\n- max: Maximum capability with deepest reasoning (Opus 4.6 only)\n- auto: Use the default effort level for your model', | ||
| 'Usage: /effort [low|medium|high|max|auto]\n\nEffort levels:\n- low: Quick, straightforward implementation\n- medium: Balanced approach with standard testing\n- high: Comprehensive implementation with extensive testing\n- max: Maximum capability with deepest reasoning (Opus 4.6/4.7, DeepSeek V4 Pro)\n- auto: Use the default effort level for your model', |
There was a problem hiding this comment.
Minor: separator inconsistency with getEffortLevelDescription('max').
The help text here uses Opus 4.6/4.7, DeepSeek V4 Pro (comma), while getEffortLevelDescription('max') in src/utils/effort.ts (line 276) uses Opus 4.6/4.7/DeepSeek V4 Pro (slash). Pick one for consistency between /effort help and /effort status output.
✏️ Proposed alignment
- 'Usage: /effort [low|medium|high|max|auto]\n\nEffort levels:\n- low: Quick, straightforward implementation\n- medium: Balanced approach with standard testing\n- high: Comprehensive implementation with extensive testing\n- max: Maximum capability with deepest reasoning (Opus 4.6/4.7, DeepSeek V4 Pro)\n- auto: Use the default effort level for your model',
+ 'Usage: /effort [low|medium|high|max|auto]\n\nEffort levels:\n- low: Quick, straightforward implementation\n- medium: Balanced approach with standard testing\n- high: Comprehensive implementation with extensive testing\n- max: Maximum capability with deepest reasoning (Opus 4.6/4.7, DeepSeek V4 Pro)\n- auto: Use the default effort level for your model',(or update line 276 in src/utils/effort.ts to match — pick whichever style you prefer.)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/commands/effort/effort.tsx` at line 172, The help text for /effort uses a
comma in the "max" description while getEffortLevelDescription('max') in
src/utils/effort.ts uses a slash; make them consistent by choosing one separator
and updating the other to match: either change the string in
src/commands/effort/effort.tsx (the usage/help message) to use "Opus
4.6/4.7/DeepSeek V4 Pro" or update getEffortLevelDescription's 'max' return
value to "Opus 4.6/4.7, DeepSeek V4 Pro" so both the /effort help and the
getEffortLevelDescription('max') output are identical.
Summary by CodeRabbit
Release Notes