AI SDK isLoopFinished vs the 20-step cap for Sume video jobs

A ten-minute Sume render needs at least eleven jobs_wait calls, because each holds at most 55 seconds. The AI SDK page says a ToolLoopAgent stops after 20 steps by default and that you can raise the limit or remove it with isLoopFinished(); the safer choice with paid tools is a higher isStepCount(n).

Loop facts are from the AI SDK loop-control page; wait limits from Sume's Jobs and results, read 2026-09-30.

How many waits can a render cost?

Sume's docs say to wait for a ten-minute render by repeating the wait. At a 55-second cap, ten minutes is at least eleven waits, plus the create and the result read. The AI SDK page quoted here gives the 20-step default but does not say how steps are counted, so check how your loop counts tool calls before relying on it.

How can I cut the number of wait calls?

Why not remove the cap?

The AI SDK page says the limit can be removed with isLoopFinished(). With paid Sume tools in the loop, an unbounded loop can keep submitting paid calls, so keep a finite isStepCount and use the per-call guards in Sume's docs: dry_run for a preview and max_spend_usd, which is enforced only when you pass it.

import { ToolLoopAgent, isStepCount } from "ai";

const agent = new ToolLoopAgent({
  model, // your model
  tools, // from your Sume MCP client
  stopWhen: isStepCount(40),
});

What if a wait ends without a result?

wait_slice_expired means retry the same ids, not that the job failed. Never resubmit the paid create.

How do I size the cap?

Estimate one create, one wait per 55 seconds of expected render, and the result reads. A batch jobs_wait with job_ids covers several jobs in each call. Set isStepCount to that total plus headroom, and keep the per-call max_spend_usd guard. If the loop stops before the job ends, the job is still running: read it with jobs_status using the stored id.