MiniMax API Rate Limits: RPM, TPM, and Concurrency

Last verified: August 26, 2026. Music eligibility and the published Music rate-limit row were rechecked separately; the numeric row remains visible in MiniMax’s central table but does not grant new-user access.

The published MiniMax API rate limit for MiniMax-M3 is 200 requests per minute (RPM) and 10,000,000 total tokens per minute (TPM). MiniMax publishes 500 RPM and 20,000,000 TPM for the listed M2-series models. Media APIs use separate controls: legacy Hailuo Video Generation allows 5 RPM on the free tier and 20 RPM on the paid tier; MiniMax-H3 Video Generation V2 allows 2 concurrent tasks on the free tier and 15 on the paid tier; T2A allows 60 RPM, image-01 allows 10 RPM, and MiniMax’s central table continues to publish 120 RPM plus 20 CONN for the listed music models. These are technical ceilings for an eligible key, not evidence that a new account can access Music or Lyrics APIs.

Those numbers are not a promise that every key will always sustain the table maximum. MiniMax says limits depend on the model and interface; commercial packages can assign different RPM, Token Plan traffic can be dynamically throttled, and negotiated accounts can have different entitlements. Treat the console, your contract, and observed responses as the source of truth for a particular credential.

This independent guide explains the official tables, the difference between RPM, TPM, concurrency, and subscription quota, how to calculate realistic throughput, and how to build a queue with 429-aware exponential backoff. For endpoints and request formats, use the broader MiniMax API guide. For credentials and regional hosts, see MiniMax API keys and base URLs.

MiniMax API rate limits: quick reference

API familyModel or operationPublished RPMPublished TPMPublished concurrency
TextMiniMax-M320010,000,000Not specified
TextListed M2-series models50020,000,000Not specified
VideoMiniMax-H3 / Video Generation V2Not specifiedNot specified2 free / 15 paid CONN
VideoLegacy Hailuo 2.3 / 2.3 Fast / 025 free / 20 paidNot specifiedNot specified
SpeechT2A speech models60Not specifiedNot specified
SpeechVoice Cloning60Not specifiedNot specified
SpeechVoice Design20Not specifiedNot specified
Imageimage-0110Not specifiedNot specified
MusicMusic 3.0 / 2.6 / Cover / 2.0120Not specified20 CONN
File and other operationsFile management, model listing, and operations absent from the central tableNot specifiedNot specifiedNot specified
Official public limits verified August 26, 2026. A blank official metric is shown as “Not specified,” not assumed to be unlimited.

Music access clarification — August 20, 2026: MiniMax says paid Music Generation and Lyrics Generation APIs are unavailable to new users, existing paying users can continue, and the free music model IDs are discontinued. The official rate-limit table still publishes 120 RPM and 20 CONN, while the operation schema still lists free IDs as available. Treat this as an unresolved official-documentation conflict: the numeric row describes limits for an entitled caller; it does not grant entitlement.

Important: “Not specified” does not mean “unlimited.” MiniMax publishes concurrency for MiniMax-H3 Video Generation V2—2 free / 15 paid—and 20 CONN for Music Generation. For every other metric shown as “Not specified,” use a conservative client-side cap and increase it only after measuring stable behavior.

The table above comes from the international English documentation at platform.minimax.io. The rate-limit page does not publish a separate Mainland China table or state that every regional account has identical entitlements. Confirm the effective limit in the console or contract associated with the key.

On this page

RPM vs TPM vs concurrency vs quota

ControlWhat it limitsPractical example
RPMRequests accepted within a one-minute period200 RPM allows at most 200 M3 calls per minute before another constraint is considered.
TPMTotal input plus output tokens processed within a one-minute periodA 10,000,000 TPM budget supports 125 calls averaging 80,000 total tokens, even though the RPM ceiling is 200.
Concurrency / CONNRequests or connections in progress at the same timeMiniMax-H3 permits at most 2 concurrent V2 tasks on the free tier or 15 on the paid tier; Music Generation publishes 20 CONN.
QuotaUsage available in a longer plan windowA Token Plan can have 5-hour and weekly quota windows even when an individual request is also subject to RPM or TPM throttling.
TPSGenerated output tokens per second after output beginsTPS describes generation speed. It is not the same as the account-level TPM allowance.

