## TL;DR
Pace the agent's dbt Cloud API usage as a client of a shared service: batch status polls, cache job definitions, and spread test submissions instead of firing them together when a workflow fans out. When a limit lands mid-execution, the agent should wait for the window and resume polling the runs it already submitted, since the runs themselves continue server-side.

```text
dbt cloud API rate limit hit mid-test execution workflow failure
```

## Use this when
- The check or run fails with this symptom: test execution stalls after the dbt Cloud API begins limiting the agent.
- You are working on an agent hitting the dbt Cloud API limit during test execution and the failure repeats on the same data or configuration.
- You need the failing rows, rule, or stage isolated before changing thresholds or code.

## Not for this skill when
- A local dbt Core test run, where no cloud API limit applies instead.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Capture the limit response and count how many runs the workflow had submitted and how many it was polling. Verify: the limit context and run counts are recorded
2. Audit the agent's polling interval and call volume per run to find the amplification, usually many runs polled at a fixed short interval. Verify: the polling amplification is quantified
3. Implement adaptive polling: a longer interval as runs age, plus a single batched status check where the API allows. Verify: polling is adaptive and batched
4. On a limit response, back off for the stated window and resume polling existing runs rather than resubmitting them. Verify: limit handling resumes instead of resubmitting
5. Run the full test execution workflow and confirm it completes within the API budget with all runs reported. Verify: the workflow completes with every run's outcome

## Variant phrasings
### dbt cloud API rate limit mid test execution agent
The verbatim dbt Cloud limit phrasing.
### dbt cloud api polling interval rate limit workflow
The polling phrasing for adaptive intervals.
### agent dbt cloud limit resume polling existing runs
The resume phrasing for server-side runs.

Compatibility: dbt Cloud API used by agents to submit and poll test execution jobs

## Why it happens
Agent workflows fan out: many runs, each polled frequently, multiply into request volumes the API's limits were not sized for. The runs are safe server-side; it is the agent's chatter that gets limited, so the cure is quieter, resumable polling.

## Edge cases / pitfalls
- Submit runs with idempotency in mind: record each run identifier before polling so nothing is submitted twice.
- Prefer webhooks or completion callbacks over polling where dbt Cloud offers them.

## Provenance

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