Same Idempotency-Key, two Sume members: two jobs, not one

On Sume, an Idempotency-Key is unique per workspace and per member who owns the API key, not across the whole workspace. If two teammates send the same key string, each gets their own job and each is billed. A retry by the same owner with the same key and the same payload returns the original job.

Where the scope comes from

The Jobs docs say a job belongs to its workspace and to the member whose key created it, and that usage is recorded against that member. The job store enforces the key with a unique index over workspace, owner and key, and the replay lookup uses the same three values.

What to do about it

A key like test-1 will not collide between two people, which feels safe, but it means a shared script run by two people can bill twice for one intended render. Derive the key from the thing you are making, and decide which one worker or member owns the submit.

• Build the key from your own record id plus a version, for example an order id and an attempt number.
• Use one service key owner for unattended submits, so retries always land in one namespace.
• Never reuse a key for a different prompt: the same owner would get 409 idempotency_conflict.

Check a key without spending

Every job object carries the idempotency_key it was created with. List your own jobs and look for the key before you decide it is unused.