Limits and queues

What happens under load: how many runs go at once, what waits, and what is refused.

Limits exist so one busy job cannot take the whole workspace with it. They are visible, and nothing is dropped silently.

Runs of the same job

Script runs of one job go one after another by default, which keeps writes in order. The part that needs the agent can be allowed to run several at a time when a job has to keep up with a burst, and that is a setting on the job rather than a surprise.

Queues

When a job is busy, the next request waits in a durable queue instead of being refused. The queue survives a restart of the platform, keeps its order, and each waiting run carries its own input, so a burst of ten documents produces ten runs with ten documents and not ten copies of the last one.

Webhooks

Sixty requests per minute per token, and a payload of up to 256 kilobytes. Above either, the caller receives an answer that says so. See Webhooks.

Capacity

Each container has a fixed amount of memory and a ceiling on how many runs happen at once. When the ceiling is reached, work queues rather than failing. Growing that ceiling is a change we make on your workspace, not something an agent can do to itself.

Long runs

A run that would take longer than its limit is ended and reported, so nothing hangs invisibly. What it did until then stays on the timeline.