Limits, and when DioscHub is the wrong choice

DioscHub is built for one shape of problem: an assistant that acts inside your systems, through your existing APIs, as the people using it, with their permissions and their consent. That focus is the reason the boundary is small enough to verify. It also means there are things DioscHub does not do. Two kinds, kept separate because they are different decisions: current limits (real today, may change) and genuine mismatches (the model is not aimed at you).

Current limits, true today

These are honest boundaries of the present system, not permanent properties.

No unattended or overnight work. The assistant acts only while a user is present and signed in. Credentials are not persisted long-term and are not refreshed outside the live session, so you cannot hand the assistant a long-running job to finish while the user is away. (Autonomous worker agents are a future direction, not a current capability.)
No shared, team, or group sessions. One session is one user. There are no multi-user shared conversations today; the model assumes a single responsible person behind each session.
One instance for correct rate-limiting and quota, for now. Rate limits and token quotas are tracked per process. A multi-replica deployment would count them independently, so run a single instance for accurate enforcement until the shared-store (Redis) version lands. See Operate for the current guidance.

Genuine mismatches, where a different tool fits better

You have no system to connect, and no actions to take. DioscHub’s value is acting in your systems through MCP servers you control. If you only need a standalone chatbot, with no identity, no tools, and answers only, you are carrying an integration layer you won’t use. (DioscHub can answer from a knowledge base, so “mostly answers, some actions” is still a fit; “only ever answers, with no system behind it” is not.)
The AI must act beyond the user’s own access. In the authenticated model, the user’s credential is what authorizes every action, so the assistant can do what the user can do, and no more. If your use case needs the assistant to act with elevated, super-user, or cross-user access beyond the person at the keyboard, that runs against the grain of the model and against the property that makes it defensible.
You can’t or won’t run an MCP server. Connecting a system means wrapping it as an MCP server you host. It is thin, but it is code you own and operate. If you need a fully managed, no-code connector catalog, DioscHub is not that.
You want a managed, multi-tenant SaaS. DioscHub is self-hosted and single-tenant. You run the image, the database, and the secrets, because it handles real user credentials. If your requirement is a vendor-operated multi-tenant service with no infrastructure on your side, the deployment model is a mismatch from the start.

If you’re on the fence

Two conditions decide it. DioscHub fits when both hold:

There is a system the AI should act in, through an API you can wrap as a tool. Without one, a plainer chatbot is the better fit.
The AI should act within real users’ permissions, and take actions you’d want a human to approve. This is the part you’d otherwise have to build and defend yourself; here it’s the model you’re evaluating.

When both hold, DioscHub is aimed squarely at your problem. The next page turns that into a half-hour test.

Next: Run a 30-minute proof-of-concept, to see the model work against your own auth and a sample tool.