-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Description
Problem (one or two sentences)
Users cannot access the specific DeepSeek V3.1 Terminus and Turbo model variants through the Chutes.ai provider in Roo Code. Furthermore, the critical "reasoning" mode for hybrid models like DeepSeek V3.1 and GLM-4.5 is not functional (#7370), despite being a core feature of these models that significantly improves output quality on complex tasks.
Context (who is affected and when)
This affects all Roo Code users who rely on state-of-the-art open-weight models for complex reasoning, coding, and creative tasks. When a user selects an OpenAI-Compatible provider like Chutes.ai and attempts to use the latest DeepSeek V3.1 models (Terminus/Turbo) or enable the reasoning effort for hybrid models, the functionality is either unavailable or does not work as expected.
Desired behavior (conceptual, not technical)
Model Variant Support: Users should be able to select and use deepseek-ai/DeepSeek-V3.1-Terminus and deepseek-ai/DeepSeek-V3.1-turbo as model options when the Chutes.ai (or similar OpenAI-compatible) provider is selected.
Functional Reasoning Mode: When the "Enable reasoning" toggle is enabled for supported hybrid models (DeepSeek V3.1, GLM-4.5), the model should actually engage its chain-of-thought reasoning process. The "Thinking" section should become visible in the UI, showing the model's step-by-step reasoning before presenting the final answer.
Constraints / preferences (optional)
UX Consistency: The experience should be consistent with how reasoning works for other supported models (e.g., claude-sonnet models).
Provider Flexibility: The solution should ideally be adaptable to work with OpenAI-compatible API endpoint that offers these models and supports their reasoning mode, including [Chutes.ai](https://chutes.ai/).
Request checklist
- I've searched existing Issues and Discussions for duplicates
- This describes a specific problem with clear context and impact
Roo Code Task Links (optional)
No response
Acceptance criteria (optional)
Criterion 1: Model Selection
Given the [Chutes.ai](https://chutes.ai/) provider is active in Roo Code,
When the user opens the model selection dropdown,
Then the options "DeepSeek-V3.1-Terminus" and "DeepSeek-V3.1-Turbo" should be present and selectable.
And these options should be clearly labeled and accessible.
But no unsupported or incorrect models should appear in the dropdown for this provider.
Criterion 2: API Call Verification
Given the user has selected "DeepSeek-V3.1-Terminus" (or a similar variant) from the dropdown,
When the user sends a chat message,
Then the API request to the [Chutes.ai](https://chutes.ai/) endpoint must include the correct model parameter (e.g., "deepseek-ai/DeepSeek-V3.1-Terminus").
And the request should be properly structured according to the API specifications.
But the model parameter should not be missing, default to an incorrect value, or cause API errors.
Criterion 3: Reasoning Toggle Efficacy
Given the user has selected a DeepSeek V3.1 model that supports reasoning (e.g., DeepSeek-V3.1),
When the user enables the "Enable reasoning" toggle in the UI,
Then the API request must include the necessary parameters to trigger reasoning mode (e.g., a specific token like "<|begin▁of▁sentence|>" or a JSON flag).
And the toggle should provide clear visual feedback (e.g., highlighted) to indicate it is active.
But the reasoning mode should not be activated if the toggle is disabled, or if the model does not support it.
Criterion 4: UI Feedback for Reasoning
Given reasoning mode is enabled and a chat request is sent,
When the model streams its response,
Then the UI must display a distinct "Thinking" section that shows the reasoning process in real-time, separate from the final answer.
And the reasoning content should be parsed correctly from the stream (e.g., based on delimiters like "<|begin▁of▁sentence|>").
But the "Thinking" section should not appear if reasoning mode is not enabled, or if the response does not contain reasoning content.
Proposed approach (optional)
No response
Trade-offs / risks (optional)
Provider-Specific Logic: The solution might require some provider-specific logic if different endpoints implement the reasoning feature differently. The goal should be to find a common pattern or make it configurable.
Maintenance Overhead: As these models and their APIs evolve, the implementation may need updates to remain compatible. However, supporting these popular models is a significant value-add for users.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status