> ## Documentation Index
> Fetch the complete documentation index at: https://synthlabs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Work amounts, resources and limits

> Distinguish requested work, task resources, run overrides and service capacity.

Four different constraints affect a run. Do not collapse them into one “concurrency limit.”

## Requested work

An evaluation plan specifies trials per task. A training plan specifies batches, tasks per batch and trials per task.

The release-linked CLI request bounds are:

| Plan field | Accepted request range |
| - | - |
| Evaluation `trials_per_task` | 1–100 |
| Training `num_batches` | 1–200 |
| Training `batch.tasks` | 1–100 |
| Training `batch.trials_per_task` | 1–100 |
| Training trial slots per batch | At most 100 |
| Training total planned trial slots | At most 1,000 |

All constraints apply together. Fifteen batches of four tasks with sixteen trials each requests 960 trial slots and satisfies these request bounds. It does not request 960 concurrent sandboxes or guarantee 60 distinct tasks.

See [the generated CLI reference](/reference/cli) for the release these bounds were checked against. The service can reject a syntactically valid request for account, capability, resource or quota reasons.

## Task resource defaults

The task declares its own agent timeout and environment requirements in `task.toml`. Set CPU and memory explicitly:

```toml theme={null}
[agent]
timeout_sec = 600

[verifier]
timeout_sec = 120

[environment]
cpus = 1
memory_mb = 4096
```

The current task upload contract accepts 1–4 CPUs and 1,024–8,192 MiB memory in multiples of 1,024. Managed task disk is 10,240 MiB; an explicit task storage request cannot exceed that contract.

These are task requirements, not facts about how many other runs are active.

## Explicit run overrides

An optional `sandbox` object in the plan overrides supported settings for that run. It does not rewrite the uploaded task. Unspecified fields retain the task or platform default.

| Run override | Request range |
| - | - |
| `agent_timeout_sec` | 60–7,200 seconds |
| `agent_setup_timeout_sec` | 60–3,600 seconds |
| `verifier_timeout_sec` | 30–3,600 seconds |
| `cpus` | 1–8 |
| `memory_mb` | 512–32,768 MiB |
| `storage_mb` | 1,024–65,536 MiB |

For example:

```json theme={null}
{
  "trials_per_task": 2,
  "sandbox": {"agent_timeout_sec": 900}
}
```

Here the agent deadline changes, but the other task requirements do not. Setup, agent execution and verification have different timeouts; one is not a total submission-to-result deadline.

## Service capacity and quota

Requested work is not instantaneous capacity. Scheduling, the account's quota, available resources and model-service throughput affect how quickly trials run. A larger permitted request is not a guarantee that every trial starts together.

For current account quota, use the [customer API](/reference/api):

```http theme={null}
GET /api/v1/users/{user_id}/quota
```

Do not infer available capacity from a historical example, a task's CPU setting or another run's throughput.

## Cost and pagination safety

Dry runs do not launch model trials. Some resolve remote references or download retained evidence; they are not all offline. Publication changes Registry state, and execution consumes resources.

List limits are page sizes, not workload limits. Follow the command's returned continuation and preserve its filters. An offset and a cursor are different mechanisms; use each command's documented form rather than inventing one universal pagination flag.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.