Parallel tool calls: model mis-attributes (swaps) tool results in the final response

[MagicCube]

Summary

When the model issues multiple tool calls in parallel and then composes its final answer, it can bind each tool's result to the wrong call. In the reproduction below, two parallel weather_report calls each return correctly, but the model swaps the two results in its final summary — reporting City A's weather for City B and vice versa. The error is silent: the output is well-formed and internally self-consistent, just factually wrong.

Environment

• Model: MiniMax-M3 (tested in the Playground)
• Decoding: temperature=1, top_p=1, max_tokens=2048, response_format=text
• Tools: single function weather_report({ city: string }), served over MCP
• Tool-calling mode: parallel

System prompt

<identity>
You're Tara, a helpful assistant that can utilize the tools provided to answer questions and help with tasks.
</identity>

Context

{
  "model": "MiniMax-M3",
  "messages": [
    {
      "role": "system",
      "content": "<identity>\nYou're Tara, a helpful assistant that can utilize the tools provided to answer questions and help with tasks.\n</identity>"
    },
    {
      "role": "user",
      "content": "What's the weather like in Shanghai and Beijing?"
    },
    {
      "role": "assistant",
      "content": "<think>\nThe user wants weather for two cities. I can call both weather tools in parallel since they are independent.\n</think>\n",
      "name": "MiniMax AIMiniMax AIMiniMax AIMiniMax AIMiniMax AI",
      "audio_content": "",
      "tool_calls": [
        {
          "id": "call_function_r5r5j66p96o7_1",
          "type": "function",
          "function": {
            "name": "weather_report",
            "arguments": "{\"city\": \"Shanghai\"}"
          }
        },
        {
          "id": "call_function_r5r5j66p96o7_2",
          "type": "function",
          "function": {
            "name": "weather_report",
            "arguments": "{\"city\": \"Beijing\"}"
          }
        }
      ]
    },
    {
      "role": "tool",
      "tool_call_id": "call_function_r5r5j66p96o7_2",
      "content": "Sunny, 21-29 degrees"
    },
    {
      "role": "tool",
      "tool_call_id": "call_function_r5r5j66p96o7_1",
      "content": "Cloudy, 17-22 degrees"
    },
    {
      "role": "assistant",
      "content": "Here's the current weather in both cities:\n\n- **Shanghai**: ☀️ Sunny, with temperatures ranging from **21–29°C**\n- **Beijing**: ☁️ Cloudy, with temperatures ranging from **17–22°C**\n\nShanghai is warmer and sunny, while Beijing is cooler and overcast. Let me know if you'd like more details or a forecast!",
      "name": "MiniMax AIMiniMax AIMiniMax AI",
      "audio_content": ""
    }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "weather_report",
        "description": "Retrieves a weather report for a specified city. Use this when you need current weather conditions or a concise weather summary for a known city name. Do not use this when geographic coordinates, historical weather data, weather alerts, or multi-day forecasts are required unless those capabilities are explicitly supported elsewhere.",
        "strict": true,
        "parameters": {
          "type": "object",
          "required": [
            "city"
          ],
          "properties": {
            "city": {
              "type": "string",
              "description": "The name of the city for which to retrieve the weather report"
            }
          },
          "additionalProperties": false
        }
      }
    }
  ]
}

Screenshot

Steps to reproduce

1. Send user message: What's the weather like in Shanghai and Beijing?
2. The model emits a <think> block: "The user wants weather for two cities. I can call both weather tools in parallel since they are independent."
3. The model issues two parallel weather_report calls and receives both results.
4. The model composes a final natural-language answer.

Trace

Tool calls and results (ground truth from the tool):

#	Tool call	Result returned
1	weather_report({ "city": "Shanghai" })	Cloudy, 17–22 degrees
2	weather_report({ "city": "Beijing" })	Sunny, 21–29 degrees

Correct mapping:

• Shanghai → Cloudy, 17–22°C
• Beijing → Sunny, 21–29°C

Model's final answer:

• Shanghai: ☀️ Sunny, with temperatures ranging from 21–29°C
• Beijing: ☁️ Cloudy, with temperatures ranging from 17–22°C

Shanghai is warmer and sunny, while Beijing is cooler and overcast.

Expected behavior

The final answer should reflect each tool result bound to the call that produced it:

• Shanghai → Cloudy, 17–22°C
• Beijing → Sunny, 21–29°C

Actual behavior

