Hi Guys I'm running Deepseek v4 flash with GLM5.2 as the agent model. The model will frequently crash or just produce garbled output, especially after something like this:

<｜DSML｜tool name="terminal" parameter name="command" string="true">cd /projects/project1 &&

cd /projects/pro

I thought it was some tool calling incompatibility with DS (but it has not happened when I was running on v1.0.0-rc11) so I disabled native tool calling, but then I get this error:

"Expected exactly one tool call in the message. More than one tool call is not supported. But got 2 tool calls. Content: Let me explore the key files and directories mentioned."

Can I ask if anybody else is running this model without an issue?

Hi @gentle-apple-32922, what provider are you using for deepseek-v4-flash? I noticed this recently and I think that maybe it’s a problem with the LLM provider

Hmmm... I thought so too, I use openrouter (normally with :floor so I get the cheapest provider), but I thought this was an issue so switched to:

{
  "provider": {
    "order": [
      "Relace",
      "StreamLake",
      "GMICloud",
      "DigitalOcean"
    ]
  }
}

Try using ones with fp8

This coincides with me really being able to only have 3 chats and 1 running at a given time (github.com/OpenHands/OpenHands/issues/16690)

Hmm, let me put gpt-5.6-sol on it and see if we can figure it out…

v1.15.0 agent canvas and: {"title":"OpenHands Agent Server","version":"1.42.1","sdk_version":"1.42.1","tools_version":"1.42.1","workspace_version":"1.42.1","build_git_sha":"167c1f924ac8a8acbeb0432bf9b1fcf77d5c2497","build_git_ref":"refs/tags/v1.42.1","python_version":"3.13.13 (main, Apr 7 2026, 204946) [Clang 22.1.1 ]","usable_tools":["file_editor","task_tool_set","task","task_tracker","terminal","workflow_tool_set","workflow","browser_tool_set","edit","list_directory","read_file","write_file","glob","grep","planning_file_editor","canvas_ui_control","launch_child_conversation"], ............... ,"services":{"agent_server":{"description":"The OpenHands Agent Server this agent is running inside. Tool calls (terminal, file_editor, browser, etc.) execute here."}

OK, thanks. I still haven’t identified why this is happening in my examples yet, still looking

Something is going on with context. Recently (v1.14.0 onwards) DS will start going wild. It will output absolute nonsense like:

"OK IM GOING TO OUTPUT NOW. GO. OUTPUT. LET'S JUST DO IT. IM OUTPUTTING. NO IM NOT. 

TIME TO GO NOW. 

I LOVE YOU ALL. GOODBYE. 

OUTPUT THIS NOW. OUTPUTTING? NO NOT YET!"

Quick investigation update: this looks most like a DeepSeek DSML parser/stream-boundary failure, not a context or

max_tokens

limit. The captured bad OpenHands turn had only ~43 completion tokens plus ~47 reasoning tokens, so output exhaustion does not fit. Most relevant upstream reports: • vLLM #53227 — DeepSeek V4 streaming tool calls leak partial DSML closing markup into parsed arguments. This is the closest match to the fragments we saw (

</parameter>

,

</invoke>

,

</｜DSML｜tool_calls>

): https://github.com/vllm-project/vllm/issues/53227 • SGLang #35563 — DeepSeek V3.2/V4 streaming parser loses tool calls and names depending on where the response is split into chunks. Fixed on SGLang

main

, but older deployed versions may still be affected: https://github.com/sgl-project/sglang/issues/35563 • SGLang #14695 — intermittent malformed DeepSeek tool output where expected DSML markers are missing and raw XML-like fragments escape as content: https://github.com/sgl-project/sglang/issues/14695 SGLang #35736 is also related—raw DSML can escape when parsing is disabled—but its

tool_choice: none

trigger does not match our request path as closely: https://github.com/sgl-project/sglang/issues/35736 My current leading hypothesis: the serving backend mishandles a partial DSML chunk, the proxy returns the residue as

reasoning_content

, and OpenHands accepts it as a reasoning-only response rather than retrying it as malformed. We still need selected-provider/backend metadata on the exact bad response to determine whether this is Baseten/vLLM, CoreWeave, or another route. This message was generated by an AI agent (OpenHands) on behalf of Graham Neubig.

@microscopic-jackal-24676, that’s interesting. If you would be able to temporarily downgrade your version and see if you get the same errors or don’t that’d be helpful to identify the issue. I can’t think of anything that I know we changed recently that would be a source of this, but I’ll keep digging.