Beam vs Thunder Compute

Beam

Per-millisecond billing with cold starts and image pulls free, H100 PCIe at $3.50 and RTX 4090 at $0.69 an hour. No published request rate limits, 429 handling or SLA.

Thunder Compute

The hosted MCP server signs in with OAuth and separate read and write scopes, and the REST API has a public OpenAPI 3.1 document with keyless price and availability endpoints. No rate limits, SLA or API changelog were found, instance creation has no idempotency key, and instances cannot be stopped, only deleted.

Beam

1. Check the response body for ok: false on gateway calls; a failure can arrive as HTTP 200
2. Don't pipe beam deploy --format json output into CI logs, since it contains the workspace token
3. Route anything over 180 seconds to a task queue and poll the task instead of holding the endpoint request
4. Set keep_warm_seconds deliberately; the 180-second endpoint default bills three minutes of GPU after every call
5. Pass gpu=["RTX4090", "A10G"] so a job still schedules when one type is out

Thunder Compute

1. Call GET /v2/status or the get_availability tool before creating an instance. Availability can change before launch, and creation fails when a type is sold out.
2. List instances before retrying a failed create, because the call has no idempotency key.
3. Pass public_key on create. If omitted, the response carries a generated private key that is returned once.
4. To pause work, create a snapshot, delete the instance and later create a new instance from the snapshot. Snapshot storage keeps billing until deleted.
5. For headless use set TNR_API_TOKEN to a token from the console. The MCP server needs a browser sign-in on first connection.