## TL;DR
Bound the listing before it starts: an agent that asks for every run and pages through them synchronously will time out on any real experiment. Query with a restrictive filter and a page size, process runs in pages, and persist progress so a timeout resumes instead of restarting. Set the agent's own deadline below the API timeout and make each page a checkpoint.

```text
agent timed out when agent tried to list 10000 MLflow runs and hit a pagination timeout error
```

## Use this when
- The run or call fails with this symptom: agent timed out listing 10000 MLflow runs with a pagination timeout.
- You are working on an agent listing or auditing MLflow runs across a large experiment and the failure repeats on the same run or configuration.
- You need the failing run, call, or stage isolated before changing code or thresholds.

## Not for this skill when
- A one-off human export where a single long download is acceptable, unlike an agent's repeated polling.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Replace the unbounded list with a filtered search: experiment, status, and a time window the task actually needs. Verify: the query scope is explicit and smaller
2. Page with a fixed page size and record the last processed run id and time after each page. Verify: progress survives a timeout
3. Give the agent a per-page deadline and a total budget, after which it reports partial coverage honestly. Verify: the agent stops with a stated coverage instead of hanging
4. Resume from the recorded position and confirm the full set is eventually covered across runs. Verify: coverage completes over successive invocations

## Variant phrasings
### agent timed out listing mlflow runs pagination
The verbatim phrasing.
### agent listing 10000 runs timeout page size fix
The paging phrasing.
### mlflow run audit agent timeout resume paging
The resume phrasing.

Compatibility: MLflow search APIs driven by agents with pagination discipline

## Why it happens
Run histories grow without bound, so an enumerate-everything strategy has a cost proportional to all history on every invocation. Synchronous paging multiplies that by round trips, and the timeout is simply the moment the total cost crosses the client's patience.

## Edge cases / pitfalls
- Server-side ordering must be stable across pages, or resumes skip and duplicate runs at page boundaries.
- Most audits need aggregates; compute counts server-side where the API allows instead of listing rows.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2Ezs2W2dulRKSpOf3z3f3g