Sonnet 5.5 on AWS, Google Cloud or Azure: one Sume key, one wallet

Moving a Sonnet 5.5 agent between clouds does not change how it pays Sume. Anthropic's page lists Sonnet 5.5 as available on Claude Platform, AWS, Google Cloud and Microsoft Azure (read 2026-10-05). Sume sees none of that. It sees one credential, one workspace and one wallet, whichever cloud hosts the model.

What Sume keys on

The Sume docs say the API key or the app session selects the workspace. Tools must not accept a workspace id from the user (Safe automation). So the hosting cloud never appears in billing. Two copies of the same agent on two clouds, using the same key, draw from the same wallet and the same concurrency limits.

Two agents, one wallet

The consequence is easy to miss. A team that runs a staging agent on one cloud and production on another may point both at one workspace key. Each agent's per-run cap is then independent, but the balance and the workspace generation concurrency are shared. Plan caps with that in mind.

Generation concurrency is plan-based. The admission docs list Free at 1 processing slot and Scale at 20, and the effective value is the concurrency_limit in submit responses (Generation admission). Two busy agents on one key compete for those slots.

Auth for each client

For a server-side agent, use an API key on the hosted MCP endpoint (Authorization: Bearer or x-api-key). For an interactive client, use OAuth. The docs state that you cannot swap one credential for the other, and that an OAuth token is not an API key. Do not paste either into prompts or logs.

• Give each deployment its own key where you can, so one leaked key is rotated alone.
• Log the Sume request_id, not keys or signed URLs.
• Keep per-run caps on Agent Completions even when the model host enforces its own token budget.

What to watch when two deployments share a key

Read generation_limits from the submit response rather than hard-coding a limit. The admission docs describe active_generation_jobs, queued_generation_jobs and queue_capacity_remaining as a snapshot that can change right after the response, because other clients on the same workspace submit work too.

If both deployments hit 429 queue_full, neither is at fault. The workspace used all of its accepted capacity. Back off, cancel queued jobs you no longer need, and retry with the same idempotency key once capacity opens. Separate keys do not separate capacity, because capacity belongs to the workspace, not the key.

Checklist when you move clouds

Re-test two things only. First, that the new platform exposes the tool features you rely on, which is a question for the model vendor's page. Second, that your Sume key is injected as a secret in the new environment. Everything else about the Sume call is the same.