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

Devstral via LiteLLM OpenAI-compatible fails with invalid_request_message_order on first file edit #3957

New Issue
Open
opened 2026-02-16 17:42:05 -05:00 by yindo · 6 comments
yindo commented 2026-02-16 17:42:05 -05:00
Owner
Copy Link
Copy Source

Originally created by @MaximilianHess on GitHub (Dec 29, 2025).

Originally assigned to: @thdxr on GitHub.

Description

When OpenCode is configured to use Devstral (devstral-2512) through the OpenAI-compatible provider path (LiteLLM OpenAI-compatible endpoint), the run fails as soon as the agent performs an edit operation (i.e., when it tries to edit a file and then continue). The failure occurs immediately at the point where OpenCode attempts to proceed after the edit.

Error message:

litellm.BadRequestError: MistralException - {"object":"error","message":"Expected last role User or Tool (or Assistant with prefix True) for serving but got assistant","type":"invalid_request_message_order","param":null,"code":"3230"}. Received Model Group=devstral-2512 Available Model Group Fallbacks=None

The same workflow does not fail when Devstral is used through the native Mistral provider path (mistral_v1).

Our config:

{
  "$schema": "https://opencode.ai/config.json",

  "tools": {
    "bash": true,
    "edit": true,
    "write": true,
    "read": true,
    "grep": true,
    "glob": true,
    "list": true,
    "lsp": true,
    "patch": true,
    "skill": true,
    "todowrite": true,
    "todoread": true,
    "webfetch": true

  },

  "provider": {
    "ascii-mistral": {
      "npm": "@ai-sdk/mistral",
      "name": "ASCII LiteLLM (Mistral native)",
      "options": {
        "baseURL": "https://llm.ascii.ac.at/mistral/v1",
        "apiKey": "{env:ASCII_AGENTIC_CODING_KEY}"
      },
      "models": {
        "devstral-2512": {
          "name": "devstral-2512 (via LiteLLM)",
          "limit": { "context": 256000, "output": 256000 },
          "tool_call": true,
        },
        "codestral-2508": {
          "name": "codestral-2508 (via LiteLLM)",
          "limit": { "context": 128000, "output": 128000 },
          "tool_call": true,
        },
      }
    },
    "ascii-oai-compatible": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "ASCII LiteLLM",
      "options": {
        "baseURL": "https://llm.ascii.ac.at/v1",
        "apiKey": "{env:ASCII_AGENTIC_CODING_KEY}"
      },
      "models": {
        "devstral-2512": {
          "name": "devstral-2512 (via LiteLLM)",
          "limit": { "context": 256000, "output": 256000 },
          "tool_call": true,
        },
        "codestral-2508": {
          "name": "codestral-2508 (via LiteLLM)",
          "limit": { "context": 128000, "output": 128000 },
          "tool_call": true,
        },
      }
    }
  },

  "model": "ascii-oai-compatible/devstral-2512"
}

Is this likely a opencode or litellm issue?

OpenCode version

1.0.207

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

Originally created by @MaximilianHess on GitHub (Dec 29, 2025). Originally assigned to: @thdxr on GitHub. ### Description When OpenCode is configured to use Devstral (devstral-2512) through the OpenAI-compatible provider path (LiteLLM OpenAI-compatible endpoint), the run fails as soon as the agent performs an edit operation (i.e., when it tries to edit a file and then continue). The failure occurs immediately at the point where OpenCode attempts to proceed after the edit. **Error message:** ```bash litellm.BadRequestError: MistralException - {"object":"error","message":"Expected last role User or Tool (or Assistant with prefix True) for serving but got assistant","type":"invalid_request_message_order","param":null,"code":"3230"}. Received Model Group=devstral-2512 Available Model Group Fallbacks=None ``` The same workflow does not fail when Devstral is used through the native Mistral provider path (mistral_v1). Our config: ```json { "$schema": "https://opencode.ai/config.json", "tools": { "bash": true, "edit": true, "write": true, "read": true, "grep": true, "glob": true, "list": true, "lsp": true, "patch": true, "skill": true, "todowrite": true, "todoread": true, "webfetch": true }, "provider": { "ascii-mistral": { "npm": "@ai-sdk/mistral", "name": "ASCII LiteLLM (Mistral native)", "options": { "baseURL": "https://llm.ascii.ac.at/mistral/v1", "apiKey": "{env:ASCII_AGENTIC_CODING_KEY}" }, "models": { "devstral-2512": { "name": "devstral-2512 (via LiteLLM)", "limit": { "context": 256000, "output": 256000 }, "tool_call": true, }, "codestral-2508": { "name": "codestral-2508 (via LiteLLM)", "limit": { "context": 128000, "output": 128000 }, "tool_call": true, }, } }, "ascii-oai-compatible": { "npm": "@ai-sdk/openai-compatible", "name": "ASCII LiteLLM", "options": { "baseURL": "https://llm.ascii.ac.at/v1", "apiKey": "{env:ASCII_AGENTIC_CODING_KEY}" }, "models": { "devstral-2512": { "name": "devstral-2512 (via LiteLLM)", "limit": { "context": 256000, "output": 256000 }, "tool_call": true, }, "codestral-2508": { "name": "codestral-2508 (via LiteLLM)", "limit": { "context": 128000, "output": 128000 }, "tool_call": true, }, } } }, "model": "ascii-oai-compatible/devstral-2512" } ``` Is this likely a opencode or litellm issue? ### OpenCode version 1.0.207 ### Steps to reproduce _No response_ ### Screenshot and/or share link _No response_ ### Operating System _No response_ ### Terminal _No response_
yindo added the bug label 2026-02-16 17:42:05 -05:00
yindo commented 2026-02-16 17:42:05 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 29, 2025):

