Significant-Gravitas/AutoGPT · warning · HTTPException

You've reached the limit of {resolved} active tasks (running

Error message

You've reached the limit of {resolved} active tasks (running + queued). Please wait for one of your current tasks to finish before starting a new one.

What it means

HTTP 429 from POST /chat/stream (routes.py:1545). The CoPilot turn queue enforces an inflight cap per user: running + queued turns must stay under inflight_cap. When enqueueing would exceed it, the queue raises turn_queue.InflightCapExceeded and the route surfaces inflight_turn_limit_message(inflight_cap) — 'You've reached the limit of {resolved} active tasks (running + queued)...'. The turn is not lost-before-enqueue; the server has already fallen back to queueing (the log line notes 'running cap reached'), and this is the hard stop beyond that.

Source

Thrown at autogpt_platform/backend/backend/api/features/chat/routes.py:1545

                session_id=session_id,
                message=request.message,
                message_id=request.message_id,
                is_user_message=request.is_user_message,
                context=request.context,
                file_ids=sanitized_file_ids,
                mode=request.mode,
                model=request.model,
                llm_auth_provider=session.metadata.llm_auth_provider,
                llm_credential_id=session.metadata.llm_credential_id,
                permissions=(
                    builder_permissions.model_dump(exclude_none=True)
                    if builder_permissions
                    else None
                ),
                request_arrival_at=request_arrival_at,
            )
        except turn_queue.InflightCapExceeded:
            raise HTTPException(
                status_code=429,
                detail=inflight_turn_limit_message(inflight_cap),
            )
        logger.info(
            f"[STREAM] Queued turn for session={session_id} "
            f"(running cap reached; inflight cap={inflight_cap})"
        )
        return _empty_ui_message_stream_response()

    if turn_id is None:
        logger.info(
            f"[STREAM] Duplicate message detected for session {session_id}, skipping enqueue"
        )
    else:
        log_meta["turn_id"] = turn_id

    setup_time = (time.perf_counter() - stream_start_time) * 1000
    logger.info(

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Wait for one of the current running/queued tasks to finish, then resend — the message says exactly this.
  2. Client-side: poll active task/turn counts for the session and disable the send button at the cap.
  3. If the product needs more parallelism, raise the per-user inflight cap in the turn-queue configuration.
  4. Check for stuck turns: a turn that never completes permanently consumes a slot — inspect the stream registry/queue if the cap never frees up.
Defensive patterns

Strategy: validation

Validate before calling

// track active tasks client-side before sending
const active = runningTurns + queuedTurns;
if (active >= INFLIGHT_CAP) {
  showToast('Wait for a running task to finish');
} else {
  await post('/chat/stream', body);
}

Try / catch

try { await post('/chat/stream', body); } catch (e) { if (e.status === 429 && /active tasks/.test(e.detail)) { showActiveTaskList(); return; } throw e; }

Prevention

When it happens

Trigger: Posting new /chat/stream turns (or fan-out task launches within a turn) while the user already has inflight_cap turns in running+queued state — e.g. automations launching many parallel agent tasks from one session.

Common situations: Power users launching parallel sub-agent tasks; a client bug re-submitting turns; long-running agent tasks accumulating in the queue so new sends bounce.

Related errors


AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14). Data as JSON: /api/errors/d81e6de8a7a103ec. Report an issue: GitHub.