Modal vs Verda

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.

Verda

The REST API has a public OpenAPI 3.1 document, a dated changelog, published rate limits with Retry-After, and an audit log endpoint. The CLI's MCP server refuses billed or destructive calls without confirm: true. Access needs a browser signup and a prepaid balance, credentials carry one scope, and instance creation has no idempotency key.

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

Verda

1. Exchange the client ID and secret at POST /v1/oauth2/token, then send the access token as a Bearer header. It expires after 3,600 seconds, so refresh it.
2. Send location_code on every create call. Requests without it have returned 400 since March 2026.
3. Call GET /v1/instance-availability before launching. POST /v1/instances returns 503 service_unavailable when the location has no capacity.
4. List instances before retrying a failed launch, because create has no idempotency key.
5. Use the delete action to stop charges. shutdown keeps billing, and deleted volumes stay recoverable for 96 hours unless delete_permanently is set.