Running a Runware task

Runware exposes one request shape across every modality: you send a task with a taskType, a model (the AIR), and the parameters that model's schema allows. This skill is the execution contract. Outcome skills decide what to run; this skill is how to run it without guessing.

The contract (follow in order)

1. Pick the model + taskType. Get the model from runware-models (live lookup). The taskType follows the modality: imageInference for images, videoInference for video, audioInference for audio, modelUpload for custom models. A just-launched model not yet in the SDK registry throws "Unknown model" - pass taskType explicitly to bypass that.
2. Inspect the schema before calling. Resolve the model's JSON Schema (the SDK and MCP do this for you). Use only fields the schema allows, and mirror its field names exactly. Never invent or guess parameter names - if it's not in the schema, it does not exist.
3. Provide inputs as URLs or base64. Local files get uploaded first (the SDK/MCP have an upload step). Reference images, source video, audio, masks all go under the model's documented input fields.
4. Run with the right delivery mode:
   • Images / fast tasks → synchronous. The call returns the finished result.
   • Video / audio / 3D / training → asynchronous. The task returns a taskUUID; poll getResponse until it reports terminal. Don't block a single sync call on a minutes-long job.
5. Read the result. Images return image URLs; video returns videoURL; 3D returns files under outputs.files[].url. Check the modality's result shape, don't assume.

Cost discipline

• Dry-run first when uncertain. Add the header X-Runware-Dry-Run: 1 to validate a request and get its cost without executing or being charged. Safe even for destructive task types. Use it to confirm the schema gate and the price before a real run.
• Set includeCost: true to get the real cost back on a live run.