Significant-Gravitas/AutoGPT · error · HTTPException
Rate limit reset failed — please try again later. Your credi
Error message
Rate limit reset failed — please try again later. Your credits have not been charged.
What it means
HTTP 503 from POST /usage/reset (routes.py:1140). The flow charges credits first, then resets daily usage in Redis (reset_daily_usage). If the Redis reset fails, the endpoint compensates by refunding via grant_credits (a GRANT, not a Stripe TOP_UP). This message means the refund SUCCEEDED — the user was made whole — but the reset did not happen; a later retry is safe.
Source
Thrown at autogpt_platform/backend/backend/api/features/chat/routes.py:1140
cost,
"Refund for failed CoPilot rate-limit reset",
)
refunded = True
logger.warning(
"Refunded %d credits to user %s after Redis reset failure",
cost,
user_id[:8],
)
except Exception:
logger.error(
"CRITICAL: Failed to refund %d credits to user %s "
"after Redis reset failure — manual intervention required",
cost,
user_id[:8],
exc_info=True,
)
if refunded:
raise HTTPException(
status_code=503,
detail="Rate limit reset failed — please try again later. "
"Your credits have not been charged.",
)
raise HTTPException(
status_code=503,
detail="Rate limit reset failed and the automatic refund "
"also failed. Please contact support for assistance.",
)
# Track the reset count for daily cap enforcement.
await increment_daily_reset_count(user_id)
finally:
await release_reset_lock(user_id)
# Return updated usage status (public schema — percentages only).
updated_usage = await get_usage_status(
user_id=user_id,View on GitHub (pinned to 9c8bb5550f)
Solutions
- Retry the reset once Redis is healthy — the refund restored the balance so a retry will charge again only if it proceeds further.
- Check Redis health and backend logs for 'CRITICAL: Failed to refund' absence (that would be the worse variant, error 150).
- Client-side: on 503 with this detail, refresh the balance display to reassure the user, then allow manual retry.
- Ops: alert on the reset-failure log path; frequent occurrences mean Redis durability issues are costing refunds.
Defensive patterns
Strategy: retry
Try / catch
try { await post('/chat/usage/reset'); } catch (e) {
if (e.status === 503 && /credits have not been charged/.test(e.detail)) {
await refreshBalance(); // reassure: refund already happened
await sleep(30_000); return retryOnce();
}
throw e;
} Prevention
- On 503 with 'not been charged', refresh the balance display before retry
- Retry only once Redis is healthy — check service status first
- Alert ops on reset-failure logs even when refunds succeed (Redis instability signal)
When it happens
Trigger: Redis write fails (down, failover, eviction) exactly between the successful spend_credits call and reset_daily_usage; the refund path then completes. Any transient Redis fault during that window produces this 503.
Common situations: Redis restarts/OOM under load; connection blips; local dev with flaky Redis. Users see a scary 503 but their balance is intact — support should confirm balance before re-charging.
Related errors
- Rate limit reset failed and the automatic refund also failed
- Unable to verify reset eligibility — please try again later.
- Chat service degraded, retry shortly
- Rate limit service degraded, retry shortly
- Rate limit reset is not available.
AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14).
Data as JSON: /api/errors/8a760b1ff8dd3be8.
Report an issue: GitHub.