Limits¶
Every limit on this page is generated from the same definitions the service enforces. There is no second, friendlier set of numbers.
Quotas¶
Every approved account starts on the academic tier. Sustained use above 3× the tier's median raises an alert rather than a block.
| Counter | Window | academic tier |
|---|---|---|
tiles |
day | 50,000 |
rows |
day | 200,000 |
jobs |
day | 5 |
jobs_month |
month | 30 |
A window is a rolling window, not a calendar one. When a counter is exhausted
the answer is quota_exceeded, and it says which
counter and when it resets.
What charges what¶
| Input kind | Counter | Charged |
|---|---|---|
patches |
tiles |
one per item |
embeddings |
rows |
one per item |
bulk_rna |
— | nothing |
tissue |
— | nothing |
disease |
— | nothing |
Work is charged by what causes it. Tiles charge per tile and embedding rows charge per row, so a small archive of large tiles and a large archive of small tiles cost what they cost to run rather than what they weigh. Covariates charge nothing.
Sizes¶
| Input kind | Item cap | Upload cap | Per-model bounds from |
|---|---|---|---|
patches |
50,000 | 2 GiB | card.input_spec |
embeddings |
50,000 | 256 MiB | card.input_spec |
bulk_rna |
— | 64 MiB | card.output |
The item cap is the point above which a submission is refused rather than
subsampled — see Observations. The upload cap is
enforced before the bytes are written, so an oversized upload fails fast with
payload_too_large.
Per-model bounds are narrower than these, and they come from the model's own
input_spec. These are the outer bounds of the
service; a model may need less.
Request rate¶
| Bucket | Limit |
|---|---|
read |
600 per minute |
write |
60 per minute |
submit |
10 per minute |
Rate limits are per key, not per address, so a lab behind one address is not one client. Every response carries the state of your buckets:
RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, Retry-After
Read those headers instead of guessing. When you do run out, the answer is
rate_limited with an interval to wait, and waiting
the interval is the correct response — retrying immediately makes it worse for
everyone including you.
One job at a time¶
One job per key is in flight. A second submission is queued, and its position and estimate are in the job response. This is a property of a small amount of hardware being shared fairly, not a tier you can buy out of.
If a limit is wrong for you¶
Limits are set from what the service can actually deliver, and they are tuned from real usage rather than guessed once. If your work does not fit, say what you are trying to do — the answer may be a raised counter, and it may be that the local path is a better fit than the hosted one.