Skip to main content
OpenRouter handles model access and routing. Render Workflows handles the execution around those calls: queuing, retries, and parallel task runs. This guide deploys a small prompt batch. One task receives a list of prompts and fans out one retriable task run per prompt. Each run calls OpenRouter’s Auto Router and returns both the answer and the concrete model OpenRouter selected.
Each prompt becomes its own task run. Render provisions compute for those runs on demand and deprovisions it when they finish, so the fan-out does not require a pre-provisioned worker pool.
Render Workflow tasks do not expose HTTP ports. In a user-facing application, a Render Web Service receives the request and triggers the workflow. This guide starts with the workflow itself so you can deploy and verify the model pipeline first.

Prerequisites

You will need:

1. Create a workflow project

Use render workflows init to scaffold Render’s Hello World starter, then add the official OpenRouter Client SDK.
@openrouter/sdk is ESM-only. Use "type": "module" in package.json (or another ESM-compatible setup). CommonJS require() is not supported.
The scaffold includes the Render SDK, creates a .env.example file and Git repository, and prints commands for local development and deployment.

2. Add your OpenRouter key

Copy the scaffolded environment file:
Replace its contents with:
The scaffold excludes .env from Git. Do not commit API keys. The Render CLI loads .env automatically during local Workflow development. If a public application will trigger this workflow, also set APP_URL to that application’s URL. OpenRouter uses APP_URL and OPENROUTER_APP_TITLE for app attribution.
Use openrouter/auto for OpenRouter’s Auto Router. The openrouter/auto-beta slug is the early-access track where new routing behavior lands first; see Auto Router.

3. Define the workflow

Replace the generated task file with the following code. The inner task makes one OpenRouter request and retries failures. The outer task fans out across every prompt. Render runs each chained task separately, so a slow or retried model call does not prevent the other calls from running.
Auto Router can choose a different model for each independent prompt. Keeping completion.model in every result makes that routing decision visible.
A retried task can repeat a billable API call if the first request succeeded but the task failed before returning its result. For production workflows with external side effects, add application-level idempotency or checkpointing.

4. Test the workflow locally

Start Render’s local Workflow server:
In another terminal, start the batch task:
The outer JSON array contains the task’s arguments. The inner array is the prompts argument. The command returns a task-run ID. Inspect the completed run with:
A successful result contains one entry per prompt:

5. Deploy the workflow to Render

Commit the project and push it to GitHub, GitLab, or Bitbucket. From the project directory, create the Workflow service with the Render CLI. --repo . reads the remote URL from the Git repository. --env-file .env adds the OpenRouter configuration to the Render service without committing the file.
Render pulls the repository, builds the Workflow service, and registers both tasks. You can also create the service in the Render Dashboard by selecting New > Workflow and using the same build and run commands.

6. Run the deployed workflow

Start the deployed batch with its full task slug:
Inspect the returned task-run ID:
You can also open the Workflow service in the Render Dashboard to inspect the parent run, each chained model call, retries, logs, results, and the concrete model selected for every prompt.
Run render workflows tasks list and select the workflow, or copy the full task slug from the task page in the Render Dashboard.

7. Trigger the workflow from an application

The CLI is the quickest way to verify the deployment. A web service can start the same task through the Render SDK. Set RENDER_API_KEY in the web service or application environment, not in the Workflow service unless the Workflow itself needs to call the Render API.
Keep the web service focused on HTTP, authentication, and returning progress to the client. Put the OpenRouter calls in Workflow tasks so they can continue after the original request ends, retry independently, and fan out on demand. Use a shared environment group when the web service and Workflow service need the same OpenRouter configuration.

Deploy a complete example

Answer Arena is a TypeScript application that combines a Render Web Service, Render Postgres, Render Workflows, and OpenRouter. It fans out model configurations, streams progress to the browser, and records model, cost, and evaluation results.

Resources