> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nemu.cc/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflows

> Route a request through logic before it reaches a model

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 looks for an enabled workflow in
   that workspace.
3. If the workflow's trigger node names the same model, the graph runs.
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.

<Note>
  Workflows apply to `/v1/chat/completions` and `/v1/responses`. Requests to the
  Anthropic Messages endpoint are not routed through them.
</Note>

## 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

|                            |                                                           |
| -------------------------- | --------------------------------------------------------- |
| Nodes per workflow         | 30                                                        |
| Nodes executed per request | 10                                                        |
| Trigger nodes              | exactly 1                                                 |
| Selection nodes            | 1 or more                                                 |
| Workflows per workspace    | 3 free, 20 starter, 50 pro, 250 max, unlimited enterprise |

Only a workspace owner or admin can create or edit a workflow. Members can view
them.

<Warning>
  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.
</Warning>

## Pages

<CardGroup cols={2}>
  <Card title="Node reference" href="/workflows/nodes">
    Every node type, what it reads, and how to configure it.
  </Card>

  <Card title="A worked example" href="/workflows/example">
    A cost cap that downgrades the model once weekly spend crosses a threshold.
  </Card>
</CardGroup>