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 family | Model or operation | Published RPM | Published TPM | Published concurrency |
|---|---|---|---|---|
| Text | MiniMax-M3 | 200 | 10,000,000 | Not specified |
| Text | Listed M2-series models | 500 | 20,000,000 | Not specified |
| Video | MiniMax-H3 / Video Generation V2 | Not specified | Not specified | 2 free / 15 paid CONN |
| Video | Legacy Hailuo 2.3 / 2.3 Fast / 02 | 5 free / 20 paid | Not specified | Not specified |
| Speech | T2A speech models | 60 | Not specified | Not specified |
| Speech | Voice Cloning | 60 | Not specified | Not specified |
| Speech | Voice Design | 20 | Not specified | Not specified |
| Image | image-01 | 10 | Not specified | Not specified |
| Music | Music 3.0 / 2.6 / Cover / 2.0 | 120 | Not specified | 20 CONN |
| File and other operations | File management, model listing, and operations absent from the central table | Not specified | Not specified | Not specified |
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-H3Video 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, TPM, concurrency, and quota
- Text-model limits
- Video, speech, image, and music limits
- Package-specific RPM
- Token Plan limits
- Throughput calculations
- Queue and worker design
- Node.js limiter and backoff
- Python limiter and backoff
- 429 and MiniMax error codes
- Monitoring checklist
- Official sources
- FAQ
RPM vs TPM vs concurrency vs quota
| Control | What it limits | Practical example |
|---|---|---|
| RPM | Requests accepted within a one-minute period | 200 RPM allows at most 200 M3 calls per minute before another constraint is considered. |
| TPM | Total input plus output tokens processed within a one-minute period | A 10,000,000 TPM budget supports 125 calls averaging 80,000 total tokens, even though the RPM ceiling is 200. |
| Concurrency / CONN | Requests or connections in progress at the same time | MiniMax-H3 permits at most 2 concurrent V2 tasks on the free tier or 15 on the paid tier; Music Generation publishes 20 CONN. |
| Quota | Usage available in a longer plan window | A Token Plan can have 5-hour and weekly quota windows even when an individual request is also subject to RPM or TPM throttling. |
| TPS | Generated output tokens per second after output begins | TPS 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 ID | RPM | TPM (input + output) | Even request spacing |
|---|---|---|---|
MiniMax-M3 | 200 | 10,000,000 | About one request every 300 ms |
MiniMax-M2.7 | 500 | 20,000,000 | About one request every 120 ms |
MiniMax-M2.7-highspeed | 500 | 20,000,000 | About one request every 120 ms |
MiniMax-M2.5 | 500 | 20,000,000 | About one request every 120 ms |
MiniMax-M2.5-highspeed | 500 | 20,000,000 | About one request every 120 ms |
MiniMax-M2.1 | 500 | 20,000,000 | About one request every 120 ms |
MiniMax-M2.1-highspeed | 500 | 20,000,000 | About one request every 120 ms |
MiniMax-M2 | 500 | 20,000,000 | About one request every 120 ms |
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
| API | Covered models or operation | Published RPM | Published CONN | Even submission pace |
|---|---|---|---|---|
| Video Generation V2 | MiniMax-H3 | Not specified | 2 free / 15 paid | Cap in-flight tasks at the tier limit |
| Video Generation (V1) | MiniMax-Hailuo-2.3, MiniMax-Hailuo-2.3-Fast, MiniMax-Hailuo-02 | 5 free / 20 paid | Not specified | About one request every 12 seconds free or 3 seconds paid |
| T2A | speech-2.8-turbo, speech-2.8-hd, speech-2.6-turbo, speech-2.6-hd, speech-02-turbo, speech-02-hd | 60 | Not specified | One request per second |
| Voice Cloning | Voice-cloning operation | 60 | Not specified | One request per second |
| Voice Design | Voice-design operation | 20 | Not specified | One request every 3 seconds |
| Image Generation | image-01 | 10 | Not specified | One request every 6 seconds |
| Music Generation | Music-3.0, Music-2.6, Music-Cover, Music-2.0 | 120 | 20 | Two requests per second, subject to CONN |
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 tier | Published RPM |
|---|---|
| Starter | 10 |
| Standard | 50 |
| Pro | 200 |
| Scale | 500 |
| Business | 800 |
| Customer Pricing | Described by MiniMax as unlimited RPM/TPM; confirm contractual controls |
Video Package RPM
| Video package | Published RPM |
|---|---|
| Standard | 20 |
| Pro | 30 |
| Scale | 40 |
| Business | 50 |
| Custom Pricing | Described by MiniMax as unlimited RPM/TPM; confirm contractual controls |
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.
| Situation | Likely control | Correct response |
|---|---|---|
| A burst fails, then succeeds after a short pause | RPM, TPM, growth control, or dynamic throttling | Queue, pace, and retry with jittered backoff. |
| Subscription usage bar is exhausted | 5-hour or weekly Token Plan quota | Wait for quota recovery, use eligible purchased Credits, upgrade, or use a pay-as-you-go key. |
| More parallel agents fail during peak traffic | Dynamic Token Plan traffic control | Reduce active agents and serialize lower-priority work. |
| Pay-as-you-go request reports insufficient balance | Billing balance, not RPM | Check 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
- Classify the job. Put text, speech, image, video, and music into separate queues with their own limits.
- Estimate cost before admission. For text, reserve estimated input tokens plus the maximum intended output. Reconcile with the response’s usage values.
- Pace instead of burst. Spread requests across the minute and keep 10–20% operating headroom.
- Cap in-flight work. Use a client concurrency limit even where MiniMax does not publish one.
- Retry only retryable failures. Apply exponential backoff with jitter to throttling and temporary server failures.
- Protect interactive traffic. Give user-facing calls a separate priority lane from batch processing.
- 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.
- 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 code | Official meaning | Application action |
|---|---|---|
1002 | Rate limit | Queue the request and retry after jittered backoff. |
1039 | Token limit | Pause until token budget recovers; reduce prompt or output size if repeated. |
1041 | Connection limit | Reduce concurrent work; MiniMax says to contact support if the problem persists. |
2045 | Rate growth limit | Avoid sudden traffic increases and decreases; ramp workers gradually. |
2056 | Usage limit exceeded | Do 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-Afterwhen 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
1041or 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_idor 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
- Rate Limits — MiniMax API Docs: central RPM, TPM, and CONN tables.
- Error Codes — MiniMax API Docs: codes 1002, 1039, 1041, 2045, and 2056.
- Token Plan FAQs — MiniMax API Docs: quota windows, dynamic throttling, approximate agent traffic, and production guidance.
- Audio Subscription — MiniMax API Docs: tier-specific speech RPM.
- Video Packages — MiniMax API Docs: package-specific video RPM.
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.
