agent's cell-by-cell execution hit the API rate limit mid-execution, run failed

TL;DR

An agent executing cells that call a rate-limited API will burn through the quota at machine speed and die mid-run on a 429. Give the agent three habits: retries with exponential backoff on 429s, a response cache so retries and re-runs do not re-spend quota, and pacing between calls to stay under the limit. Also surface the quota state to the agent's planner so it stops scheduling calls it cannot afford.

agent's cell-by-cell execution hit the API rate limit mid-execution, run failed

Use this when

• An agent's run fails partway with 429s from inside executed cells.
• Re-runs fail at the same point (no caching).
• The agent makes many API calls in a tight loop.

Not for this skill when

• The API rejects with auth errors. That is credentials.
• A human's notebook hits the limit. Same fixes, manual application.

Steps

1. Add backoff retries around the API calls in the executed code. Verify: a 429 is retried, not fatal.
2. Add a disk cache keyed by request. Verify: a re-run spends near-zero new quota.
3. Pace the calls: sleep or batch to stay under the documented rate. Verify: the request rate is under the limit.
4. Expose quota headers to the agent's planner. Verify: the agent slows down as quota drains.
5. Re-run the agent end to end. Verify: it completes without 429 failures.

Variant phrasings

agent api rate limit 429 execution

Short form. Backoff, cache, pace.

agent hitting rate limits mid run

The symptom phrasing. Quota is a budget.

cell execution api quota exhausted

The budget phrasing. Cache aggressively.

Compatibility: Any HTTP API with rate limits, any agent runner. The habits are client-side.

Why it happens

Agents execute at machine speed with no human pauses, so a loop that a person would run over an afternoon completes in a minute and trips limits designed around human pacing. The 429 is the API working as intended; the agent was planned as if quota were infinite. Treating quota as a budget in the planner, not just handling 429s in the code, is what prevents the failure rather than merely surviving it.

Edge cases / pitfalls

• Backoff without a cap can stall the run for hours. Cap total wait and fail clearly.
• Caching with a wrong key serves stale data. Key on the full request including parameters.
• Some APIs ban keys that retry aggressively. Back off genuinely; do not just retry faster.
• The planner needs the quota state before scheduling, not after failing. Wire it in early.

Provenance

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