Modal vs Thunder Compute

Modal

Scale to zero by default, per-second billing and about one-second container boots. No REST API or OpenAPI spec for deploying or invoking Functions.

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.

Modal

1. Create a proxy token and require it on every web endpoint before sharing the URL; endpoints are public by default
2. Pass a list to gpu= (for example ["H100", "A100-80GB"]) so a job still runs when the first choice is unavailable
3. Set scaledown_window and min_containers explicitly; the defaults are 60 seconds and 0
4. Use .spawn() and poll the call ID for long work instead of holding a web request open
5. Keep web endpoint traffic under 200 requests a second or ask Modal to raise the limit

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.