Skip to main content
A workflow decides which model a request actually runs on. Your client keeps sending one stable model name; the workspace decides what sits behind it. You draw a graph in the console. One trigger node names the model clients ask for, check nodes inspect the request and your usage history, and a selection node names the model to run instead. When a request arrives for the triggering model, the gateway walks the graph and rewrites the model before dispatching. Nothing about the client changes. It does not know a workflow ran.

​
What it is good for

Sending traffic to a cheaper model once spend crosses a threshold. Falling back when a quota is exhausted. Routing requests that carry an image to a model that can see. Serving a different model at night. Each of those is a graph rather than a branch in your own code.

​
How a request reaches a workflow

  1. A client calls /v1/chat/completions or /v1/responses with a model name.
  2. Before the model is resolved, the gateway considers every enabled workflow in that workspace.
  3. The one whose trigger node names the requested model runs. If several match, the default configuration wins, and the oldest after that.
  4. If the graph reaches a selection node, the request’s model is replaced with the selected one.
  5. Anything else, including any error inside the workflow, leaves the request on the model it asked for.
A workflow can only ever change the model. It cannot alter the messages, the parameters or the response.

​
Defining what auto means

auto is a model name like any other, so a trigger node can name it. Build a workflow triggered on auto and it decides what the keyword resolves to for that workspace, using any of the checks available to any other workflow. The gateway’s own choice is only used when no workflow claims it, and it is not careful: see Models.
Workflows apply to /v1/chat/completions and /v1/responses. Requests to the Anthropic Messages endpoint are not routed through them.

​
Control flow

Execution starts at the trigger and follows edges depth first. A branch stops as soon as a node fails, and the first branch that reaches a selection node wins. Only the metric check node branches, with separate success and failure outputs. Every other node either continues along its edges or stops its branch. There are no loops. Cycles are rejected before the workflow runs, and a workflow that executes more than ten nodes is abandoned.

​
Limits

Only a workspace owner or admin can create or edit a workflow. Members can view them.
Node configuration is validated when a request runs, not when you save. A workflow that saves cleanly can still be rejected at request time, and a rejected workflow silently leaves requests on their original model. Check Metrics after enabling one to confirm it is routing.

​
Pages

Node reference

Every node type, what it reads, and how to configure it.

A worked example

A cost cap that downgrades the model once weekly spend crosses a threshold.