Skip to content

Client Integration

Overview

This page describes how to integrate clients and coding agents with the deployed serving stack. MiniMax-M2.7 handles tool calls and reasoning output differently from a typical OpenAI-compatible model, so the description centers on those differences.

Endpoints

Item Value
Gateway port 80
Base URL http://<gateway>:80/v1
Model list GET /v1/models
Chat POST /v1/chat/completions
Authentication None (--api-key not used)

Authentication is outside the scope of the serving stack

The serving stack does not perform authentication. When you expose it externally, handle authentication and authorization at the ingress layer. If you expose it outside the cluster without meeting this requirement, anyone can call the model.

Check the model ID with GET /v1/models. The <model-id> used in the examples below is that value.

Context budget

Item Value
--max-model-len 204,800
Router prefix matching limit 204,800

A request is rejected when the sum of input and output exceeds 204,800. The client has to truncate or summarize the conversation to stay within this limit.

The router's prefix matching limit equals --max-model-len, so prefix-cache-aware routing can predict cache hits across the full context. With autoTune on (the default), the router hashes the prompt in --block-size units (4,096 tokens), so it does not track a prefix shorter than one block or the partial block at the end of a prompt (see Serving Configuration › Prefix reuse unit of 512 tokens).

Parameter Value
temperature 1.0
top_p 0.95
top_k 40

These are the model provider's recommended values, and this model was evaluated with them. Re-measure accuracy when you change them.

Tool call

MiniMax-M2.7 generates tool calls in XML format rather than OpenAI JSON.

<minimax:tool_call>
  <invoke name="tool_name">
    <parameter name="arg">value</parameter>
  </invoke>
</minimax:tool_call>

The server's minimax_m2 parser converts this into the OpenAI-compatible tool_calls field, so the client receives the response in the standard format and does not need to parse the XML directly.

Coding agent integration

mini-swe-agent

Validated; see Reference Design › Status badges for the badge vocabulary. This is the agent that the agent workload of the Target Configuration validation ran. It connects through LiteLLM to the OpenAI-compatible endpoint that vllm serve exposes, as in MiniMax-M2.7 on RBLN NPU.

1
2
export OPENAI_API_BASE=http://<gateway>:80/v1
mini-swe-agent --model openai/<model-id>

Because the server does not require authentication, an arbitrary value in OPENAI_API_KEY also works. When authentication is applied at the ingress, set that value instead.

Other agents

Agent Status
OpenCode Unverified. Configure it as an OpenAI-compatible provider with the base URL above; there is no bundled example
Other OpenAI-compatible clients Connect by changing only the base URL. For the reasoning field, follow steps 3 and 5 of the Integration check sequence.

Integration check sequence

  1. Check the model ID with GET /v1/models.
  2. Send a non-streaming call with a short prompt and confirm that content is returned. Leave max_tokens large enough for the reasoning to finish: the model reasons first, and a response cut off before the reasoning ends returns no content.
  3. In the same call, confirm that reasoning is returned separately. The response does not carry reasoning_content, so a client that reads only that field receives no reasoning. If reasoning is mixed into content, --reasoning-parser is missing.
  4. Make a call that includes tool definitions and confirm that tool_calls is returned in the standard format. If the raw XML is visible in content, --tool-call-parser or --enable-auto-tool-choice is missing.
  5. Include the reasoning field of the previous response in the second request that returns the tool execution result.

For the metrics to watch during operation, see Operations.