MiniMax defines TPM as input tokens plus output tokens. A large prompt can therefore exhaust TPM before RPM. Streaming changes how the response arrives, but it does not remove the request or token budget. Likewise, a fast model can have high output TPS while your account remains limited by RPM, TPM, or an independent quota window.

Design as if calls that share one MiniMax key also share its effective traffic budget unless the console or contract explicitly says otherwise. A limiter inside only one web server cannot protect the total budget when three other servers use the same key.

Text-model RPM and TPM table

The following values reproduce MiniMax’s public LLM rate-limit table as verified on August 26, 2026.

Model IDRPMTPM (input + output)Even request spacing
MiniMax-M320010,000,000About one request every 300 ms
MiniMax-M2.750020,000,000About one request every 120 ms
MiniMax-M2.7-highspeed50020,000,000About one request every 120 ms
MiniMax-M2.550020,000,000About one request every 120 ms
MiniMax-M2.5-highspeed50020,000,000About one request every 120 ms
MiniMax-M2.150020,000,000About one request every 120 ms
MiniMax-M2.1-highspeed50020,000,000About one request every 120 ms
MiniMax-M250020,000,000About one request every 120 ms
Verified August 26, 2026. The spacing column is an engineering calculation, not an additional MiniMax policy.

Even spacing is safer than sending the whole minute’s allowance in a burst. For example, a client targeting 200 M3 RPM should pace requests around 3.33 per second and reserve headroom for retries. A practical initial target is 80–90% of the published figure, then adjust using observed throttling and latency. That headroom is an operational recommendation, not an official MiniMax entitlement.

Video, speech, image, and music rate limits

APICovered models or operationPublished RPMPublished CONNEven submission pace
Video Generation V2MiniMax-H3Not specified2 free / 15 paidCap in-flight tasks at the tier limit
Video Generation (V1)MiniMax-Hailuo-2.3, MiniMax-Hailuo-2.3-Fast, MiniMax-Hailuo-025 free / 20 paidNot specifiedAbout one request every 12 seconds free or 3 seconds paid
T2Aspeech-2.8-turbo, speech-2.8-hd, speech-2.6-turbo, speech-2.6-hd, speech-02-turbo, speech-02-hd60Not specifiedOne request per second
Voice CloningVoice-cloning operation60Not specifiedOne request per second
Voice DesignVoice-design operation20Not specifiedOne request every 3 seconds
Image Generationimage-0110Not specifiedOne request every 6 seconds
Music GenerationMusic-3.0, Music-2.6, Music-Cover, Music-2.012020Two requests per second, subject to CONN
Central MiniMax rate-limit table verified August 26, 2026. Music names reproduce the display labels in that table; use the exact case-sensitive model ID from the operation reference when sending a request.

Media workloads need both submission-rate and in-flight controls. Legacy Hailuo V1 is governed by 5 RPM free or 20 RPM paid; MiniMax-H3 V2 is governed by 2 concurrent tasks free or 15 paid. Do not apply the Hailuo RPM value to H3 or the H3 concurrency value to legacy Hailuo.

The central MiniMax table does not assign a standalone public RPM, TPM, or CONN value to file management, model-listing calls, Video Agent, or every task-status route. Apply a conservative queue to undocumented operations and confirm the entitlement for the account; their absence from the table is not evidence of unlimited access.

Use separate queues for text, video, speech, image, and music. A large speech batch should not block an interactive M3 request, and a video status poller should not share an unrestricted worker pool with creation calls. For asynchronous media, store each returned task ID and poll at a measured interval rather than resubmitting the generation request.

Why an audio or video package may show different RPM

