In Gemma-4-26B, when using tools in OpenClaw, commands are always output as text to the dialog box.

[JasonQWJ]

<|tool_call>call:tavily:search{something query}<tool_call|>

omlx 3.5 dev1
gemma-4-26b-a4b-it-mxfp4
TurboQuant KV Cache 8-bit

[opticblu]

Having the same issue, think it's related to this message, at least in my case... need to install from homebrew anyway:

2026-04-08 03:51:03,730 - omlx.engine.vlm - INFO - [-] - Structured output is not available in the DMG version (xgrammar requires torch which significantly increases app size). Use the pip or Homebrew version for structured output support.

[JasonQWJ]

Having the same issue, think it's related to this message, at least in my case... need to install from homebrew anyway:

2026-04-08 03:51:03,730 - omlx.engine.vlm - INFO - [-] - Structured output is not available in the DMG version (xgrammar requires torch which significantly increases app size). Use the pip or Homebrew version for structured output support.

So, did you solve the problem by installing via brew? @opticblu

[f-feary]

Tried installing via brew - no success.
May require brew reinstall omlx --with-grammar, testing now

No luck.

[JasonQWJ]

reinstall with brew ，not solve。

[TipKnuckle]

@jundot This commit is making the same mistake the initial tool implementation did in mlx-vlm:
Blaizzy/mlx-vlm#914 and fixed in Blaizzy/mlx-vlm#916
and has been tweaked a few times since then.

The new omlx commit is actively worse than the upstream fix in nested argument structures. The upstream parser handles call:edit{path:<|"|>test.txt<|"|>,edits:[{newText:<|"|>orange<|"|>,oldText:<|"|>apple<|"|>}]} correctly. The new omlx fallback would mangle that same input because _gemma4_args_to_json_robust has no concept of nesting depth.

Strongly recommend to upgrade the mlx-vlm/mlx-lm dependency to pull in the upstream fix, and revert or remove the omlx fallback code. Keeping it means two parsers for the same format, with the omlx one silently producing wrong results on any tool call with nested args. And the marker-stripping block at the bottom of parse_tool_calls will bury the evidence.

[TipKnuckle]

I should also mention @jundot that my PR #614 would potentially fix some of the user's above issues with structured requests from gemma4 when users do not have xgrammar installed - that's exactly why I put in that PR. And I've been running it for a few days now and all is well so far.

[jundot]

@TipKnuckle thanks for the detailed feedback. I went and looked at the mlx-vlm issue and the PR #916 fix to compare.

From what i can tell, the original mlx-vlm bug was two things: the non-greedy (.*?) regex stopping at the first }, and the flat index(":")/index(",") loop treating every colon and comma as top-level delimiters. Both of those completely break on nested structures.

My fallback is taking a different approach though. It uses a recursive regex (?2) for brace extraction (same as mlx-lm 0.31.2), and key quoting uses a lookbehind (?<=[{,]) so only colons after { or , get treated as key separators. I traced through your example (call:edit{path:<|"|>test.txt<|"|>,edits:[{newText:<|"|>orange<|"|>,oldText:<|"|>apple<|"|>}]}) and it actually parses correctly because <|"|> strings get extracted as placeholders before any regex runs.

The one weakness i found is bare string values inside arrays (like call:func{items:[foo,bar]}), but that throws an exception rather than silently mangling output, and the try/except catches it. Feels unlikely in practice since gemma 4 uses <|"|> for strings.

The reason i added this fallback in the first place is that mlx-lm uses \w+ for function names, so something like call:tavily:search{...} from the original report just can't be parsed without it.

On #614, i looked at it but i think it's solving a different problem. It adds parse_json_output() to /v1/responses for structured output formatting when xgrammar is unavailable, while this issue is specifically about tool call parsing not working. Merging #614 alone wouldn't fix the case in this issue since the tool call markers would still fail to parse without the fallback. Could be wrong though, let me know if i'm missing something.

I do agree the marker-stripping at the bottom is not great. Silently removing unparsed markers makes debugging harder, so i'll add warning logging there.

Curious to hear your thoughts on the above.

[TipKnuckle]

@jundot You are totally right here, and I was wrong. I read your commit too hastily. Your code does not have the regex problem the mlx-vlm had. The placeholder extraction handles nesting correctly. And the function name regex problem in mlx-vlm is a real issue. My apologies for not tracing it carefully enough.

Though you got the fix correct, there's a secondary concern about maintenance burden. Like, is this really omlx's problem? This is 300 lines of parser code that exists because upstream has a \w+ where it needs [\w:.-]+. Not sure if an issue is filed in mlx-vlm yet, but it would be worth filing so the fix can be where the parser lives. Then this fallback can eventually be removed.

[JasonQWJ]

Is this the right link?