HydraFusion Cascade and Critique: keep Sume paid calls from repeating

Yes, a multi-pass workflow can reach the same tool call more than once, so every paid Sume call needs its own idempotency_key. With the key in place a repeated call returns the original job instead of starting a second render.

GitHub shipped HydraFusion as a research preview on September 30 for VS Code and the Copilot app. It sits in the model picker like a model, but behind it a task can be routed across several models. The changelog says nothing about MCP, so this post makes no claim about how HydraFusion handles tools. It only covers what to do on the Sume side if any multi-pass coding agent of yours is connected to the hosted MCP at https://mcp.sume.com/mcp.

What the three workflows do

The changelog describes three workflows. The point for a tool user is that two of them include a second pass over the same task.

Why the key matters more than the model

Any retry, escalation or revision is a chance for an agent to re-issue a call it already made. A video render is the expensive case: the second call is a new job with a new charge unless the server recognizes it.

On the hosted MCP, paid and write tools take an idempotency_key. Sending the same key with the same arguments returns the original job. Sending a new key starts a new job. So the key should come from the intent (for example launch-2026-10-hero-v1), not from a random value generated per attempt.

Wallet admission is the spend gate, and max_spend_usd is enforced when you pass it, so pass it on every paid call a multi-pass agent may make. Run dry_run first when you want the price before any pass commits.

• Derive the key from the task and the scene, not from the attempt number.
• Pass max_spend_usd on each paid call so a bad revision stops at a cap.
• Treat a jobs_wait slice that expires as a reason to wait again with the same ids, never to resubmit the create call.

What a critic should and should not do

GitHub describes the critic as read-only. That fits Sume's own split: jobs_get, jobs_status, jobs_result and balance_get are reads, while create tools are writes behind the mcp:write OAuth scope. If you can scope the reviewing pass to a read-only session, a critique can inspect a finished render without being able to start a new one. See the read-only subagent post for that setup.

A checklist before you enable it

Preview features must be enabled by an administrator on Business and Enterprise plans, so check who owns that switch in your organization.

Then test with a cheap call: ask the agent to create a short image twice in one task and confirm the second call returns the first job. The jobs docs describe the statuses you will see while it runs, and the tools and gates page lists which tools need the write scope.