MiniMax’s central guide publishes 60 RPM for T2A, 5 RPM free / 20 RPM paid for legacy Hailuo generation, and 2 free / 15 paid concurrent tasks for MiniMax-H3 V2. Separate commercial package pages can publish different Hailuo RPM values, so use the entitlement attached to the credential.

Audio Subscription RPM

Audio tierPublished RPM
Starter10
Standard50
Pro200
Scale500
Business800
Customer PricingDescribed by MiniMax as unlimited RPM/TPM; confirm contractual controls
Audio package table verified August 26, 2026. Prices and monthly points are intentionally omitted because this page is about traffic limits.

Video Package RPM

Video packagePublished RPM
Standard20
Pro30
Scale40
Business50
Custom PricingDescribed by MiniMax as unlimited RPM/TPM; confirm contractual controls
Video package table verified August 26, 2026.

Check the entitlement attached to the key rather than copying a limit from another account. Package cost, included points, and model pricing are covered separately in our MiniMax pricing guide.

Token Plan: rate limits are not the same as usage quota

A Token Plan Subscription Key has an included usage pool controlled by 5-hour rolling and weekly windows. That longer-window quota is separate from short-term RPM and TPM throttling. Reaching a quota window can produce a usage-limit response even if the client is sending slowly.

MiniMax’s Token Plan FAQ says requests may be throttled when RPM or TPM is exceeded, that the short-term restriction typically clears in about one minute, and that limits may tighten during peak traffic. The same page gives approximate simultaneous agent guidance during dynamically adjusted peak periods: Plus 3–4 agents, Max 4–5, and Ultra 6–7. These figures are traffic guidance for Token Plan agents, not a published HTTP API CONN value.

SituationLikely controlCorrect response
A burst fails, then succeeds after a short pauseRPM, TPM, growth control, or dynamic throttlingQueue, pace, and retry with jittered backoff.
Subscription usage bar is exhausted5-hour or weekly Token Plan quotaWait for quota recovery, use eligible purchased Credits, upgrade, or use a pay-as-you-go key.
More parallel agents fail during peak trafficDynamic Token Plan traffic controlReduce active agents and serialize lower-priority work.
Pay-as-you-go request reports insufficient balanceBilling balance, not RPMCheck balance and the credential’s Team or region.

How to calculate MiniMax throughput

For a text model, calculate the maximum request rate from both RPM and TPM:

token_limited_requests_per_minute = floor(TPM / average_total_tokens_per_request)

effective_requests_per_minute = min(
  RPM,
  token_limited_requests_per_minute
)

M3 example: 50,000 total tokens per request

RPM ceiling             = 200 requests/minute
TPM ceiling             = 10,000,000 tokens/minute
Average request         = 50,000 input + output tokens
Token-limited rate      = 10,000,000 / 50,000 = 200 requests/minute
Effective table ceiling = min(200, 200) = 200 requests/minute

M3 example: 80,000 total tokens per request

Token-limited rate      = 10,000,000 / 80,000 = 125 requests/minute
Effective table ceiling = min(200, 125) = 125 requests/minute

The 80,000-token workload is TPM-bound. Adding more workers cannot raise sustainable throughput above approximately 125 calls per minute unless the average token count falls or the account limit changes.

Include latency and client concurrency

A client must also have enough workers to keep the intended rate in progress. Use this planning approximation:

client_capacity_rpm = (client_concurrency × 60) / average_latency_seconds

planned_rpm = min(
  published_RPM,
  floor(TPM / average_total_tokens),
  client_capacity_rpm
)

If average end-to-end latency is 15 seconds and the application allows 20 requests in flight, client capacity is approximately 80 RPM. Raising the client cap to 50 would theoretically support 200 RPM at that latency, but MiniMax does not publish an M3 concurrency allowance in the central table. Do not jump directly to 50; ramp gradually, watch errors, and leave capacity for retries.

