MiniMax M3 Standard vs Priority: 400-Request Latency Test

Last verified: July 28, 2026

Evidence status: Original paid API experiment run by the MiniMax-AI.chat editorial team: 200 matched prompt pairs and 400 completed MiniMax M3 requests. The downloadable evidence package contains the protocol, raw request-level JSONL, paired CSV, and summary.

Short answer: Priority was not meaningfully faster for the typical request. Median time to first content was 856.9 ms for Priority and 854.7 ms for Standard, while Priority won 102 of 200 matched pairs. Its observed advantage appeared in the slow tail: p95 TTFT fell from 3,371.6 ms to 1,191.8 ms, a 64.7% reduction. However, MiniMax reported cache reads asymmetrically and left zero cache-clean pairs. This is a practical delivered-latency result with automatic caching active, not proof that the tier alone caused the tail difference.

Verdict: Test Priority when long-tail latency threatens a user-facing SLO. Do not buy it expecting every request, or even most requests, to become faster, and reproduce the test with your own production prompt prefixes.

MiniMax M3 Standard vs Priority: key results

Metric	Standard	Priority	Interpretation
Completed requests	200/200	200/200	No API or transport failures
TTFT p50	854.7 ms	856.9 ms	Effectively tied
TTFT p90	1,916.0 ms	1,122.2 ms	41.4% lower with Priority
TTFT p95	3,371.6 ms	1,191.8 ms	64.7% lower with Priority
TTFT p99	4,963.0 ms	1,541.0 ms	69.0% lower with Priority
Maximum TTFT	5,286.2 ms	2,207.1 ms	58.3% lower with Priority
Priority paired win rate	51.0%		102 of 200 pairs
Median paired TTFT delta	−6.2 ms		Negative means Priority was faster
Strict output accuracy	86.0%	86.0%	No aggregate quality advantage
Calculated token cost	$0.01020456	$0.01409220	38.1% more for this sample

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 Standard-versus-Priority result is unchanged. ZIP SHA-256: 996fe3929154104e400a99c678e036340d30405b66497cd9ac63ba5d6f0032f4.

What MiniMax M3 Priority changes

Standard and Priority use the same MiniMax-M3 model. The request changes through service_tier: "standard" or service_tier: "priority". MiniMax describes Priority as preferential request admission, intended to provide faster responses and fewer failures, and prices its matching token categories at 1.5 times Standard. The official documentation does not promise a fixed millisecond improvement. That makes paired measurement more useful than the tier label alone.

Check the current official Chat Completions reference, pay-as-you-go pricing, and our dated MiniMax pricing guide before deployment or purchase.

What we tested

We created 200 deterministic English prompts across ten task families: arithmetic, alphabetical sorting, reference extraction, even-or-odd classification, date normalization, Boolean logic, string reversal, unit conversion, character counting, and severity classification. Every prompt had a locally computed expected answer. Each matched pair launched the same task to the same model concurrently, changing only the requested service tier.

• Model: MiniMax-M3
• Endpoint: POST https://api.minimax.io/v1/chat/completions
• Sample: 200 matched pairs; 400 headline requests
• Dispatch: tiers launched concurrently; client creation order alternated by pair
• Streaming: enabled, including final usage
• Thinking: explicitly disabled
• Sampling: temperature 0.1; top-p 0.95
• Output ceiling: 96 completion tokens
• Pair interval: 900 ms after each completed pair
• Retries: none; every first attempt remained in the data
• Main run: July 28, 2026, 13:04:46 to 13:12:15 UTC

The primary metric was time to first content (TTFT): elapsed time from starting the POST request until the first non-empty assistant content delta. We also recorded response-header time, first-body-byte time, and total stream time. The main pair used the same task and the same run-unique nonce for both tiers. Pair-level comparisons therefore controlled prompt content, but automatic cache behavior did not stay balanced.

Priority improved the observed tail, not the median