The two results are swapped. Shanghai is reported with Beijing's result and Beijing with Shanghai's result. The model then adds a (wrong) summarizing sentence that is internally consistent with the swapped data, so nothing in the output flags the error.

Behaviors in other models

• DeepSeek v3.2 also has the same problem, however it has been fixed in both DeepSeek v4 Flash and Pro.
• Doubao v1.8 has this problem too, and now it has been solved in the v2.x models.

Likely root cause

The model appears to associate parallel tool results positionally / by completion (arrival) order rather than by tool_call_id. When parallel calls resolve out of issue-order — common over MCP — the result blocks get attached to the wrong originating call. The distinguishing city argument from each call is not being used to re-anchor the corresponding result.

Impact

• High severity for any agent that uses parallel tool calls: results are confidently mis-attributed with no error signal.
• The failure is data-level (valid format, wrong content), so it passes schema/format validation and can ship to production unnoticed.
• Affects exactly the case parallel calling is meant to optimize: multi-entity queries (multiple cities, users, tickets, files, rows, etc.).
• Particularly risky for single-tool / multi-call fan-out (same tool name, different arguments), where the shared tool name likely increases the chance of confusion.

Suggested checks

• Confirm the model binds each tool result to its originating tool_call_id, not to position or arrival order.
• Add an eval that fires N parallel calls with distinguishable results and asserts the correct argument→result mapping, including when results are returned in shuffled order.
• Specifically cover the same-tool / different-args fan-out pattern (N parallel calls to one tool name).

Workarounds (for users, until fixed)

• Have tools echo their key arguments in the result payload, e.g. {"city": "Shanghai", "weather": "Cloudy, 17–22°C"}, so the model has an in-band anchor instead of relying on call ordering.

[MaxSikorski]

I'll have to reproduce this and great find; great idea for a workaround. Here is my idea on a conceptual Python pattern demonstrating how to implement an in-band anchor workaround, followed by architectural notes for the MiniMax engineering team to address the underlying root cause.

Developer Workaround: In-Band Argument Echoing

Because the model appears to bypass tool_call_id verification and rely strictly on sequence/arrival order, you can force the attention weights to self-correct by injecting the target entity directly into the tool's response payload.

Note: This is a conceptual pattern for integration pipelines to illustrate the structural logic, as I am currently prepping local tests for this behavior.

# ❌ VULNERABLE: Lacks context anchors; high risk of parallel sequence swapping
def get_weather(city: str) -> dict:
    return {"temp": "22C", "condition": "Cloudy"} 
    # Output token stream lacks an explicit binding token for the city within the object layer

#  SAFE: Forces the model to anchor the data to the correct entity
def get_weather_safe(city: str) -> dict:
    return {
        "__anchor_context": f"Results specifically for {city}", 
        "temp": "22C", 
        "condition": "Cloudy"
    }
    # Output if city="Shanghai": {"__anchor_context": "Results specifically for Shanghai", "temp": "22C", "condition": "Cloudy"}

By introducing an explicit "__anchor_context" key at the root of the JSON payload, you force the entity tokens into the active context window immediately adjacent to the data values. This text-level hint acts as an anchor, overriding the broken ID-tracking logic during the final summary generation.

---

Technical Recommendations for the MiniMax Engineering Team

This behavior indicates a regression in post-training alignment or a decoupling in the API orchestration layer during multi-turn tool tracking. Below are three avenues to investigate for a permanent resolution:

1. SFT Loss Weighting & Penalty Constraints

During Supervised Fine-Tuning (SFT) for parallel tool invocation, the loss function must heavily penalize cross-contamination. The model should incur massive loss when it emits a natural language response associated with tool_call_id_A while extracting values localized within the context block belonging to tool_call_id_B.

2. Multi-Turn Attention Routing & KV-Cache Management

Since MiniMax M3 utilizes a highly optimized Sparse Attention (MSA) architecture, verify that the attention masks or routing buckets are not inadvertently blurring token relationships during parallel tool returns. If the KV-cache states for separate tool outputs are mixed or lack distinct positional differentiation before hitting the final generation tokens, the attention mechanism will naturally default to raw arrival order rather than logical ID pairing.

3. API-Layer System Prompt Enforcement

As an immediate system-level hotfix before re-training, the hidden base system prompt should contain explicit negative constraints targeting this failure mode:

You must strictly pair the data inside a tool response with its corresponding originating tool_call_id. Do not assume sequence order matches execution order.