A safe queueing design

  1. Classify the job. Put text, speech, image, video, and music into separate queues with their own limits.
  2. Estimate cost before admission. For text, reserve estimated input tokens plus the maximum intended output. Reconcile with the response’s usage values.
  3. Pace instead of burst. Spread requests across the minute and keep 10–20% operating headroom.
  4. Cap in-flight work. Use a client concurrency limit even where MiniMax does not publish one.
  5. Retry only retryable failures. Apply exponential backoff with jitter to throttling and temporary server failures.
  6. Protect interactive traffic. Give user-facing calls a separate priority lane from batch processing.
  7. Coordinate across instances. If several processes share a key, keep counters in a shared store such as Redis rather than creating an independent full-budget limiter in each process.
  8. Use idempotent job handling. Persist returned media task IDs. If a response is lost, verify job state before repeating a generation POST, because a duplicate request may create duplicate work.

For an M3 service, a conservative deployment might start with 180 RPM and 9,000,000 TPM, not the full public values. For legacy Hailuo at 5 RPM, submit at roughly 12–15-second intervals; at 20 RPM, start near 3–4 seconds. For MiniMax-H3 V2, cap outstanding tasks at 2 free or 15 paid; the official table does not publish an H3 RPM. These are starting policies; measure the workload and the account’s effective behavior.

Node.js: RPM, TPM, concurrency, and backoff

This dependency-free Node.js example uses the OpenAI-compatible Chat Completions route, a conservative M3 budget, a local queue, and jittered exponential backoff. It checks both HTTP 429 and MiniMax application-level codes. Use Node.js 18 or later for built-in fetch. Because the example uses top-level await, save it as rate-limit-demo.mjs and run node rate-limit-demo.mjs, or enable ECMAScript modules with "type": "module" in package.json.

const API_KEY = process.env.MINIMAX_API_KEY;
const BASE_URL = process.env.MINIMAX_OPENAI_BASE_URL ??
  "https://api.minimax.io/v1";

if (!API_KEY) throw new Error("Set MINIMAX_API_KEY");

const limits = {
  rpm: 180,              // 90% of the published M3 RPM
  tpm: 9_000_000,        // 90% of the published M3 TPM
  maxConcurrency: 8,     // client policy; not a published M3 limit
  windowMs: 60_000,
};

const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

class MinuteLimiter {
  constructor(config) {
    this.config = config;
    this.windowStartedAt = new Date().getTime();
    this.requests = 0;
    this.tokens = 0;
    this.inFlight = 0;
    this.nextRequestAt = 0;
  }

  resetIfNeeded() {
    const elapsed = new Date().getTime() - this.windowStartedAt;
    if (elapsed >= this.config.windowMs) {
      this.windowStartedAt = new Date().getTime();
      this.requests = 0;
      this.tokens = 0;
    }
  }

  async acquire(estimatedTokens) {
    if (estimatedTokens > this.config.tpm) {
      throw new Error("One request estimate exceeds the local TPM budget");
    }

    for (;;) {
      this.resetIfNeeded();
      const timestamp = new Date().getTime();
      const fitsRequest = this.requests + 1 <= this.config.rpm;
      const fitsTokens = this.tokens + estimatedTokens <= this.config.tpm;
      const fitsConcurrency = this.inFlight < this.config.maxConcurrency;
      const fitsPace = timestamp >= this.nextRequestAt;

      if (fitsRequest && fitsTokens && fitsConcurrency && fitsPace) {
        this.requests += 1;
        this.tokens += estimatedTokens;
        this.inFlight += 1;
        this.nextRequestAt = timestamp +
          (this.config.windowMs / this.config.rpm);
        return;
      }

      const untilReset = this.config.windowMs -
        (new Date().getTime() - this.windowStartedAt);
      await sleep(Math.max(50, Math.min(250, untilReset)));
    }
  }

  release() {
    this.inFlight = Math.max(0, this.inFlight - 1);
  }
}

const limiter = new MinuteLimiter(limits);
const retryableCodes = new Set([1001, 1002, 1024, 1033, 1039, 1041, 2045]);

function appCode(body) {
  return Number(body?.base_resp?.status_code ?? body?.error?.code ?? 0);
}

