Skip to content
OpenRouter

Connector · AI models

OpenRouter, in every client’s workflows.

Ask a model, with the client’s own OpenRouter account.

Triggers
0start a workflow
Actions
1steps in a workflow

Do it in OpenRouter

A step with its own fields: values from the run go in by name, and what OpenRouter answers is there for the next step.

  • Ask a modelOne prompt, one reply (OpenAI-compatible): the output’s Reply.

Connect the client’s OpenRouter

On the client’s page in Thrum: Add credential, type OpenRouter API key.

openrouter.ai → Keys → Create Key. Set a credit limit on the key for this client.

The key is stored encrypted and bound to that client: another client’s workflow cannot use it, and no template or pack copies it.

OpenRouter’s API documentation

Watched like everything else

When OpenRouter stops answering or refuses the client’s key, you hear about it, and your client does not.

A failing request
Tried 3 times, 5 seconds apart and doubling, only for errors a retry can fix
A service that asks for a pause
Given it, up to an hour
Requests at once, per account
2, per worker; the rest wait their turn
Timeout
15 seconds, unless the step sets its own
Private and internal addresses
Refused, on every redirect too
The client’s key
Encrypted, bound to the client, and kept out of every run record
A step that keeps failing
Marks the workflow Degraded and alerts you, not the client

OpenRouter and its logo are trademarks of their owner, used here only to say what Thrum works with; no endorsement is implied.

Thrum is cooking.

Get early access and you’ll be among the first in. Early members get a launch perk.