| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Hey! Your PR title transform to DeepSeek API fix and aditional test cases doesn't follow conventional commit format. Please update it to start with one of:
Where scope is the package name (e.g., app, desktop, opencode). See CONTRIBUTING.md for details. |
Sorry, something went wrong.
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
Sorry, something went wrong.
…king: enabled
DeepSeek requires reasoning_content in providerOptions.openaiCompatible for
all assistant messages, even when empty (the API rejects requests without it).
The generic interleaved handling only runs when capabilities.interleaved is
set to an object with a field, which may not always be the case for DeepSeek
models depending on models.dev data.
- Merge the reasoning part padding into a single DeepSeek‑specific block that
extracts reasoning parts to providerOptions.openaiCompatible.reasoning_content
and strips them from content (with return, skipping generic interleaved)
- Add result["thinking"] = { type: "enabled" } in options() so DeepSeek
reasoning models return reasoning_content in the first place
| Back | FazBrowse Home | New Git URL |
Issue for this PR
Closes #17523, #9397, #8934
Type of change
What does this PR do?
Problem: When using DeepSeek models with thinking mode (via reasoner model IDs or thinking option), assistant messages after the last user message were missing the reasoning_content field. The DeepSeek API expects this field to be present (even if empty) for proper thinking mode operation in multi-turn conversations. The official DeepSeek API only utilizes current turn reasoning, no need for previous reasoning to be provided.
Changes made:
Modified packages/opencode/src/provider/transform.ts to:
Added tests in packages/opencode/test/provider/transform.test.ts covering:
Why it works: The DeepSeek API documentation indicates that thinking mode requires the reasoning_content field to be present on assistant messages. By setting it to an empty string for assistant messages after the last user message, we comply with API expectations while maintaining backward compatibility for non-thinking mode usage.
How did you verify your code works?
Screenshots / recordings
N/A - This is a backend fix with no UI changes.
Checklist
If you do not follow this template your PR will be automatically rejected.