function retryDelayMs(response, attempt) {
  const retryAfter = response.headers.get("retry-after");
  if (retryAfter && /^\d+$/.test(retryAfter)) {
    return Number(retryAfter) * 1000;
  }

  if (retryAfter) {
    const retryAt = Date.parse(retryAfter);
    if (Number.isFinite(retryAt)) {
      return Math.max(0, retryAt - new Date().getTime());
    }
  }

  const cap = Math.min(30_000, 1000 * (2 ** attempt));
  return Math.floor(cap / 2 + Math.random() * cap / 2);
}

async function createCompletion(messages, estimatedInputTokens = 1000) {
  const maxOutputTokens = 1024;
  const estimatedTotalTokens = estimatedInputTokens + maxOutputTokens;

  for (let attempt = 0; attempt <= 5; attempt += 1) {
    await limiter.acquire(estimatedTotalTokens); // every HTTP attempt uses budget

    let response;
    let body;
    try {
      response = await fetch(`${BASE_URL}/chat/completions`, {
        method: "POST",
        headers: {
          Authorization: `Bearer ${API_KEY}`,
          "Content-Type": "application/json",
        },
        body: JSON.stringify({
          model: "MiniMax-M3",
          messages,
          max_completion_tokens: maxOutputTokens,
        }),
      });

      body = await response.json().catch(() => ({}));
    } finally {
      limiter.release();
    }

    const code = appCode(body);
    if (code === 2056) {
      throw new Error("Token Plan quota window exhausted (MiniMax 2056)");
    }

    const throttled = response.status === 429 || retryableCodes.has(code);
    if (throttled && attempt < 5) {
      await sleep(retryDelayMs(response, attempt));
      continue;
    }

    if (!response.ok || code !== 0) {
      throw new Error(`MiniMax request failed: HTTP ${response.status}, code ${code}`);
    }

    return body;
  }

  throw new Error("MiniMax retry budget exhausted");
}

const result = await createCompletion(
  [{ role: "user", content: "Return three names for a project queue." }],
  20
);

console.log(result.choices?.[0]?.message?.content);

The in-memory limiter is suitable for one process. In a horizontally scaled service, move the minute counters and in-flight lease to a shared store. Also replace the rough input estimate with a tokenizer or MiniMax’s token-estimation endpoint where appropriate. Reserving the requested maximum output is conservative; observed usage.total_tokens can improve later estimates.

Python: queued requests with backoff

The Python version uses requests, a thread-safe minute limiter, and a small worker pool. Install the dependency with python -m pip install requests.

import os
import random
import threading
import time
from concurrent.futures import ThreadPoolExecutor

import requests

API_KEY = os.environ["MINIMAX_API_KEY"]
BASE_URL = os.getenv(
    "MINIMAX_OPENAI_BASE_URL",
    "https://api.minimax.io/v1",
)


class MinuteLimiter:
    def __init__(self, rpm, tpm, max_concurrency):
        self.rpm = rpm
        self.tpm = tpm
        self.max_concurrency = max_concurrency
        self.window_started = time.monotonic()
        self.requests = 0
        self.tokens = 0
        self.in_flight = 0
        self.next_request_at = 0.0
        self.condition = threading.Condition()

    def _reset_if_needed(self):
        if time.monotonic() - self.window_started >= 60:
            self.window_started = time.monotonic()
            self.requests = 0
            self.tokens = 0

    def acquire(self, estimated_tokens):
        if estimated_tokens > self.tpm:
            raise ValueError("One request estimate exceeds the local TPM budget")

        with self.condition:
            while True:
                self._reset_if_needed()
                fits = (
                    self.requests + 1 <= self.rpm
                    and self.tokens + estimated_tokens <= self.tpm
                    and self.in_flight < self.max_concurrency
                    and time.monotonic() >= self.next_request_at
                )
                if fits:
                    self.requests += 1
                    self.tokens += estimated_tokens
                    self.in_flight += 1
                    self.next_request_at = time.monotonic() + (60 / self.rpm)
                    return
                self.condition.wait(timeout=0.25)

    def release(self):
        with self.condition:
            self.in_flight = max(0, self.in_flight - 1)
            self.condition.notify_all()


