DOCSEARCHbyAlgolia
Submit Docs

Runware Platform Documentation

website·Indexed 39 days ago

https://docs.runware.ai/

Developer documentation for the Runware platform, featuring SDKs for TypeScript and Python, a CLI, and integrations with ComfyUI, Vercel AI SDK, and the Model Context Protocol (MCP). Covers API authentication, model search and upload, media storage, task polling, webhooks, and streaming (SSE).

Tokens
44.8K
Snippets
202
Records
303
Agent score
60%

What's inside Runware

  1. Overview of Comfy Cloud

    Comfy Cloud is the official cloud-based version of ComfyUI, providing a zero-setup environment powered by NVIDIA RTX 6000 Pro GPUs. It includes pre-installed models and custom nodes, ensuring compatibility and removing the need for local hardware or installation. It is accessible via any device with an internet connection.

  2. Overview of Model Context Protocol (MCP) in Codex

    The Model Context Protocol (MCP) allows ChatGPT and Codex to connect to third-party documentation and developer tools (e.g., browser, Figma). MCP configuration is shared across the ChatGPT desktop app, Codex CLI, and IDE extensions. Codex supports two primary server types: STDIO servers (local processes) and Streamable HTTP servers (remote addresses).

  3. Overview of Runware Skills

    Runware Skills are packaged recipes that enable AI agents to achieve specific outcomes (e.g., 'product video') without needing to know the specific model catalog. They act as a routing layer: the agent matches a user's plain-language request to a skill's description, and the skill then selects the best available model for that task. This ensures stability for the user, as the underlying model can be updated by Runware without changing the skill's interface. Skills are not new endpoints but instructions that agents load and execute using existing Runware access methods like the MCP server, CLI, or SDKs.

  4. Understand Runware Skills and their purpose

    Skills are packaged, outcome-oriented instructions that provide an AI agent with the 'know-how' to achieve a specific result without manual scripting. A skill maps a user's natural language request to a specific model and set of parameters. While skills guide the agent's decision-making, the actual execution is performed via Runware SDKs, the MCP server, or the CLI. Use skills for autonomous agent results; use SDKs, MCP, or CLI for direct API control.

  5. Use TypedDict for compile-time parameter validation

    To get editor support and compile-time validation (via Pyright or mypy), import the specific TypedDict for the target architecture from runware.types.task_map.
    from runware import Runware
from runware.types.task_map import SdxlArchParams

params: SdxlArchParams = {
    "model": "civitai:133005@782002",
    "taskType": "imageInference",
    "positivePrompt": "A professional headshot portrait",
    "negativePrompt": "blurry, distorted",
    "width": 1024,
    "height": 1024,
    "steps": 30,
}

async with Runware() as client:
    images = await client.run(params)

  6. Configure Embeddings model upload parameters

    When uploading a model with the category set to embeddings, the architecture parameter is required. Additionally, you can specify the type of the embedding model.
    {
  "category": "embeddings",
  "architecture": "sdxl", // Allowed: illustrious, noobai, pony, sd1x, sdxl, sdxllightning, sdxlturbo
  "type": "positive" // Allowed: positive, negative
}

  7. Search and discover AI models using the Model Search API

    The Model Search API enables discovery of available models on the Runware platform, including public community models and private organizational models. Models found via this API are used in generation tasks by referencing their unique AIR identifiers. The API supports filtering by category, architecture, visibility, and tags, with results returned in a paginated format.

  8. Understand Runware capacity and rate limiting

    Runware uses a shared infrastructure model with dynamic queue-based systems rather than hard rate limits. Instead of arbitrary rejection, the platform employs graceful degradation: under high load, requests are queued, which increases latency rather than causing immediate failure. Processing capacity is distributed fairly across active users via model-specific queues.

  9. Execute concurrent operations with the Runware SDK

    Because the SDK uses a WebSocket architecture, it can handle multiple simultaneous operations without the overhead of multiple HTTP connections. Use Promise.all to trigger different tasks (e.g., image generation, upscaling, background removal) or multiple long-running tasks (e.g., several video generations) concurrently to maximize throughput.
    const runware = new Runware({ apiKey: "your-api-key-here" });

// Execute different operations simultaneously
const [generatedImages, upscaledImage, backgroundRemoved, imageCaption] = await Promise.all([
  runware.requestImages({
    positivePrompt: "Abstract digital art",
    numberResults: 3,
    width: 1024,
    height: 1024,
  }),
  runware.upscaleGan({
    inputImage: "some-uuid",
    upscaleFactor: 4,
  }),
  runware.removeImageBackground({
    inputImage: "some-uuid",
  }),
  runware.requestImageToText({
    inputImage: "some-uuid",
  }),
]);

  10. Run community checkpoints in ComfyUI

    To run a community checkpoint (e.g., SDXL or FLUX fine-tunes), use the architecture-specific nodes located under Runware/Custom models. Select the node that matches your checkpoint's architecture (e.g., Stable Diffusion XL, SD 1.5, FLUX.1 [dev], or Pony Diffusion XL). Set the model field to the checkpoint's AIR. You can use the search catalog button on the node to find compatible checkpoints and automatically fill the AIR.

  11. Understand Runware pricing models

    Runware uses two primary pricing structures:

    1. Serverless (Optimized Compute): Used for most open-source models (e.g., Stable Diffusion, Flux). Billing is based on the exact compute time (GPU seconds) used. Costs decrease as Runware optimizes inference speed. There are no charges for idle time or cold starts.
    2. Fixed Price: Used for closed-source or partner models. These have a predictable, standardized cost per request based on provider rates.

  12. Monitor run cost and safety flags

    After a run, model, architecture, and custom nodes display a status line on their title bar indicating the cost and content safety check results (e.g., $0.00078 · NSFW: no). These details only appear if the response from the API included cost or safety data.