CoreWeave vs Modal

CoreWeave

Per-hour prices for 8-GPU H100, H200 and B200 nodes are public, the docs ship as Markdown with llms.txt and embedded OpenAPI specs, and IAM has read-only roles per service. An organisation must be approved by CoreWeave's sales team before any token exists, and no request rate limits were found in the reviewed documentation.

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.

CoreWeave

1. Create an API access token at console.coreweave.com/tokens with an expiry and send it as Authorization: Bearer to https://api.coreweave.com
2. Add GPUs by applying a NodePool resource (compute.coreweave.com/v1alpha1) to a CKS cluster with instanceType and targetNodes. instanceType can't be changed afterwards
3. Set targetNodes to 0 or delete the Node Pool when a job ends. Nodes are whole 8-GPU machines billed by the hour
4. Never pass dry_run to the MCP tool coreweave_kubectl_apply expecting a preview. The reference says the parameter is ignored and the manifest is applied
5. Use a separate Forge API key and https://api.inference.wandb.ai/v1 for Serverless Inference. A CoreWeave API access token doesn't work there

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