Significant-Gravitas/AutoGPT · warning · HTTPException

You have not reached your daily limit yet.

Error message

You have not reached your daily limit yet.

What it means

HTTP 400 from POST /usage/reset (routes.py:1084). Inside the per-user lock the endpoint re-verifies actual usage with get_usage_status; if the user's daily used amount is still below their daily limit, the paid reset is pointless (there is nothing exhausted to reset) and the request is rejected. This stops users from wasting credits on unneeded resets, including ones triggered by stale UI.

Source

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

    # Acquire a per-user lock to prevent TOCTOU races (concurrent resets).
    if not await acquire_reset_lock(user_id):
        raise HTTPException(
            status_code=429,
            detail="A reset is already in progress. Please try again.",
        )

    try:
        # Verify the user is actually at or over their daily limit.
        # (rate_limit_reset_cost intentionally omitted — this object is only
        # used for limit checks, not returned to the client.)
        usage_status = await get_usage_status(
            user_id=user_id,
            daily_cost_limit=daily_limit,
            weekly_cost_limit=weekly_limit,
            tier=tier,
        )
        if daily_limit > 0 and usage_status.daily.used < daily_limit:
            raise HTTPException(
                status_code=400,
                detail="You have not reached your daily limit yet.",
            )

        # If the weekly limit is also exhausted, resetting the daily counter
        # won't help — the user would still be blocked by the weekly limit.
        if weekly_limit > 0 and usage_status.weekly.used >= weekly_limit:
            raise HTTPException(
                status_code=400,
                detail="Your weekly limit is also reached. Resetting the daily limit won't help.",
            )

        # Charge credits.
        credit_model = await get_user_credit_model(user_id)
        try:
            remaining = await credit_model.spend_credits(
                user_id=user_id,
                cost=cost,

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Refresh usage state (GET usage status endpoint) — the user is simply not over the limit and can keep using CoPilot normally.
  2. Client-side: only render the reset affordance when the usage status says the daily limit is exhausted; re-fetch on 400 and update the badge.
  3. If you believe usage is wrong, check Redis usage counters for drift against actual spend.

Example fix

// before
// reset button always visible -> 400 when not over limit

// after — gate on live usage status
const usage = await getUsageStatus();
{usage.daily.used >= usage.daily.limit && <ResetButton />}
Defensive patterns

Strategy: validation

Validate before calling

// re-fetch usage right before offering the reset
const usage = await getUsageStatus();
if (usage.daily.used >= usage.daily.limit) {
  await post('/chat/usage/reset');
} else {
  refreshUsageBadge(usage); // stale UI was the cause
}

Try / catch

try { await post('/chat/usage/reset'); } catch (e) { if (e.status === 400 && /not reached your daily limit/.test(e.detail)) { await refreshUsage(); return; } throw e; }

Prevention

When it happens

Trigger: User calls /usage/reset while usage_status.daily.used < daily_limit — typical when the frontend usage badge is stale, when the daily window rolled over (UTC midnight) between display and click, or when the user never hit the cap at all.

Common situations: Client cached an 'over limit' state from before the UTC-day rollover; race where usage display lags; users probing the endpoint manually without being rate-limited.

Related errors

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