Skip to content
MaxAEOMaxAEO Docs

Rate Limits & Quotas

To share platform capacity fairly across accounts, the API applies concurrency and rate limits to task submissions, and size limits to requests themselves.

Limits at a glance

Section titled “Limits at a glance”
Limit Default Counted over When exceeded
Concurrent tasks 5 Tasks in your account with status queued, dispatching, or running Submit returns 1024
Submissions per minute 120 Tasks submitted in your account in the last 60 seconds (rolling window) Submit returns 1025
API keys 10 Non-deleted keys in your account (including disabled and expired ones) The console won’t create new keys
Request body size 64 KiB A single request Returns 1001
query length 4,096 characters A single task Returns 1001
wait_seconds 0–120 seconds A single request Returns 1001
List Tasks page_size Max 100 A single request Returns 1001
  • The concurrency, requests-per-minute, and API key limits currently in effect for your account are shown under Usage → Limits in the console. Contact sales if you need higher limits.
  • Limits apply per account: every API key, MCP call, and Playground request in the same account shares them.
  • Only task submissions count toward concurrency and rate. List Platforms, Retrieve a Task, and List Tasks don’t use up either limit, but please keep polling reasonable (about every 15 seconds per task).
  • A submission rejected by a limit creates no task and costs no credits, so retrying after a wait is safe.

How concurrency is counted

Section titled “How concurrency is counted”

Concurrency only counts tasks in queued, dispatching, and running — not pending (dispatched and waiting in the platform queue). In other words:

  • Once a submitted task is dispatched and moves to pending, it no longer counts against your concurrency limit.
  • Large numbers of P2 tasks sitting in pending while a platform is busy won’t exhaust your concurrency.
  • What actually counts are tasks that were just submitted but not yet dispatched, and tasks that are running.

Controlling your rate on the client

Section titled “Controlling your rate on the client”

When submitting in bulk, it’s better to pace yourself on the client than to wait for the server to reject you:

  • Throttle: leave a gap between submissions so you stay under the per-minute limit (for example, at most one submission every 0.6 seconds).
  • Back off on 1024 / 1025: pause (starting at 15 seconds and doubling each time), then submit the same task again.
  • Separate submitting from polling: one queue handles submissions; a separate scheduled loop checks unfinished tasks in batches.
# Submit a batch of questions one by one: throttle proactively, back off on rate limits
import time


SUBMIT_INTERVAL = 0.6  # seconds, about 100 per minute




def submit_batch(platform, queries):
    task_ids = []
    for query in queries:
        delay = 15
        while True:
            try:
                task = post("/task/submit", {"platform": platform, "query": query})
                task_ids.append(task["task_id"])
                break
            except MaxAEOError as e:
                if e.ret not in (1024, 1025):
                    raise
                time.sleep(delay)  # no task was created; wait, then retry the same question
                delay = min(delay * 2, 120)
        time.sleep(SUBMIT_INTERVAL)
    return task_ids

post, MaxAEOError, and sleep are defined in Error Handling. In production, also follow that page’s steps to confirm whether a task was created when a submission times out or returns -1.

Section titled “Related pages”
Error HandlingHow to handle 1024, 1025, and other error codes, and when to retry.
Billing & CreditsBeyond rate limits, insufficient credits return 1023.