Why Is a Model Listed on WaveSpeedAI but Not Available to Run Yet?
A model card does not always guarantee a runnable endpoint. Check its schema, account access, errors, capacity, and current availability.

Overview
A visible model card confirms discoverability, not necessarily that your account can run that model at this moment. A runnable integration also needs a valid endpoint, a current request schema, sufficient account access, available capacity, and inputs that meet the model’s requirements.
Check the failure layer in order
Start with the model’s API tab or the GET /api/v3/models response. Confirm that the model has an API path and request schema, then compare every required field with your payload. A 400 usually points to invalid parameters; 401 or 403 points to authentication or account access; 429 indicates a rate-limit constraint; a server error may be temporary.
Next, inspect the current model page and the response returned for your own account rather than copying an older code sample or inferring access from another user’s experience. Parameters, versions, and availability can change.
Staged rollout, regional restriction, capacity pause, and deprecation are possible explanations, but they should not be presented as WaveSpeedAI policy unless the current model page, status communication, or support response states them for that case.
Decide whether to wait or switch
If the endpoint exists but returns a transient failure, retain the task details and retry conservatively. If access is not confirmed, select a fallback model by capability rather than by similar name alone.
Keep availability observable
Store the model ID, schema version or retrieval date, HTTP response, and last successful run. That turns “listed but unavailable” into a diagnosable state instead of a production surprise.