limiter = MinuteLimiter(rpm=180, tpm=9_000_000, max_concurrency=8)
retryable_codes = {1001, 1002, 1024, 1033, 1039, 1041, 2045}


def application_code(body):
    base_response = body.get("base_resp") or {}
    error = body.get("error") or {}
    return int(base_response.get("status_code") or error.get("code") or 0)


def retry_delay(response, attempt):
    value = response.headers.get("Retry-After")
    if value and value.isdigit():
        return int(value)
    cap = min(30, 2 ** attempt)
    return random.uniform(cap / 2, cap)


def create_completion(prompt, estimated_input_tokens=1000):
    max_output_tokens = 1024
    estimated_total_tokens = estimated_input_tokens + max_output_tokens

    for attempt in range(6):
        limiter.acquire(estimated_total_tokens)
        try:
            response = requests.post(
                f"{BASE_URL}/chat/completions",
                headers={
                    "Authorization": f"Bearer {API_KEY}",
                    "Content-Type": "application/json",
                },
                json={
                    "model": "MiniMax-M3",
                    "messages": [{"role": "user", "content": prompt}],
                    "max_completion_tokens": max_output_tokens,
                },
                timeout=180,
            )
            try:
                body = response.json()
            except ValueError:
                body = {}
        finally:
            limiter.release()

        code = application_code(body)
        if code == 2056:
            raise RuntimeError("Token Plan quota window exhausted (MiniMax 2056)")

        throttled = response.status_code == 429 or code in retryable_codes
        if throttled and attempt < 5:
            time.sleep(retry_delay(response, attempt))
            continue

        if not response.ok or code != 0:
            raise RuntimeError(
                f"MiniMax request failed: HTTP {response.status_code}, code {code}"
            )
        return body

    raise RuntimeError("MiniMax retry budget exhausted")


prompts = [
    "Give one queue-health metric.",
    "Give one safe retry rule.",
    "Give one way to reduce token usage.",
]

with ThreadPoolExecutor(max_workers=8) as pool:
    responses = list(pool.map(create_completion, prompts))

for response in responses:
    print(response["choices"][0]["message"]["content"])

This example treats each retry as another request and another conservative token reservation. That avoids a retry storm silently bypassing the limiter. It does not coordinate across machines; production clusters need a shared counter and lease system.

429 responses and MiniMax rate-limit codes

Do not detect throttling only by checking for HTTP 429. The official MiniMax error reference documents application-level status codes that can appear in the JSON response, commonly under base_resp.status_code. Compatible SDKs or gateways may also surface an HTTP 429. Inspect both the HTTP response and the parsed body.

MiniMax codeOfficial meaningApplication action
1002Rate limitQueue the request and retry after jittered backoff.
1039Token limitPause until token budget recovers; reduce prompt or output size if repeated.
1041Connection limitReduce concurrent work; MiniMax says to contact support if the problem persists.
2045Rate growth limitAvoid sudden traffic increases and decreases; ramp workers gradually.
2056Usage limit exceededDo not retry every few seconds. Wait for the applicable 5-hour or weekly quota window, use eligible Credits, or change billing route.

For a complete status-code map, authentication errors, and non-rate failures, use the MiniMax API error-code guide.

Recommended backoff policy

  • Honor Retry-After when the response includes it, but do not assume the header will always be present.
  • Use exponential backoff with jitter, for example approximately 1, 2, 4, 8, 16, then 30 seconds with randomized delay.
  • Cap retries, then return a controlled error or keep the job in a durable queue.
  • Do not retry invalid authentication, insufficient balance, safety rejections, or invalid parameters as if they were throttling.
  • Do not aggressively retry code 2056; it represents a longer usage window rather than a one-minute burst.
  • Reduce concurrency after repeated 1041 or HTTP 429 responses and increase it slowly after a stable period.

