anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE]: Preserve reasoning blocks with reasoning_details for OpenRouter #2888

New Issue
Closed
opened 2026-02-16 17:37:41 -05:00 by yindo · 5 comments
yindo commented 2026-02-16 17:37:41 -05:00
Owner
Copy Link
Copy Source

Originally created by @oabdellatif on GitHub (Nov 16, 2025).

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Reasoning models from OpenAI/Anthropic/xAI as well as certain OSS models (e.g. MiniMax-M2) support passing reasoning blocks back to the model. This is implemented by the native provider APIs but is not easily supported by the OpenAI-compatible provider. According to the OpenRouter docs, this can be done by passing back the reasoning_details field: Preserving Reasoning Blocks.

The OpenRouter AI SDK provider seems to support this, but it requires passing back providerOptions according to this comment (src/chat/convert-to-openrouter-chat-messages.ts):

// Check if we have preserved reasoning_details from the original OpenRouter response
// OpenRouter requires reasoning_details to be passed back unmodified for multi-turn conversations
// If we don't have the preserved version (AI SDK doesn't pass providerOptions back),
// we should NOT send reconstructed reasoning_details as they won't match the original
// Instead, only use the legacy reasoning field

This allows for parity in model performance between OpenRouter and the native APIs, as results will be compromised without maintaining the reasoning context.

Originally created by @oabdellatif on GitHub (Nov 16, 2025). ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request Reasoning models from OpenAI/Anthropic/xAI as well as certain OSS models (e.g. MiniMax-M2) support passing reasoning blocks back to the model. This is implemented by the native provider APIs but is not easily supported by the OpenAI-compatible provider. According to the OpenRouter docs, this can be done by passing back the reasoning_details field: [Preserving Reasoning Blocks](https://openrouter.ai/docs/use-cases/reasoning-tokens#preserving-reasoning-blocks). The OpenRouter AI SDK provider seems to support this, but it requires passing back providerOptions according to this comment ([src/chat/convert-to-openrouter-chat-messages.ts](https://github.com/OpenRouterTeam/ai-sdk-provider/blob/9607d475ecd7ec5cd234daaf5db0e3e4c782e1cf/src/chat/convert-to-openrouter-chat-messages.ts#L195-L199)): ``` // Check if we have preserved reasoning_details from the original OpenRouter response // OpenRouter requires reasoning_details to be passed back unmodified for multi-turn conversations // If we don't have the preserved version (AI SDK doesn't pass providerOptions back), // we should NOT send reconstructed reasoning_details as they won't match the original // Instead, only use the legacy reasoning field ``` This allows for parity in model performance between OpenRouter and the native APIs, as results will be compromised without maintaining the reasoning context.
yindo added the discussion label 2026-02-16 17:37:41 -05:00
yindo closed this issue 2026-02-16 17:37:41 -05:00
yindo commented 2026-02-16 17:37:42 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 18, 2025):

I think the issue is that models.dev uses the openai compatible ai sdk provider instead of the openrouter one

@rekram1-node commented on GitHub (Nov 18, 2025): I think the issue is that models.dev uses the openai compatible ai sdk provider instead of the openrouter one
yindo commented 2026-02-16 17:37:42 -05:00
Author
Owner
Copy Link
Copy Source

@Mushoz commented on GitHub (Nov 27, 2025):

I think the issue is that models.dev uses the openai compatible ai sdk provider instead of the openrouter one

But don't we need similar functionality for openai compatible endpoints? For example, minimax-m2 can also be served through llamacpp. The reasoning tokens are returned in reasoning_content. Opencode should also be able to pass back reasoning_content, so the chat template can integrate those tokens into the prompt that will be processed.

@Mushoz commented on GitHub (Nov 27, 2025): > I think the issue is that models.dev uses the openai compatible ai sdk provider instead of the openrouter one But don't we need similar functionality for openai compatible endpoints? For example, minimax-m2 can also be served through llamacpp. The reasoning tokens are returned in `reasoning_content`. Opencode should also be able to pass back `reasoning_content`, so the chat template can integrate those tokens into the prompt that will be processed.
yindo commented 2026-02-16 17:37:42 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 27, 2025):

yep we do need to do that, also i forgot to close this we addressed this partially the interleavened thinking models on openrouter use their sdk

@rekram1-node commented on GitHub (Nov 27, 2025): yep we do need to do that, also i forgot to close this we addressed this partially the interleavened thinking models on openrouter use their sdk
yindo commented 2026-02-16 17:37:42 -05:00
Author
Owner
Copy Link
Copy Source

@Mushoz commented on GitHub (Nov 27, 2025):

Should I open a new issue for implementing this for OpenAI compatible endpoints? Or is that already being tracked somewhere?

@Mushoz commented on GitHub (Nov 27, 2025): Should I open a new issue for implementing this for OpenAI compatible endpoints? Or is that already being tracked somewhere?
yindo commented 2026-02-16 17:37:42 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 27, 2025):

No need i have to make a pr for vercel ai sdk anyways

@rekram1-node commented on GitHub (Nov 27, 2025): No need i have to make a pr for vercel ai sdk anyways
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2888
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?