Your quota for this chat has been reached. Try again later o

Error message

Your quota for this chat has been reached. Try again later or contact the site owner.

What it means

Per-session quota enforcement inside canRespond: when max_chats_per_session > 0 and the count of EmbedChats rows for that embed AND that sessionId within the last 24 hours has reached it, the request gets HTTP 429 with abort payload 'Your quota for this chat has been reached. Try again later or contact the site owner.'. Unlike the daily cap this is per visitor session, so one heavy user cannot be unblocked by other users' inactivity.

Source

Thrown at server/utils/middleware/embedMiddleware.js:164

        });
        return;
      }
    }

    if (
      !isNaN(embed.max_chats_per_session) &&
      Number(embed.max_chats_per_session) > 0
    ) {
      const dailySessionCount = await EmbedChats.count({
        embed_id: embed.id,
        session_id: sessionId,
        createdAt: {
          gte: new Date(new Date() - 24 * 60 * 60 * 1000),
        },
      });

      if (dailySessionCount >= Number(embed.max_chats_per_session)) {
        response.status(429).json({
          id: uuidv4(),
          type: "abort",
          textResponse: null,
          sources: [],
          close: true,
          error:
            "Your quota for this chat has been reached. Try again later or contact the site owner.",
        });
        return;
      }
    }

    next();
  } catch {
    response.status(500).json({
      id: uuidv4(),
      type: "abort",
      textResponse: null,

View on GitHub (pinned to 3aec848f28)

Solutions

Raise or clear max_chats_per_session on the embed config (blank/0 disables it)
Start a new session: generate a new UUID sessionId — the quota is keyed to the session, so a fresh id gets a fresh budget
Otherwise wait until that session's chats age out of the rolling 24h window

Example fix

// before: widget keeps one hardcoded sessionId forever
const sessionId = '00000000-0000-0000-0000-000000000000';

// after: 'New chat' button issues a fresh session
function newChat() { sessionId = crypto.randomUUID(); }

Defensive patterns

Strategy: retry

Validate before calling

// widget: offer an escape hatch before the cap bites
if (messagesThisSession >= knownSessionCap) offerNewChat(); // new crypto.randomUUID() resets quota

Try / catch

if (res.status === 429) {
  const data = await res.json();
  if (/quota for this chat/.test(data.error ?? '')) {
    sessionId = crypto.randomUUID(); // fresh session = fresh per-session quota
    retryOnceWithNewSession(message);
  }
}

Prevention

Wire the widget's 'New chat' action to generate a fresh session UUID
Size max_chats_per_session generously enough for real conversations
Track message count per session client-side to warn before the cap

When it happens

Trigger: A single visitor (one sessionId) sends more messages than max_chats_per_session within 24h; every subsequent message from that session 429s while other sessions still work.

Common situations: Aggressive per-session caps (e.g. 5) set to control LLM spend; automated visitors looping on one session; widget 'new chat' button not generating a fresh sessionId so the visitor stays on a exhausted session.

Related errors

AI-assisted analysis of Mintplex-Labs/anything-llm@3aec848f28 (2026-08-18). Data as JSON: /api/errors/c7c297112ba36822. Report an issue: GitHub.