Rate limits

The TabPFN API applies per-user request limits to keep the service reliable and responsive. Each operation must remain below both its per-minute and per-hour limit. These request limits are separate from API metering, which tracks prediction tokens and thinking fits over daily and monthly periods. Exceeding either a request rate limit or a usage quota returns HTTP 429.

Default limits

Request type	Requests per minute	Requests per hour
Predict	60	1,500
Fit	60	1,000
Thinking mode fit	10	30
Upload	120	3,000

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 mode fit counts against both the thinking fit limit and the general fit limit. Train- and test-set upload preparation requests share the upload limit.

Handle rate-limit errors

The request that exceeds either limit returns HTTP 429 Too Many Requests. The response includes a Retry-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-After before 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.

Do not retry rate-limited requests in a tight loop. Requests remain rejected until the current fixed window expires. The following examples show how the retry delay appears in 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:

try:
    predictions = model.predict(X_test)
except RuntimeError as exc:
    print(f"{type(exc).__name__}: {exc}")

Example output—the remaining time and trace ID vary by request:

RuntimeError: Fail to call predict: [HTTP 429] Rate limit exceeded: at most 60 predict requests per minute are allowed. Retry in 42s.. Report trace ID: <trace-id>.

The high-level client exposes the retry delay in the message, but not the response headers through the RuntimeError. Use the REST API directly when your application needs to read Retry-After programmatically.

The raw response includes the same retry delay in both the JSON message and the Retry-After response header:

HTTP/1.1 429 Too Many Requests
Retry-After: 42
Content-Type: application/json

{
  "message": "Rate limit exceeded: at most 60 predict requests per minute are allowed. Retry in 42s.",
  "error_code": "USER_ERROR",
  "trace_id": "<trace-id>"
}

With httpx, inspect the header before handling other HTTP errors:

import httpx

response = httpx.post(
    f"{BASE}/tabpfn/predict",
    headers=HEADERS,
    json=predict_payload,
)

if response.status_code == 429:
    retry_after = int(response.headers["Retry-After"])
    error = response.json()
    print(error["message"])
    print(f"Retry-After header: {retry_after} seconds")
else:
    response.raise_for_status()

Example output:

Rate limit exceeded: at most 60 predict requests per minute are allowed. Retry in 42s.
Retry-After header: 42 seconds

See the REST API quickstart for a complete predict_payload example.

Higher limits

If the defaults do not support your workload, submit a limit increase request through Usage form in our platform.

API metering

Token budgets, usage pools, and thinking fit quotas.

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.

Getting Started

Metering and rate limits

Capabilities

Agentic

Integrations

Troubleshooting

TabPFN in Action

Customer References

Changelog

Default limits

Handle rate-limit errors

Higher limits

API metering

REST quickstart

Thinking mode

Security

​Default limits

​Handle rate-limit errors

​Higher limits

API metering

REST quickstart

Thinking mode

Security

Default limits

Handle rate-limit errors

Higher limits