This project is amazing work, first of all- and has been my daily driver. Using the Q2 on a Mac Studio M4 Max 128 GB. But I have noticed this recurring issue:
#167 was closed (same issue) but the fix leaves sessions in a worse state than the original bug. When the model produces a DSML tool call without closing first, the server now logs "thinking not closed, ignoring DSML in reasoning" and returns finish=stop with no tool calls and no useful text. Opencode and pi both just stop and sit there until I nudge it. Typically I explain the tool call failed and to try again- or run the command myself. Not ideal.
Here's a log snip from a session:
ds4-server: thinking not closed, ignoring DSML in reasoning
0531 21:29:28 ds4-server: chat ctx=104990..105039:49 gen=80 TOOLS THINKING finish=stop 4.779s
Opencode shows that the model intended the tool call. (I have not seen a model "thinking about tool calling" and generating the tool token sequence. That seems very unlikely.) Most probable is that it just dropped the closing tag. The fix seems like: when is absent but DSML is present, treat the DSML start as an implicit whoopsie thinking boundary instead of discarding the call. Pre-DSML text becomes reasoning, DSML parses normally.
I checked open PRs and PR #273 does fix this but bundles a lot of other stuff (ASCII DSML variants, tool result reordering, argument unwrapping... none of which I have issues with personally). I made a fork with a targeted change and it's about 20 lines in parse_generated_message_ex. I'm can send the PR if that sounds good.
Thanks
This project is amazing work, first of all- and has been my daily driver. Using the Q2 on a Mac Studio M4 Max 128 GB. But I have noticed this recurring issue:
#167 was closed (same issue) but the fix leaves sessions in a worse state than the original bug. When the model produces a DSML tool call without closing first, the server now logs "thinking not closed, ignoring DSML in reasoning" and returns finish=stop with no tool calls and no useful text. Opencode and pi both just stop and sit there until I nudge it. Typically I explain the tool call failed and to try again- or run the command myself. Not ideal.
Here's a log snip from a session:
Opencode shows that the model intended the tool call. (I have not seen a model "thinking about tool calling" and generating the tool token sequence. That seems very unlikely.) Most probable is that it just dropped the closing tag. The fix seems like: when is absent but DSML is present, treat the DSML start as an implicit whoopsie thinking boundary instead of discarding the call. Pre-DSML text becomes reasoning, DSML parses normally.
I checked open PRs and PR #273 does fix this but bundles a lot of other stuff (ASCII DSML variants, tool result reordering, argument unwrapping... none of which I have issues with personally). I made a fork with a targeted change and it's about 20 lines in parse_generated_message_ex. I'm can send the PR if that sounds good.
Thanks