## TL;DR
Cache baselines and make the regression check degrade gracefully: the baseline rarely changes, so fetch it once, store it with its fetch time, and on a 429 serve the check from the cache while scheduling a refresh. A check that must fetch the baseline live on every run converts a routine rate limit into a total outage of regression detection.

```text
MLflow API rate limit hit mid-regression check and agent failed to fetch baseline metrics with 429 error
```

## Use this when
- The run or call fails with this symptom: MLflow API rate limit hit mid-regression check and the agent failed to fetch baseline metrics.
- You are working on an agent running regression checks against MLflow baselines 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 baseline that changed minutes ago, where serving the cache would be wrong and the fix is waiting out the limit window.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Identify which fetches the check repeats every run and which of them return effectively static data. Verify: the cacheable set is defined
2. Implement a baseline cache keyed by run id with a freshness window matched to how often baselines are re-chosen. Verify: baseline fetches become rare
3. On a 429 during refresh, fall back to the cache and mark the check's result with the baseline's age. Verify: checks continue with staleness disclosed
4. Add jittered backoff to refresh attempts and confirm checks run through a limit window without failing. Verify: the check survives throttling end to end

## Variant phrasings
### mlflow rate limit regression check baseline metrics 429 agent
The verbatim phrasing.
### agent failed fetch baseline rate limited cache fix
The cache phrasing.
### regression check agent throttled mlflow baseline stale
The staleness phrasing.

Compatibility: MLflow APIs driven by agents fetching baselines under rate limits

## Why it happens
Regression checks are frequent and baselines are nearly static, so the fetch pattern is all cost and no benefit until a limit makes it all failure. Caching with honest staleness keeps the safety function alive exactly when the API is under stress.

## Edge cases / pitfalls
- Never cache the candidate side; freshness there is the entire point of the check.
- If the baseline is re-picked often in your workflow, shorten the window rather than dropping the cache.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_YVxcyTp8r1i-rPNCheLXGg