Mean TTFT was 891.0 ms for Priority and 1,165.8 ms for Standard, so a comparison of means alone would make Priority look 23.6% faster. The matched distribution is more informative. Median TTFT was 2.1 ms slower for Priority, and the median pair-level delta was just 6.2 ms in Priority’s favor. Priority won 51% of pairs—nearly an even split.

The slow tail was different. Standard reached 1.916 seconds at p90, 3.372 seconds at p95, and 4.963 seconds at p99. Priority recorded 1.122, 1.192, and 1.541 seconds at the same percentiles. Median total stream time was also close: 904.1 ms for Standard and 916.4 ms for Priority. At p95, total time widened to 3,443.8 ms versus 1,240.5 ms.

This pattern can matter to a product team even when the typical request feels identical. A chat or agent interface may value fewer multi-second waits more than a slightly lower median. But the cache imbalance means the numbers describe what this account received under MiniMax’s automatic caching, not a clean causal estimate of admission tier.

Accuracy was equal—and imperfect

Both tiers returned the exact expected answer on 172 of 200 tasks, or 86%. Both were correct on 167 pairs and both were wrong on 23. Standard alone was correct five times; Priority alone was correct five times. The returned strings were identical in 180 pairs.

There was no aggregate quality advantage. Most incorrect responses came from character counting; other misses included a dropped character during reversal, month/day swaps, and one arithmetic error. These short fixtures were designed to keep latency work bounded and comparable, not to estimate M3’s broad intelligence. Their value here is showing that the tier comparison did not hide a systematic accuracy tradeoff.

Why this is not a cache-clean benchmark

In the main 400-request wave, MiniMax reported cached input on 160 of 200 Standard requests (80%) and all 200 Priority requests (100%). Standard returned 40 zero-cache records, six records with 114 cached tokens, and 154 with 128. Every Priority request reported 114 cached tokens. Consequently, none of the 200 matched pairs was cache-clean on both sides.

We then ran two separate ten-pair diagnostics, excluded from the headline 400. In the first, each tier received a different equal-purpose nonce at the beginning of the system message. In the second, the tier label was the first character of that prefix. Both attempts still produced the same distribution: Standard reported cache reads on seven of ten requests, while Priority reported them on ten of ten. Neither pilot produced a cache-clean matched pair.

The persistent 114- and 128-token reports suggest provider-managed or hidden-prefix behavior that a client nonce could not fully control. We therefore do not label Priority causally responsible for every tail difference. This experiment answers a narrower practical question: what latency did Standard and Priority deliver, with the platform’s automatic caching active, for this short matched workload?

Cost: published premium versus this sample

The 400 headline requests used 47,120 input tokens per tier. Standard returned 803 output tokens and Priority returned 609. Using the returned usage and the published rates for M3 requests below 512K input, the calculated cost was $0.01020456 for Standard and $0.01409220 for Priority, or $0.02429676 combined.

Priority cost 38.1% more in this observed batch, not exactly 50%, because output length and reported cache composition differed. Do not treat 38.1% as a pricing rule. At equal billable composition, the published Priority input, output, and cache-read rates are 1.5 times the corresponding Standard rates. The useful business metric is cost per response that meets both latency and correctness targets.

Minimal Node.js matched TTFT test

const endpoint = "https://api.minimax.io/v1/chat/completions";

