We sent 300 live, paid requests to MiniMax M3 through three different API surfaces. The practical result was short deterministic, non-streaming text-output semantic parity on this frozen dataset: Chat Completions, Responses, and Anthropic Messages each returned 100 correct answers from 100 requests, with no API or format failures. Across the 100 matched endpoint triplets, normalized text was exactly identical 97% of the time. The remaining three triplets were not model disagreements: they contained the same valid JSON keys and values, differing only in insignificant whitespace.
This is the distinction that matters for an integration decision. The benchmark measured 100% semantic accuracy and 97% normalized textual agreement. If your application parses structured output instead of comparing raw strings byte for byte, all three MiniMax M3 interfaces behaved equivalently on this test set. The endpoint choice can therefore be based mainly on the SDK and request format that best fit your stack.
The result at a glance
| Metric | Chat Completions | Responses | Anthropic Messages |
|---|---|---|---|
| Requests | 100 | 100 | 100 |
| API success | 100% | 100% | 100% |
| Format valid | 100% | 100% | 100% |
| Semantic accuracy | 100% | 100% | 100% |
| Mean latency | 1,399 ms | 1,404 ms | 1,320 ms |
| p50 latency | 1,012 ms | 1,001 ms | 1,018 ms |
| p95 latency | 3,630 ms | 3,630 ms | 3,024 ms |
| Mean effective input tokens | 206.4 | 206.4 | 206.4 |
| Mean output tokens | 8.68 | 8.74 | 8.61 |
| Corrected estimated cost, 100 requests | $0.00463080 | $0.00462120 | $0.00458088 |
| Fastest within matched triplets | 35 | 24 | 41 |
Bottom line: all 300 requests succeeded and were scored correct. All three endpoints were semantically identical in 100 of 100 triplets; 97 of 100 were also exact textual matches after ordinary text normalization.
What “API parity” means in this test
MiniMax exposes the same model through multiple interface conventions. The OpenAI-style Chat Completions endpoint accepts a message array. The Responses endpoint separates instructions from input. The Anthropic-compatible Messages endpoint uses Anthropic-shaped system and message fields. These formats make migration easier, but compatibility at the request-schema level does not automatically prove that the returned answer will be the same.
| Capability | Status |
|---|---|
| Short deterministic text output | Tested |
| Non-streaming requests | Tested |
| Chat / Responses / Anthropic endpoints | Tested |
| Tools | Not tested |
| Multimodal input | Not tested |
| Streaming | Not tested |
| Server Tools | Not tested |
| Long-context and multi-turn behavior | Not tested |
| Priority routing | Not tested |
We defined parity in two layers. First, semantic accuracy asks whether each response satisfies deterministic ground truth. Arithmetic and classification outputs had to match exactly after basic normalization. Ordered transformations and date-format tasks had explicit expected strings. JSON extraction had to return a directly parseable object containing the exact expected values. Second, text agreement asks whether all three extracted response strings are identical after text normalization. The first measure reflects application correctness; the second catches presentational differences.
That two-layer scoring explains the headline numbers. Every endpoint scored 100/100 for semantic accuracy, and every matched triplet had three correct answers. Exact normalized text agreement was 97/100 because three JSON extraction repetitions inserted spaces after commas and colons on one endpoint while another returned compact JSON. For example, {"open": false} and {"open":false} parse to precisely the same value. Those three cases were formatting variations only—not incorrect fields, missing data, or divergent reasoning.
Methodology: 50 tasks, repeated twice, across three endpoints
The live run completed on July 28, 2026. We built a balanced dataset of 50 deterministic cases: 10 arithmetic tasks, 10 sentiment classifications, 10 ordered transformations, 10 JSON extractions, and 10 date-format compliance tasks. Every case was executed twice. For each case and repetition, the harness launched one request to each endpoint concurrently, producing 100 endpoint triplets and 300 billable requests.
- Model:
MiniMax-M3 - Service tier: Standard
- Sampling: temperature 0.1 and top-p 0.95
- Output allowance: an equivalent 256-token maximum on every endpoint
- Generation mode: non-streaming, with thinking or reasoning disabled
- Timeout: 120 seconds per request
- Dispatch control: the three requests in each triplet started concurrently, while endpoint creation order rotated between triplets
Concurrent dispatch reduced the chance that short-term network or server conditions would favor an endpoint simply because it always ran first. Rotating the creation order added another small protection against client-side ordering effects. We waited one second between triplet groups. This was a parity experiment rather than a maximum-throughput load test, so the latency figures describe these controlled individual requests, not the capacity of a production deployment under sustained concurrency.
Each response was also checked independently for transport success, parseability, API status, output format, and task correctness. No endpoint required retries to produce the reported 100% success rate. The downloadable artifact linked below contains the sanitized request-level results, triplet comparison table, run manifest, and corrected summary so the aggregate claims can be audited.
Equivalent payloads for the three MiniMax M3 APIs
The prompt, sampling controls, model, service tier, and output limit remained constant. Only the fields required by each interface changed. This is the mapping used in the benchmark:
| Interface | Path | System and user mapping | Reasoning control | Output-limit field |
|---|---|---|---|---|
| Chat Completions | /v1/chat/completions | System message + user message in messages | thinking.type = "disabled" | max_completion_tokens |
| Responses | /v1/responses | instructions + input | reasoning.effort = "none" | max_output_tokens |
| Anthropic Messages | /anthropic/v1/messages | system + one user message | thinking.type = "disabled" | max_tokens |
const API_KEY = process.env.MINIMAX_API_KEY;
const BASE_URL = "https://api.minimax.io";
function payloadFor(api, system, prompt) {
const common = {
model: "MiniMax-M3",
service_tier: "standard",
temperature: 0.1,
top_p: 0.95,
stream: false
};
if (api === "chat") {
return {
path: "/v1/chat/completions",
body: {
...common,
thinking: { type: "disabled" },
reasoning_split: true,
max_completion_tokens: 256,
messages: [
{ role: "system", content: system },
{ role: "user", content: prompt }
]
}
};
}
if (api === "responses") {
return {
path: "/v1/responses",
body: {
...common,
reasoning: { effort: "none" },
max_output_tokens: 256,
instructions: system,
input: prompt
}
};
}
return {
path: "/anthropic/v1/messages",
body: {
...common,
thinking: { type: "disabled" },
max_tokens: 256,
system,
messages: [{ role: "user", content: prompt }]
}
};
}
async function callMiniMax(spec) {
const response = await fetch(BASE_URL + spec.path, {
method: "POST",
headers: {
Authorization: `Bearer ${API_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify(spec.body)
});
if (!response.ok) throw new Error(`${spec.path}: HTTP ${response.status}`);
return response.json();
}
const system = "Return only the requested answer.";
const prompt = "Calculate 37 × 14.";
const specs = ["chat", "responses", "anthropic"]
.map(api => payloadFor(api, system, prompt));
const results = await Promise.all(specs.map(callMiniMax));The response extraction step is necessarily endpoint-specific: Chat Completions reads the assistant message, Responses reads its output text structure, and Anthropic Messages reads text content blocks. Normalize those shapes into one internal type at the adapter boundary. Downstream application code can then work with a consistent object regardless of which interface you select.
How to reproduce a fair comparison
Save one request-level record for every call: endpoint, case ID, repetition, dispatch position, start and finish timestamps, HTTP status, raw text, parsed output, token-usage fields, and any error. Join records by a stable triplet ID so that each prompt is compared only with its two matched calls. Predeclare the ground truth, normalizer, parser, and pass/fail rules before running the benchmark; changing them after seeing outputs turns evaluation into interpretation.
Dispatch each matched trio concurrently under identical model settings, timeout, service tier, and output cap. Rotate creation or launch order across triplets to prevent a fixed first-request advantage. Evaluate JSON twice: parse it and compare the resulting values for semantic accuracy, then separately compare normalized strings for literal agreement. That distinction keeps harmless whitespace or serialization differences from being mislabeled as model errors.
Keep credentials in environment variables, never in the dataset. Before publishing artifacts, remove authorization headers, request IDs that could expose account data, and any logs containing secrets or private prompts. Preserve raw usage fields as well as normalized effective input tokens, document the normalization formula, and recalculate estimated costs whenever the provider changes rates. A reproducible report should therefore ship the protocol version, sanitized request-level rows, scoring code, and the exact pricing assumptions used for that run.
Latency was close at the median
Median latency clustered tightly around one second: 1,012 ms for Chat Completions, 1,001 ms for Responses, and 1,018 ms for Anthropic Messages. A 17 ms spread between the fastest and slowest median is too small to drive an architecture decision here. Mean latency was also similar, although the Anthropic-compatible endpoint recorded the lowest mean at 1,320 ms versus 1,399 ms for Chat and 1,404 ms for Responses.
The tail showed the largest difference. Anthropic Messages had a 3,024 ms p95, while Chat and Responses were both approximately 3,630 ms. It was the fastest member of 41 triplets, compared with 35 for Chat and 24 for Responses. Still, that is not proof that the Anthropic-shaped route is inherently faster. This was one 300-request run from one client location, on one day, using short deterministic prompts. The endpoints may share substantial infrastructure, and ordinary internet variation can move results at this scale. For a latency-sensitive product, repeat the experiment from your deployment region with production-sized prompts and streaming settings.
Methodology correction
Usage fields are not directly comparable until cache accounting is normalized. Chat Completions and Responses reported input totals that included cache-read tokens. In the Anthropic-compatible response, input_tokens excluded cache reads, which were reported separately. Treating only that first Anthropic field as total input would undercount usage and make the endpoint appear artificially cheaper.
We corrected the summary by defining effective Anthropic input as input_tokens + cache_read_input_tokens + cache_creation_input_tokens. Cache-read tokens retained the published cache-read price in the cost calculation; they were not repriced as ordinary input. After normalization, every endpoint averaged exactly 206.4 effective input tokens per request, or 20,640 across its 100 requests.
The corrected estimated costs were $0.00463080 for Chat Completions, $0.00462120 for Responses, and $0.00458088 for Anthropic Messages. The total for all 300 requests was $0.01383288. The small endpoint differences came from observed output-token counts and cache categories, not different prompt content. Rates can change, so use the official MiniMax pay-as-you-go pricing page for budgeting rather than treating this historical run total as a quote.
Which endpoint should you choose?
For this dataset, correctness does not break the tie. Choose Chat Completions if your application already uses OpenAI-compatible message arrays or depends on mature chat-oriented client abstractions. Choose Responses if your integration is built around the newer instructions-and-input pattern. Choose Anthropic Messages when an Anthropic-compatible SDK or existing Messages adapter makes migration materially simpler. Our MiniMax Anthropic-compatible API guide covers that route in more detail.
Whichever interface you select, avoid comparing raw JSON strings in production. Parse JSON, validate its schema, and compare values. Also keep endpoint-specific response extraction and usage normalization inside a small adapter. That design makes switching interfaces far less disruptive and protects analytics from accounting differences. For broader setup material, see our MiniMax API guide, MiniMax M3 model overview, and MiniMax pricing guide. The primary references are MiniMax’s official API overview and official M3 model page.
Package maintenance — verified July 30, 2026: The repaired ZIP restores the generated datasets and schema required by the offline validator and adds a verified internal SHA-256 manifest. The published benchmark result is unchanged. ZIP SHA-256: ea47ff83c2351acc08c91ad8a8fd815e159359bfda48cd0643f9228d99eceea3.
Limitations
- Accuracy is scoped to this dataset. A 100% score means all 50 deterministic cases, repeated twice, passed. It does not imply universal MiniMax M3 accuracy on open-ended reasoning, long context, coding, or domain-expert tasks.
- The prompts were intentionally short. Effective input averaged 206.4 tokens and output averaged fewer than nine tokens. Long responses may expose different latency, formatting, or token-accounting behavior.
- This was non-streaming Standard tier. Time to first token, streaming smoothness, Priority-tier behavior, tools, multimodal input, and multi-turn conversation state were outside the protocol.
- Latency is a snapshot. One location and one run cannot establish a permanent endpoint ranking. Regional routing, client networking, time of day, and service load can change the distribution.
- Textual agreement was deliberately strict. It treated internal JSON spacing as a string difference even when parsed objects were identical. That makes the 97% figure useful for spotting serialization variation, but 100% semantic accuracy is the more relevant application metric.
Frequently asked questions
Did one MiniMax M3 endpoint produce more correct answers?
No. Chat Completions, Responses, and Anthropic Messages each returned 100 correct responses from 100 requests. All 100 matched triplets contained three correct answers.
Why was exact agreement 97% if accuracy was 100%?
Three JSON triplets differed only in whitespace. One response used spaces after separators, while another used compact JSON. Every version parsed successfully and contained the same keys, strings, booleans, and values. There were no semantic disagreements.
Was the Anthropic-compatible endpoint cheaper?
Its corrected estimated cost was slightly lower in this test, but the difference across 100 short requests was less than five hundredths of a cent. That difference is too small to justify choosing an endpoint. Normalize cache-related usage fields and apply the current official rates to your own workload.
Which endpoint was fastest?
The Responses endpoint had the lowest median latency at 1,001 ms. Anthropic Messages recorded the lowest mean, the lowest p95, and the highest number of fastest-triplet wins. The differences were not large enough to declare a universal winner, so you should benchmark the endpoints from your own region using representative prompts.
Can I migrate without rewriting my application?
If your application already uses OpenAI- or Anthropic-compatible requests, MiniMax’s compatible endpoints can substantially reduce the required changes. However, you should still verify supported fields, handle each endpoint’s response structure correctly, normalize usage reporting, and run regression tests for the features your application uses.
Methodology note: This article reports the completed Protocol 1.0.0 run and uses the corrected summary for effective input tokens and estimated cost. Raw artifacts were sanitized before publication. No response was manually changed to improve its score.