MiniMax-M2.7 on mlx_lm.server loads fine and the first API/tool call succeeds

#1
by jarvisfoobi - opened

The model loads fine and the first API/tool-like call succeeds.
But in a multi-step workflow, the model corrupts identifiers between steps.

Example:

  • first response contains correct issue ID:
    6e5bb523-70d4-4fac-a81a-eb0e2864a20e
  • next generated command uses:
    6e5bb523-70d4-4fac-a81a-eb0e28a64a20e

So one character group changes, and the next API call fails with:
{"error":"Issue not found"}

This does not look like:

  • model load failure
  • missing template/tokenizer/config
  • wrong base URL
  • failed first call

It looks like:

  • argument / ID corruption across sequential calls

Question:
Has anyone seen MiniMax-M2.7 on MLX corrupt IDs / tool-call arguments like this in multi-step agent workflows?

If needed, I can share:

  • the exact first successful call
  • the next corrupted call
  • the MLX server settings and chat template setup
baa.ai org

Yeah typical tokenization drift.

The only way around it is to reduce temperature (temp=0) and top_p=1 for those specific tool calls.

There is also a known issue with mlx-lm and MiniMax (see MLX-LM Issue #1145) where the model sometimes omits angle brackets in tool tags. This "messy" output can confuse the model's internal state for the next turn.

To address that you want to ensure your chat_template or system prompt explicitly reinforces the XML structure

Sign up or log in to comment