Limits & Fair Use¶
The hosted service is a shared testbed. The limits below exist to keep it responsive for everyone — and, more importantly, to keep one person's workspace from being able to reach into anyone else's.
Your workspace¶
Every account gets its own isolated workspace and its own container. Studies, conversations, results, and configuration are yours alone; nothing is shared between users except the service itself.
| resource | limit |
|---|---|
| CPU | 2 cores |
| Memory | 2 GB |
| Processes | 256 |
| Privileges | runs as an unprivileged user; no privilege escalation |
| Network | outbound access is restricted to what the workflow legitimately needs (web search and grounding, the project's own data services) |
Workspaces suspend after about two hours of inactivity and start again the next time you open the service. Nothing is lost — that's why the first page load after a break says "waking up your workspace". A conversation left idle for 15 minutes disconnects its assistant session and resumes transparently on your next message.
Simulation scale¶
There is no hard wall-clock cap on a run, but the workflow is designed to keep hosted runs under about ten minutes, in the foreground, so you can watch them finish. Practically, that puts a hosted study in the range of tens to a few hundred agents over a handful of steps.
If your question genuinely needs more, the assistant should tell you before running rather than starting something that will overrun. Your options:
- Cut the scale — a smaller pool over the same horizon usually answers the same question, and you can scale up once the design is right.
- Take it local — clone the open-source package and run the same study directory with your own key and your own hardware. Nothing needs rewriting; see Installation.
Some bundled studies wrap external pipelines that are never appropriate to run here (a reinforcement-learning trainer that wants a GPU, for example). Those carry a note on their run card telling you so, and how to run them locally — drug procurement is the example.
Rate limits¶
| action | limit |
|---|---|
| chat messages | 20 per minute |
| sign-in and registration attempts | 10 per 5 minutes, per address |
| password-reset requests | 5 per 15 minutes, per address |
Hitting one returns a "too many requests" error; wait and retry. Requests to the underlying language models are queued rather than rejected when the service is busy, so a slow response under load is normal — it isn't a failure.
What the assistant is not allowed to do¶
The assistant runs inside your workspace under a permission policy, and some things are refused outright regardless of what it's asked. You'll see these as refusals in the conversation:
- Writing outside your studies. It can create and edit files under
studies/— and nowhere else. It cannot modify the framework itself. - Installing software or changing the environment. No package installation, no privileged commands, no touching service configuration or credentials.
- Version-control operations. It cannot commit or push anything anywhere.
- Destructive commands. Deletion is confined to your own study directories.
- Anything the policy doesn't explicitly cover, which is denied by default rather than allowed by default.
Web search and the project's data services are available — grounding a study in the real world is the point.
Why it won't discuss its own infrastructure
Ask the assistant about file paths, API keys, model endpoints or how the service is deployed and it will decline. That isn't evasiveness — it's a deliberate boundary, so a workspace can't be talked into revealing operational detail about the service or other users.
Fair use, in one paragraph¶
Use it for research. Don't use it as general-purpose compute, don't try to reach other users' workspaces or the service's own configuration, and don't script against it to drive load. If you need more capacity than the limits above — a teaching session, a large batch of studies, a genuinely big population — ask. That's a conversation, not a violation.
Privacy and durability¶
Your studies, transcripts, and results live in your workspace on the server. They are not visible to other users. Because this is a testbed rather than a production system, treat it accordingly:
Don't put sensitive data here
Don't paste confidential, personal, or identifying data into a study. The populations SocioVerse builds are synthesized or sampled from declared sources — they don't need real individuals' records, and the service is not the right place to hold them.
Deleting one of your own studies is permanent and takes its results and conversation with it. If a result matters, save the numbers or the report elsewhere.