MiniMax does not document guaranteed rate-limit response headers in the public guide. A client should therefore work without remaining-quota headers and use local admission control, response codes, and observed behavior.

What to monitor in production

  • Requests attempted, accepted, retried, and failed by model and endpoint.
  • HTTP status and MiniMax application code as separate fields.
  • Input, output, and total tokens from successful text responses.
  • Queue depth, oldest-job age, in-flight count, and worker utilization.
  • Throttle rate over 1-minute, 5-minute, and 1-hour windows.
  • End-to-end latency, time to first token, and output generation duration.
  • Media task creation rate, completion rate, failure rate, and poll volume.
  • trace_id or compatible request identifier for support investigations.
  • Token Plan usage-bar alerts or pay-as-you-go balance alerts.

Never log the API key. Avoid logging full prompts, uploaded content, voice samples, or generated media by default. If request content must be retained for debugging, apply access control, minimization, redaction, and a defined retention period.

How to request higher limits

MiniMax’s rate-limit guide directs customers to its business team when the published limits do not meet their needs. Prepare a short capacity plan before contacting MiniMax:

  • Account or Team identifier and service region—do not email the secret key.
  • Models and exact endpoints.
  • Expected average and peak RPM, TPM, and concurrency.
  • Average and p95 input/output tokens or media job size.
  • Traffic shape: interactive, scheduled batch, or public multi-user application.
  • Required launch date and growth forecast.
  • Retry, queue, and abuse-prevention controls already implemented.

An increased limit does not replace backpressure. Keep the queue and retry controls because service capacity, downstream dependencies, and account quotas can still create temporary restrictions.

Official MiniMax sources

Limits and packages can change. Keep the visible verification date when publishing and recheck these canonical pages during scheduled content reviews.

Frequently asked questions

What is the MiniMax M3 API rate limit?

The public MiniMax table verified August 26, 2026 lists MiniMax-M3 at 200 RPM and 10,000,000 TPM. Effective throughput is the lower of the RPM limit, TPM divided by average total tokens, client capacity, and any account-specific control.

Does MiniMax count input and output tokens toward TPM?

Yes. MiniMax defines TPM as the maximum total input plus output tokens processed per minute. Estimate both sides before admission and record actual usage from the response.

What is the MiniMax API concurrency limit?

The central table publishes maximum concurrent tasks of 2 free / 15 paid for MiniMax-H3 Video Generation V2 and 20 CONN for Music Generation. For Music Generation, 20 CONN applies only when the account remains entitled; it is not proof of availability for a new account. The table does not publish numeric concurrency for M3, the listed M2 models, legacy Hailuo V1, speech, or image; “Not specified” is not unlimited.

Why did I receive a 429 below the published RPM?

You may have crossed TPM, sent a burst inside the provider’s enforcement window, exceeded a connection or rate-growth control, shared the key with another process, reached a Token Plan restriction, or encountered dynamic throttling. Inspect the MiniMax code in the JSON body as well as the HTTP status.

Does streaming avoid MiniMax rate limits?

No. Streaming changes delivery and can improve perceived latency, but the call still consumes request capacity and its input plus output still contributes to token usage.

Are Token Plan quotas the same as RPM and TPM?

No. Token Plan uses longer 5-hour rolling and weekly quota windows, while RPM and TPM control short-term traffic. A request can satisfy one control and fail another.

How long should I wait after a MiniMax rate-limit error?

MiniMax says Token Plan RPM/TPM throttling typically clears in about one minute, but the appropriate delay depends on the error. Honor Retry-After if supplied and use capped exponential backoff with jitter. Code 2056 is a longer quota-window error and should not be retried every few seconds.

Can I raise MiniMax API limits?

MiniMax directs customers whose limits are insufficient to its business team. Audio subscriptions and video packages also publish plan-specific RPM, while custom arrangements may differ. Provide a measured capacity plan rather than requesting an unspecified increase.

Disclosure: MiniMax-AI.chat is an independent informational website and is not MiniMax’s official API platform. Verify account-specific limits in the official console before relying on them for a production capacity commitment.