Skip to main content
This page exists so you can search for the exact text you saw. Every message below is quoted verbatim from Receipt — if what’s in front of you doesn’t match one of these strings exactly, it’s a different error than the one you’re thinking of. Most of them appear in a banner at the top of the message box — a warning triangle and red text, with a Dismiss error control on the right. A background run that stops early reports itself differently, as a message inside the thread; those strings are listed further down under routing and background runs.

​
Access and session

​
Model and provider

Like the file-upload message further down this page, This model requires a paid plan to use. runs through the same no-paywall contract: the check that decides whether a model is locked to a plan currently returns “allowed” for every model regardless of plan, and the composer has no model picker in this release. So this message can’t currently appear either.

​
The context limit

Receipt words the context-limit condition slightly differently depending on where it’s telling you about it — treat all three as the same underlying limit. When the model has a larger Max context window available to switch into, the wording changes instead: The standing message is the one you’ll usually meet, because it appears before you send: once the previous response’s reported usage has reached the window, the banner shows it and Send stays blocked. The version with the window size filled in replaces it when you send anyway — the composer estimates the prompt first, and the server repeats the check and refuses the turn with HTTP 413. Both estimates count roughly one token per four characters of text. The server’s own wording, in the third row, travels in the error response body and is never rendered; what you read on screen is always the version carrying the token count. What to do either way: start a new chat, or switch to Max if that control is available on the model you’re using.

​
Rate limits, quota, and credit

Rate limiting is a 60-second window, 30 requests, per user. There’s a separate, more restrictive free-tier rate limit (10 requests per 60 seconds) and a free allowance (100 requests per 24 hours) defined in the product, but the check that would route a request onto that free-tier path currently always returns false — so every request is evaluated against the 30-requests-per-60-seconds limit above, and the free-allowance-exhausted message can’t currently appear.
The counters live in the database, so every server replica shares them. A deployment you run yourself that sets VITE_DISABLE_REDIS=true swaps in an adapter that allows every request, so no rate limit applies at all. The window and the count can be changed with PAID_CHAT_RATE_LIMIT_WINDOW_MS and PAID_CHAT_RATE_LIMIT_MAX_REQUESTS; a value that isn’t a positive integer is rejected with Expected {NAME} to be a positive integer.

​
Server and stream failures

Two more strings for the same kinds of failure are written by the server rather than translated from a key, and they reach you by different routes. Something went wrong on our side while generating the response. Please try again. is saved as the assistant’s message when a turn fails without producing text, so you read it in the thread; a rejected provider key saves Unable to connect to the AI service. Verify that your organization OpenAI API key is valid. there instead. The assistant response failed while streaming. Please retry. is the fallback text for a broken stream: it rides along in the error response body, and it reaches the banner only when the same stream failure is reported twice.

​
Routing and background runs

When a turn needs a background run, a failure arrives as an assistant message in the thread rather than a banner — the last row below is the one exception. Beetle, in these messages, is the interface’s name for the assistant. Background runs explains each situation and how to recover; the strings are repeated here so you can find them. The routing message reads the same everywhere, but reaches you differently by channel. On the web it is the Reason: line of the Beetle stopped before completing this response. block. In Slack it is posted as a threaded reply that starts with a mention of you, and the refusal is recorded as a slack.thread.routing_failed receipt. Teams is the exception: it does not refuse, and starts a background run anyway.

​
File uploads

As covered on Files and attachments, file uploads are not actually plan-gated in this release — the check behind this message currently always allows the upload, so you shouldn’t see it in practice. The size and count limits on that page (10 MB per file, 10 files per message) do apply.

​
Route-level failures

A small set of failures happens at the chat route itself, before the turn starts: something fundamental — your session, your request body, or your organization context — didn’t check out. On screen you get the matching message from the tables above, usually Please sign in and try again. or Your request was invalid. Refresh and try again. The route’s own wording is carried in the error response body next to the TraceID, so it’s what you’ll find if you look at the failed request in your browser’s network panel or in a server log: Unauthorized, Organization context is required, Invalid JSON body, Validation failed, Failed to resolve access policy, Workspace is unavailable, and, when a tab tries to rejoin a response that is still streaming, Missing threadId query param.

​
The TraceID

Whenever an error carries a server-issued request id, the error banner shows a Show TraceID control you can expand to reveal the trace identifier under a TraceID label; clicking the identifier copies it. If you’re reporting a problem, copying and including that TraceID gives whoever investigates it a precise anchor into the request that failed. If the string in front of you is not on this page, ask for help or report a problem. Next step: go back to what Kentron is.