sandbox API rate limit hit mid-campaign and the triage agent's detonation batch failed to complete

TL;DR

Sandbox APIs throttle like any shared API, and a campaign batch submitted all at once guarantees hitting the ceiling midway, leaving half the samples in an unknown state. Pace submissions under the published limit, submit idempotently with your own sample references, track each sample state from submitted to verdict in durable storage, and let the batch span runs: what matters is that every sample eventually gets a verdict, not that one run does it all.

sandbox API rate limit hit mid-campaign and the triage agent's detonation batch failed to complete

Use this when

• Detonation submissions start failing with rate limit responses mid-batch.
• The agent cannot say which samples were accepted before the failures.

Not for this skill when

• Submissions fail with authentication errors. Pacing does not fix credentials.
• The sandbox returns verdicts so slowly that throughput, not submission rate, is the limit. Address verdict latency instead.

Steps

1. Confirm the sandbox API rate limit from its documentation or response headers and measure your submission rate during failures. Verify: the limit and your overshoot are quantified.
2. Add a submission pacer that stays under the limit with headroom, and honour retry guidance on limit responses. Verify: a test burst no longer triggers limit errors.
3. Record every sample with a client reference and state before submission, updating state on acceptance and verdict. Verify: at any moment the batch state is fully queryable.
4. Make the batch resumable across runs, picking up samples in submitted or unsubmitted states only. Verify: stopping and restarting loses no sample and duplicates none.
5. Run a full campaign-sized batch. Verify: every sample reaches a verdict or an explicit timeout state.

Variant phrasings

sandbox api rate limit detonation batch pacing

The pacing variant.

triage agent sample tracking submitted verdict state

The state tracking variant.

Compatibility: Commercial sandbox APIs with published rate limits, agent batch workflows.

Why it happens

Campaigns arrive in bursts, exactly when the sandbox is most contended by every other customer with the same campaign. An agent that treats submission as fire-and-forget discovers the limit as data loss; one that treats it as a queue discovers it as a schedule.

Edge cases / pitfalls

• Verdicts, not submissions, are the deliverable. Optimise the batch design around verdict completion tracking.
• If the vendor offers bulk or priority submission, campaign urgency may justify it. Ask before engineering around free-tier limits.
• Cache verdicts by file hash across campaigns; kits reuse samples heavily.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstUf-lEtNALqEaauVYV9TpA