Errors and limits

The error envelope

Every error, from every endpoint, has the same shape:

{
  "type": "error",
  "error": {
    "type": "bad_request_error",
    "message": "invalid params, content must include a non-empty text item (prompt is required) (2013)",
    "http_code": "400"
  },
  "request_id": "021785229015510a2c883cf675b9804d"
}

Two details that catch people out, both inherited from the MiniMax API:

• the numeric code lives inside message, in parentheses — there is no separate code field;
• http_code is a string, not a number.

request_id is echoed on every response, including successes, in the X-Request-Id header. Quote it when asking for help. Send your own and we will use it instead.

Codes

Which ones to retry

429 and 503 are worth retrying, with backoff. 500 is worth retrying once.

400, 401, 402 and 422 will fail identically no matter how many times you send them — fix the request, the key or the balance.

Task failure is not request failure

A task that is accepted and later fails reports through the query endpoint, not through an HTTP error:

{
  "task": {
    "status": "failed",
    "error": { "code": "1000", "message": "…" }
  }
}

Note task.error.code is a string, and there is no http_code. It is a different shape from the envelope above.

A failed task costs nothing: the charge is held at submit and returned in full.

Rate limits

Four independent limits, per account:

Concurrency counts queued as well as running tasks. Without that, one account could enqueue ten thousand clips and everyone else would wait a day.

All four are adjustable — ask.

Generation limits

Content filtering

Prompts pass a filter before they reach a TPU. A rejection is 422 with code 1026. Filters have false positives; if you think you have one, quote the request_id.