This issue might be related to existing LiteLLM and OpenAI-compatible provider issues. Please check:

  • #6244: Response terminates prematurely when using Gemini 3 via LiteLLM (similar LiteLLM provider issue)
  • #5674: Custom OpenAI-compatible provider options not being passed to API calls
  • #2915: LiteLLM error: Anthropic doesn't support tool calling without tools= param

These issues all involve LiteLLM proxies or OpenAI-compatible providers and may provide context for troubleshooting.

Feel free to ignore if your specific case with Devstral's message ordering is a distinct issue.

@github-actions[bot] commented on GitHub (Dec 29, 2025): This issue might be related to existing LiteLLM and OpenAI-compatible provider issues. Please check: - #6244: Response terminates prematurely when using Gemini 3 via LiteLLM (similar LiteLLM provider issue) - #5674: Custom OpenAI-compatible provider options not being passed to API calls - #2915: LiteLLM error: Anthropic doesn't support tool calling without tools= param These issues all involve LiteLLM proxies or OpenAI-compatible providers and may provide context for troubleshooting. Feel free to ignore if your specific case with Devstral's message ordering is a distinct issue.
yindo commented 2026-02-16 17:42:05 -05:00
Author
Owner
Copy Link
Copy Source

@maxious commented on GitHub (Jan 6, 2026):

I had the same issue with vllm; mistral_common.exceptions.InvalidMessageStructureException: Unexpected role 'user' after role 'tool'

The workaround from #2440 is to ensure your model id has the string "mistral" in it; devstral should probably be added too: https://github.com/anomalyco/opencode/blob/e5a868157e7ea89a632a43d6c15fd20128c71144/packages/opencode/src/provider/transform.ts#L58

@maxious commented on GitHub (Jan 6, 2026): I had the same issue with vllm; `mistral_common.exceptions.InvalidMessageStructureException: Unexpected role 'user' after role 'tool'` The workaround from #2440 is to ensure your model id has the string "mistral" in it; devstral should probably be added too: https://github.com/anomalyco/opencode/blob/e5a868157e7ea89a632a43d6c15fd20128c71144/packages/opencode/src/provider/transform.ts#L58
yindo commented 2026-02-16 17:42:05 -05:00
Author
Owner
Copy Link
Copy Source

@eleqtrizit commented on GitHub (Jan 18, 2026):

@MaximilianHess there is a config to ensure alternating roles for litellm for Mistral based models

litellm_settings:
  request_timeout: 300
  drop_params: true
  set_verbose: true
  modify_params: true
  default_litellm_params:
    ensure_alternating_roles: true
    user_continue_message:
      role: user
      content: Please continue.
    assistant_continue_message:
      role: assistant
      content: Please continue.
@eleqtrizit commented on GitHub (Jan 18, 2026): @MaximilianHess there is a config to ensure alternating roles for litellm for Mistral based models ``` litellm_settings: request_timeout: 300 drop_params: true set_verbose: true modify_params: true default_litellm_params: ensure_alternating_roles: true user_continue_message: role: user content: Please continue. assistant_continue_message: role: assistant content: Please continue. ```
yindo commented 2026-02-16 17:42:05 -05:00
Author
Owner
Copy Link
Copy Source

@eleqtrizit commented on GitHub (Jan 18, 2026):

One more thing, I don't know how you'r running vLLM, but only the nightlies support tool calling for OpenCode due to another bug with streaming tool calls, which is what OpenCode makes.

@eleqtrizit commented on GitHub (Jan 18, 2026): One more thing, I don't know how you'r running vLLM, but only the nightlies support tool calling for OpenCode due to another bug with streaming tool calls, which is what OpenCode makes.
yindo commented 2026-02-16 17:42:05 -05:00
Author
Owner
Copy Link
Copy Source

@geoHeil commented on GitHub (Jan 19, 2026):

Works for me!

@geoHeil commented on GitHub (Jan 19, 2026): Works for me!
yindo commented 2026-02-16 17:42:05 -05:00
Author
Owner
Copy Link
Copy Source

@LucasScellos commented on GitHub (Jan 26, 2026):

Hello @MaximilianHess
This issue is resolved in OpenCode v1.1.36 and does not require any changes to your LiteLLM.
The failure was caused by a message ordering mismatch between OpenCode and Mistral-based models leading to invalid sequences after tool calls.
In my case, upgrading OpenCode fixes the problem by relaxing validation after tools calls

@LucasScellos commented on GitHub (Jan 26, 2026): Hello @MaximilianHess This issue is resolved in OpenCode v1.1.36 and does not require any changes to your LiteLLM. The failure was caused by a message ordering mismatch between OpenCode and Mistral-based models leading to invalid sequences after tool calls. In my case, upgrading OpenCode fixes the problem by relaxing validation after tools calls
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 bug
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#3957
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?