Default limits
Both limits apply at the same time. For example, you can stay below the per-minute prediction limit, but still breach the hourly limit.
A Thinking fit counts against both the Thinking fit and general fit request rate limits shown above. There is no separate monthly Thinking fit allowance. Train- and test-set upload preparation requests share the upload rate limit.
Handle rate-limit errors
The request that exceeds either limit returns HTTP 429 Too Many Requests. The response includes aRetry-After header containing the number of seconds until the breached fixed window expires.
When handling a request rate limit:
- Wait at least the number of seconds specified by
Retry-Afterbefore retrying. - Use bounded exponential backoff and jitter if requests can still collide after the window resets.
- Queue batch workloads and smooth traffic instead of sending large bursts.
- Limit concurrent workers so their combined request rate stays below both limits.
- Reuse uploaded datasets and fitted model IDs when possible instead of repeating upload or fit operations. For repeated predictions against the same training set, consider the KV cache.
tabpfn-client and raw HTTP responses.
- tabpfn-client
- REST API
tabpfn-client includes the HTTP status and remaining wait time in the exception message. Given a fitted TabPFNClassifier or TabPFNRegressor called model:RuntimeError. Use the REST API directly when your application needs to read Retry-After programmatically.Higher limits
If the defaults do not support your workload, submit a limit increase request through Usage form in our platform.API metering
Shared token budgets for predictions and Thinking fits, usage estimates, and charges.
REST quickstart
Authenticate, upload data, fit a model, and run predictions.
Thinking mode
Configure fit-time optimization and understand thinking parameters.
Security
Encryption, data isolation, and access controls.