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
- Wait for one of the current running/queued tasks to finish, then resend — the message says exactly this.
- Client-side: poll active task/turn counts for the session and disable the send button at the cap.
- If the product needs more parallelism, raise the per-user inflight cap in the turn-queue configuration.
- 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
- Render the user's running+queued task count in the chat UI
- Don't auto-retry — a slot frees only when a task completes
- Watch for stuck turns that never release their inflight slot
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
- A reset is already in progress. Please try again.
- You've reached your {window} usage limit. Resets in {time_st
- Rate limit service degraded, retry shortly
- Rate limit reset is not available.
- No daily limit is configured — nothing to reset.
AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14).
Data as JSON: /api/errors/d81e6de8a7a103ec.
Report an issue: GitHub.