[minimax M3 Bug] Bug Report: Raw internal tool-call tokens (]<]minimax[>[) leaking into minimax-m3 response content with stop chat

Which inference path did you use?

Other

Inference parameters

No response

Prompt / input

leaking into minimax-m3 response content

Expected behavior

Bug Report: Raw internal tool-call tokens (]<]minimax[>[) leaking into minimax-m3 response content

Actual behavior

when i coding with minimax m3 some times got this and stop chat , some times got continuously
minimax m3 ai:
Let me read that part to confirm.
I need to continue with Step 1. Let me read the run_one function to find where to add the state initialization Tuner.]<]minimax[>[<tool_call>
]<]minimax[>[]<]minimax[>[C:\encher\src\main.rs]<]minimax[>[]<]minimax[>[<start_line>130]<]minimax[>[</start_line>]<]minimax[>[<end_line>165]<]minimax[>[</end_line>]<]minimax[>[
]<]minimax[>[</tool_call>

Additional context

##################
i ask with it claude , say:

Bug Report (from claude): Raw internal tool-call tokens (]<]minimax[>[) leaking into minimax-m3 response content (

---

Summary

When using the minimax-m3 model through the Kilo Gateway / Kimchi API (OpenAI-compatible chat/completions endpoint), the model's internal tool-call boundary tokens (]<]minimax[>[) sometimes leak directly into the visible message.content field instead of being parsed into a proper structured tool_calls array. This produces garbled, unusable output on the client side and causes the calling application (an AI coding agent) to stall or fail mid-task.

Environment

• Model: minimax-m3 (accessed as kimchi/minimax-m3 via Kilo Gateway)
• Endpoint: /v1/chat/completions (OpenAI-compatible), both streaming and non-streaming
• Client: OpenAI-compatible coding agent (opencode), via a local proxy that otherwise forwards requests unmodified
• Frequency: Intermittent — occurs "suddenly" and sometimes repeats for multiple consecutive requests before stopping

Expected behavior

When the model wants to invoke a tool/function, the response should contain a properly structured tool_calls array:

{
  "choices": [{
    "message": {
      "role": "assistant",
      "content": null,
      "tool_calls": [{
        "id": "call_...",
        "type": "function",
        "function": { "name": "...", "arguments": "{...}" }
      }]
    }
  }]
}

Actual behavior

The model's raw internal boundary/delimiter tokens appear directly in message.content as plain text, wrapping what looks like an internal tool-call payload that was never converted into the structured format.

Reproduction examples (captured from live responses)

Example:

Debug derive conflict (BlendMode already has Debug). Fix:]<]minimax[>[ ]<]minimax[>[]<]minimax[>[C:\Users\yumin\Desktop\other\no\cons\tun\src\lib.rs]<]minimax[>[]<]minimax[>[/// Selected configuration for one scene.
#[derive(Debug, Clone, Copy, Debug)]
pub struct ConfigChoice { ... }
]<]minimax[>[]<]minimax[>[cargo test --release --manifest-path "..." --lib 2>&1 | grep -E "(test result|FAILED|error)" | head -10]<]minimax[>[]<]minimax[><]minimax[>[]<]minimax[>[

Observations

1. The ]<]minimax[>[ sequence appears to function as an internal delimiter marking the boundaries of a tool call (target file path, code diff/content, and a shell command each appear as separate segments between markers).
2. In Example 1, the payload between markers matches the shape of a code-edit tool call: file path → old/new code content → a test command → a numeric value (possibly a timeout in ms).
3. This occurs on both streaming and non-streaming requests.
4. Client-side retries of the same request sometimes succeed with a properly formatted tool_calls response, suggesting this is non-deterministic / load- or path-dependent on the gateway or model-serving side rather than a fixed per-request issue.

Impact

• Any client relying on structured tool_calls (coding agents, function-calling integrations) receives unusable output and cannot execute the intended action.
• Silent failures: there is no error status/code returned — the response is 200 OK with malformed content, so clients that don't specifically pattern-match for this can't distinguish it from a legitimate (if unusual) text response.

Suggested fix directions

• Ensure the tool-call parsing/finalization step on the gateway (or model-serving layer) always converts these internal delimiter-wrapped segments into the structured tool_calls field before returning the response, for both streaming and non-streaming paths.
• If the delimiter tokens are ever unparseable for some segments, return an explicit error (e.g. finish_reason: "content_filter" or a 5xx) rather than 200 OK with raw tokens in content, so clients can detect and retry deterministically instead of silently receiving garbage.
• Investigate why this is intermittent — whether it correlates with specific prompt/tool-schema shapes, concurrent load, or a specific upstream replica/version of minimax-m3.

Start by reproducing the issue through the /v1/chat/completions endpoint with both streaming and non-streaming requests, using the minimax-m3 model and tool schemas. Compare successful responses with cases where ]<]minimax[>[ appears in message.content. Done means tool calls are consistently returned in the structured tool_calls field, or malformed payloads produce an explicit detectable error instead of a 200 response with raw tokens.