If you're looking for a "kill switch" to stop the chatbot on one specific project while leaving it running everywhere else, this guide has to correct that expectation up front: that feature doesn't exist. What does exist is simpler and broader.
What's actually there: chatbotEnabled
There's a single boolean, chatbotEnabled, stored on the organization's settings — not
on any individual project. It gates every AI route in the app: the normal chat
endpoint, the streaming endpoint, and two others. When it's off, every one of those
routes returns the same response before doing any AI work: an error saying the chatbot
isn't enabled.
Turning it off is immediate for anything requested after the settings save (subject to the same short config-cache window described in the setup guide — a few seconds, not a redeploy). It does not delete your routing configuration — vendors, models, and thresholds all stay saved, so turning it back on later restores exactly the setup you had.
What it does not do
- It is not per-project. Flip it off, and the chatbot stops responding for the entire organization, not one project within it. If you need a project-specific restriction, this toggle is the wrong tool — it's an all-or-nothing switch at the org level.
- It does not revoke API keys. Your provider keys stay stored and valid. This is a request-gate in the app, not a credential rotation — if your concern is a compromised key, rotate the key itself with your provider, don't rely on this toggle.
- It does not stop in-flight requests. A request already being processed when you flip the switch off completes normally; the gate only applies to new requests.
When to use it
- Pausing AI spend org-wide for a period without losing your configuration.
- A provider incident where you'd rather show a clear "not available" message than let every request fail slowly through retries.
- Testing: turning the chatbot off is a fast way to confirm your app's fallback behavior (whatever the client does when AI features are unavailable) actually works, without needing to break a provider key to simulate it.
If you actually need project-level control
That's a feature gap, not a documentation gap — there's nothing in the current source to point to. If a per-project switch matters for your use case, that's worth raising as a feature request against the app rather than assuming a workaround exists in today's settings.