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

[PR #5053] feat(mistral): allow Mistral transforms for local/custom models #11225

New Issue
Closed
opened 2026-02-16 18:16:01 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 18:16:01 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/anomalyco/opencode/pull/5053

State: closed
Merged: No

Thanks for this wonderful project!

This PR addresses an issue when running Mistral-family models (codestral, devstral, etc.) through custom providers like local vLLM/sglang/llama.cpp or ollama setups.

The problem I have

Mistral models have specific requirements:

  • Tool call IDs must be exactly 9 alphanumeric characters
  • A tool message cannot be directly followed by a user message (needs an assistant message in between)

The existing transform logic only kicked in when providerID === "mistral" or the model name contained mistral. This is smart, but it means custom providers serving codestral/devstral would fail with cryptic API errors, typically for me, after tool calls:

Unexpected role 'user' after role 'tool' Unexpected role 'user' after role 'tool'

The fix I suggest

Two changes:

  1. Added a transforms config option at the provider level, so you can explicitly opt-in:

    {
  "provider": {
    "my-local-llm": {
      "api": "http://localhost:8080/v1",
      "npm": "@ai-sdk/openai-compatible",
      "transforms": "mistral",
      "models": { ... }
    }
  }
}

  2. Extended pattern matching to also catch codestral, devstral, ministral and pixtral model names automatically.

The detection now works as: explicit config > providerID match > model name pattern.

Also updated the DeepSeek detection to follow the same pattern for consistency (supports transforms: "deepseek" now too).

Testing

Added tests covering:

  • Config-based transform activation
  • Pattern matching for each model variant
  • Tool call ID normalization
  • Message sequence fixing
  • Non-Mistral providers unaffected

Happy to adjust the approach if there's a better way to handle this!

**Original Pull Request:** https://github.com/anomalyco/opencode/pull/5053 **State:** closed **Merged:** No --- Thanks for this wonderful project! This PR addresses an issue when running Mistral-family models (codestral, devstral, etc.) through custom providers like local vLLM/sglang/llama.cpp or ollama setups. ## The problem I have Mistral models have specific requirements: - Tool call IDs must be exactly 9 alphanumeric characters - A tool message cannot be directly followed by a user message (needs an assistant message in between) The existing transform logic only kicked in when `providerID === "mistral"` or the model name contained `mistral`. This is smart, but it means custom providers serving codestral/devstral would fail with cryptic API errors, typically for me, after tool calls: ``` Unexpected role 'user' after role 'tool' Unexpected role 'user' after role 'tool' ``` ## The fix I suggest Two changes: 1. Added a transforms config option at the provider level, so you can explicitly opt-in: ```json { "provider": { "my-local-llm": { "api": "http://localhost:8080/v1", "npm": "@ai-sdk/openai-compatible", "transforms": "mistral", "models": { ... } } } } ``` 3. Extended pattern matching to also catch `codestral`, `devstral`, `ministral` and `pixtral` model names automatically. The detection now works as: explicit config > providerID match > model name pattern. Also updated the DeepSeek detection to follow the same pattern for consistency (supports transforms: "deepseek" now too). Testing Added tests covering: - Config-based transform activation - Pattern matching for each model variant - Tool call ID normalization - Message sequence fixing - Non-Mistral providers unaffected Happy to adjust the approach if there's a better way to handle this!
yindo added the pull-request label 2026-02-16 18:16:01 -05:00
yindo closed this issue 2026-02-16 18:16:01 -05:00
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 pull-request
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#11225
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?