async function timedTier(serviceTier, prompt) {
  const started = performance.now();
  const response = await fetch(endpoint, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.MINIMAX_API_KEY}`,
      "Content-Type": "application/json",
      Accept: "text/event-stream",
    },
    body: JSON.stringify({
      model: "MiniMax-M3",
      service_tier: serviceTier,
      thinking: { type: "disabled" },
      stream: true,
      stream_options: { include_usage: true },
      temperature: 0.1,
      top_p: 0.95,
      max_completion_tokens: 96,
      messages: [{ role: "user", content: prompt }],
    }),
  });
  if (!response.ok) throw new Error(`HTTP ${response.status}`);

  const reader = response.body.getReader();
  const decoder = new TextDecoder();
  let buffer = "";
  let firstContentMs = null;

  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    buffer += decoder.decode(value, { stream: true });
    const lines = buffer.split(/\r?\n/);
    buffer = lines.pop() ?? "";
    for (const line of lines) {
      if (!line.startsWith("data:")) continue;
      const data = line.slice(5).trim();
      if (!data || data === "[DONE]") continue;
      const event = JSON.parse(data);
      const text = event.choices?.[0]?.delta?.content ?? "";
      if (text && firstContentMs === null) {
        firstContentMs = performance.now() - started;
      }
    }
  }
  return { tier: serviceTier, firstContentMs };
}

const prompt = "Return only the integer result of 731 + 289.";
const pair = await Promise.all([
  timedTier("standard", prompt),
  timedTier("priority", prompt),
]);
console.table(pair);

One pair is not a benchmark. Use many production-shaped prompts, launch each pair concurrently, alternate client creation order, retain first attempts, validate output, and analyze paired deltas as well as p50, p95, p99, and failures. Keep the key server-side. See our OpenAI-compatible API guide and MiniMax M3 guide for implementation context.

Which MiniMax M3 tier should you choose?

Workload	Starting point	Reason
Offline extraction or batch evaluation	Standard	Queues can absorb tail variation
Interactive chat without a hard p95 target	Standard, then measure	The median difference was negligible
Latency-sensitive agent or support UI	Test Priority	The observed p90-p99 tail was tighter
Hard first-token SLO	Priority plus fallbacks	A tier does not replace deadlines and graceful degradation
Long-context workload	Run a separate test	These were short prompts below the 512K price boundary

Limitations

• One dated session, client environment, account, and network path is not a global latency study.
• Tasks were short deterministic English prompts; tools, media, long context, and production concurrency can differ.
• Automatic cache reporting was asymmetric, and no headline or diagnostic pair was cache-clean.
• Concurrent requests reduce clock drift but cannot remove internet and client scheduling noise.
• Strict answer accuracy validates comparable work; it is not a general M3 capability score.
• The calculated cost uses returned usage and published rates, not a tax-inclusive billing ledger.
• Pricing and service behavior can change. Re-run the protocol for your account and workload.

Frequently asked questions

Is MiniMax M3 Priority always faster?

No. Priority won 51% of matched TTFT pairs, and the p50 values were effectively tied. Its observed advantage was lower p90, p95, p99, and maximum latency.

How much lower was Priority p95 TTFT?

Priority p95 TTFT was 1,191.8 ms versus 3,371.6 ms for Standard: 2,179.8 ms, or 64.7%, lower in this run.

Does Priority improve answer quality?

Not in this fixture. Both tiers scored 86% strict accuracy, and each was uniquely correct on five pairs. Priority changes service treatment, not the model ID.

Is Priority exactly 50% more expensive?

The matching published per-token rates are 1.5 times Standard. A particular run’s total can differ when output length, reported cache reads, retries, or input bands differ.

Can this predict my production latency?

No. Use it as a measured reference and reproducible method. Benchmark your prompt lengths, tools, concurrency, region, caching pattern, and success criteria before choosing a tier.

Bottom line

Our 400-request MiniMax M3 Standard vs Priority benchmark found no meaningful median advantage and almost no pairwise majority: Priority won 51%, with a median paired gain of 6.2 ms. It did sharply reduce the observed slow tail—p95 TTFT fell 64.7%, p99 fell 69.0%, and the worst wait fell 58.3%—but asymmetric cache reporting prevents a clean causal claim. Start with Standard for cost-sensitive or queueable work. Test Priority when p95 and p99 latency carry real product value, and decide from production-shaped measurements rather than the tier name.

---

Related guides: MiniMax M3 model and limits · MiniMax API guide · API rate limits · MiniMax pricing

Independence notice: MiniMax-AI.chat is an independent guide and is not owned, operated, sponsored, endorsed by, or affiliated with MiniMax. This experiment used the public paid API. MiniMax did not select the prompts, review the method, supply the results, or approve the conclusions.