AI SDK 7 isStepCount stopWhen: cap a paid tool loop

stopWhen: isStepCount(5) ends the AI SDK tool loop after five steps, which bounds how long the model can keep calling tools. It does not bound money. A single step can submit a paid job, so a step cap needs a spend guard next to it, and Sume's MCP tools carry three: idempotency_key, dry_run, and max_spend_usd.

What does isStepCount actually limit?

Vercel's AI SDK page passes stopWhen: isStepCount(5) to generateText alongside the tools loaded from client.tools(). The number counts loop steps in your application. It knows nothing about what a tool call costs on the other side, so five steps of tools_list and five steps of paid submits look the same to it.

Which Sume gates sit on the tool side?

On hosted MCP, each guard has a different job, and two of them are easy to misread.

Why does the max_spend_usd detail matter?

Sume's docs say max_spend_usd is enforced only when you provide it. A model that omits the field gets no cap from it. If you want a ceiling on every paid call, do not rely on the prompt: wrap the tool or use your own approval policy so the field is always present. The tool approval post shows where that hook goes in the AI SDK.

The key is also not a consent step. Sume states that idempotency_key is for transport and dedup, so a retried step reuses the same key rather than paying twice, but nothing in it asks a person.

Can Sume bound a batch of calls in one step?

Yes, through script_run. It runs a short JavaScript program on the Sume side that calls tools in a loop, and Sume's docs say the run is bounded by timeout_seconds (5-55), max_calls and max_paid_calls. One model step can then fan out several creates, with max_paid_calls as the ceiling on how many are paid. Each paid create inside it still needs its own idempotency_key.

What should I set for a first run?

Start with a low step count, ask for dry_run=true on the first paid call, and read the estimate before allowing a real submit. Sume's playbook for paid tools says to preview with dry_run or generation_admission_preview, then submit with a fresh key and, when you want a cap, max_spend_usd. Details are in MCP tools and gates.

What happens when a step is retried?

A retried paid create with the same idempotency_key is transport and dedup, which is why Sume requires one on write and paid tools. Generate the key from the task, not from the step number, so a repeated step reuses it. A new key means a new request.

Keep the step cap low while you learn what the model does with the tool list. Five steps is Vercel's example value, not a recommendation for paid work; raise it only after the dry runs look right.