Goose MCP HTTP retries and Sume paid calls: reuse the key
When goose retries an MCP HTTP call to Sume, the same idempotency_key keeps a paid generate call a dedup, not a second job. Check status before resubmitting.

If goose retries an MCP HTTP call to Sume, the idempotency_key in the tool arguments is what keeps the retry safe: Sume's docs require it on every write and paid tool and describe it as a stable key for transport and dedup. Reuse the same key for the same intended job, and check job status before ever submitting a new one.
goose 1.51.0 (2026-09-17) lists the bug fix "MCP preferred version and HTTP retries (#12066)". The release notes say nothing more about how retries behave, so this post covers the Sume side only: Errors and credits and MCP tools and gates, read 2026-10-01.
What do the Sume docs say about retrying a submit?
Under rate limits, the docs say to back off on 429, use retry-after when present, and not retry unsafe submit requests without an Idempotency-Key. For MCP the equivalent is the idempotency_key argument. The same row says it is not human approval, so a retry with the same key is dedup, and a new key means a new request.
What if a retried call times out locally?
The jobs docs say not to resubmit the original paid request just because a local process timed out. A timeout means your client stopped waiting, not that the job stopped. Read it back with the job id, or with jobs_status, before deciding anything.
| Situation | What to do |
|---|---|
Transport error on a paid tools/call | Retry with the same idempotency_key |
| Local timeout | Read the job by id; do not resubmit the paid request |
429 | Back off; use retry-after when present |
| Need a different generation | New request, new idempotency_key |
Unsafe HTTP submit with no Idempotency-Key | Do not retry |
How should goose's model generate the key?
The key should be stable per intended job, not per model turn. A model that writes a fresh random key on every attempt defeats the dedup. If your setup lets you wrap the tool call, mint the key outside the model and pass it in. For the broader goose setup, see goose as an MCP client for Sume.
How do I confirm only one job was created?
Read the job by id when you have one. Sume's MCP tools include jobs_status and jobs_result, and the docs list a batch jobs_wait that takes job_ids. If a call never returned an id, retry with the same key rather than a new one, then read the result. dry_run=true previews cost and admission without submitting, which is useful when you are testing a retry path.
Sources
Related posts
More in Developers
- GPT-5.5 retires Oct 14 in Codex: what to change for Sume
Codex retires GPT-5.5 on October 14, 2026. A Sume server entry names no model, and Agent Completions only accepts sume-agent, so check your own settings.
- gpt-image-2.5-flare-2026-09-08 on Sume: use openai/gpt-image-2.5
OpenAI lists the snapshot gpt-image-2.5-flare-2026-09-08. Sume documents catalog slugs, so send openai/gpt-image-2.5 and check /v1/images/models for ids.
- GPT Image 2.5 Flare: 5 images a minute at Tier 1 vs Sume limits
OpenAI limits Flare to 5 images per minute at Tier 1 and 250 at Tier 5. Sume applies plan concurrency, queue capacity and 429 codes instead. Both tables here.
- GPT Image 2.5 largest square: 2880x2880, not 3000x3000
GPT Image 2.5 caps pixels at 8,294,400. A square tops out at 2880x2880; 3000x3000 (9,000,000) is rejected. OpenAI calls sizes above 2560x1440 experimental.
Written by Sume