What every part of the studio does, how to get from nothing to a workflow running in your repository, and what is real today. The “?” buttons around the studio link to the entries here.
Design it here
A workflow is a diagram you drag together here. It is saved to your account, so it is there in any browser you sign in to.
Test it for free
A test run plays it back with simulated agents, usage and refusals. Nothing is called and nothing is billed.
Run it for real
On your own computer through relay connect, or exported as a GitHub Actions workflow that a label on an issue starts. Either way, your own subscriptions do the work.
Start here
Five steps. Each one links to the page where you do it, and ticks itself off once it is done.
Choose where your agents run, then sign them in
A real run needs the coding agents somewhere to run: on your own computer through relay connect, or on a machine Relay runs for you in Relay Cloud. Then sign in Claude Code with your Claude plan and Codex with your ChatGPT plan — the studio starts each CLI’s own login and never sees a token.
Pick a template
Start from a ready-made workflow such as Fix main when CI goes red, or a blank canvas. Using a template copies it; the original never changes.
Shape it in the builder
Drag nodes from the palette, wire ports whose colours fit, and fill in each node in the inspector. Validation points at problems as you go.
Run a test
Press Test run in the builder. It plays back with the same phases and refusals a real run has, calls nothing, and is recorded under Runs.
Export it to your repository
Export in the builder downloads a .zip with the config, a GitHub Actions workflow and a SETUP.md. Unzip it into the repository, add the secrets it lists, and it runs on your own minutes.
Anatomy of a workflow
A workflow is one trigger followed by whatever should happen next. Here is a small one, with what each part does and what the coloured dots mean.
Assigned to the bot
Assignee: @bot
Author allowlist
alice, bob
Run the pipeline
Standard review
Deliver the change
Draft pull request
Ask for review
#eng
Assigned to the bot · trigger
Something happened: a Linear issue was assigned to the bot. Every workflow has exactly one trigger, and it only has outputs. This one hands on a ticket.
Author allowlist · guardrail
Checks who asked before any agent starts. It has two outputs: the ticket carries on through Allowed, and Refused can be wired to a message so people learn why nothing happened.
Run the pipeline · agents
Plans, reviews, implements, reviews again and runs the tests, in its own worktree. It only accepts a ticket, and hands on a finished run.
Deliver the change · delivery
Turns the run into a change: here a draft pull request. A run somebody else started may never merge on its own; the validator refuses that wiring.
Ask for review · notify
Tells the team. It accepts a change, so it can only be wired after delivery. Any of the catalog’s apps can sit at the end of a workflow like this.
The same rules apply to every node in the palette: inputs on the left, outputs on the right, and a wire only where the colours fit. Open any template in the template gallery to see a complete one.
Port colours
The dots on each node are typed. A wire is allowed when both ends are the same colour, or either end is light grey.
Inside the pipeline
The Agent pipeline node is where the coding agents work. A run goes through these phases in order; the review phases repeat as the review level allows. You can watch them in any run’s timeline.
Prepare
Fetching issue
Reads the ticket the trigger handed over: title, body, labels and links.
Creating workspace
Creates an isolated git worktree on a fresh branch, named from the branch prefix and the ticket, so your own checkout is never touched.
Plan
PlanningPlanner · Claude Code
Reads the code and writes plan.md: what will change, where, and how it will be tested.
Plan reviewPlan reviewer · Codex repeats
A different agent checks the plan against the real code, read-only, and lists what is wrong or missing.
Plan revisionPlanner · Claude Code repeats
The planner answers the review. Review and revision repeat until the reviewer has nothing left to raise or the round limit is reached.
Build
ImplementationImplementer · Codex
Makes the change in the worktree. The diff you see afterwards is computed from git, not from what the agent says it did.
Code reviewCode reviewer · Claude Code repeats
The other agent reviews the diff, read-only. The test suite can run at the same time, since neither needs the other’s verdict.
Code revisionImplementer · Codex repeats
The implementer fixes what the review found, again up to the round limit.
Verify
Tests
Runs the project’s own test suite, detected automatically or the command you set. The suite has the last word: if it fails, so does the run.
Then delivery. The pipeline hands its run to the Deliver node, which commits, pushes, opens a pull request or merges, as far as its policy and the unattended rules allow. A secret scan runs before anything is pushed.
Concepts
The same explanations the “?” buttons show, in full. Link to any of them with its # anchor.
A graph that says what starts a run, what checks it, what the agents do, and where the result goes.
A workflow is a diagram you drag together: one trigger on the left, then gates, the agent pipeline and delivery, then whoever should hear about it. Relay saves it to your account, can play it back as a test run, runs it for real on your computer as it is drawn, and compiles it into files a repository runs with the relay CLI or on its own GitHub Actions minutes.
Show meThe event that starts a workflow: an issue assigned, a label added, a schedule, a webhook.
Every workflow starts with exactly one thing that happened. Triggers come from apps (Linear, GitHub, Sentry, Zendesk…), from a schedule, from an incoming webhook, or from a Manual start button. A trigger has only outputs; it hands its payload — usually a ticket — to whatever it is wired to. In a test run every trigger fires with a sample. For real, a label on a GitHub issue is the one that starts an exported workflow by itself today; the others are started by a person, with a ticket.
A step that does something: post to Slack, run the pipeline, open a pull request, call a URL.
Actions take something in on the left and pass something on to the right. Some have more than one output — a Condition has True and False, a Budget gate has Within budget and Refused — so the graph can branch on what happened.
The dots on each node. Colours are types: a ticket only plugs into something that accepts a ticket.
Each colour is a type. One carries a ticket: an issue with a title and a body. One carries a finished pipeline run. One carries a change: a branch or a pull request. One is a plain “this happened” event, and the faintest accepts anything. Hover a dot to read which it is. Inputs are on the left of a node, outputs on the right. The canvas refuses a connection whose colours do not fit, so a nonsense graph cannot be drawn in the first place.
Plan → plan review → implement → code review → tests, in an isolated git worktree, by two different agents.
The pipeline is what Relay is for. One coding agent writes a plan, a different one attacks it against the real code, the plan is revised, one implements, the other reviews the diff, and the project's own test suite has the last word. Everything happens on its own branch in its own worktree, so your checkout is never touched. It takes a ticket in and hands a finished run out. The Fast run variant skips both reviews for small, well-described tickets.
The command-line tools that do the work, such as Claude Code and Codex, each signed in with its own account.
Relay does not bring its own model. The pipeline drives coding CLIs you already use: Claude Code and Codex. Another CLI can be plugged in as a harness in the repository’s config, but those two are the ones built in and tested. Each runs inside the run's worktree on its own account, so the plan you already pay for does the work. Two different agents checking each other is what makes the reviews worth having.
Show meWho plans, who reviews the plan, who implements and who reviews the code.
Cross-model review is the point: the planner and the plan reviewer should be different agents, and so should the implementer and the code reviewer. Reviewers always run read-only, which is why an agent with no read-only mode can implement but never review.
How hard the agents check each other: Light (one round), Standard (two each), Thorough (three each).
More rounds find more problems, and take more time and usage. Standard is the default; Light suits small, well-described tickets; Thorough suits anything you would not want to review twice yourself.
A separate checkout on its own branch where a run does all its work, so your own checkout is never touched.
Before any agent starts, the pipeline creates a git worktree on a fresh branch named after the branch prefix, the ticket and its title. Agents edit files there, tests run there, and delivery pushes from there. If a run fails or is stopped, the branch and the work so far stay behind for you to inspect.
Checks that sit in front of the pipeline and refuse by default: allowlist, approval, kill switch, and a budget if you set one.
Gates exist because anything that can be triggered by somebody else can start agents on your plans. Each gate has a pass output and a refused output. Wire the refused one to a Slack message and the team learns why nothing happened, instead of wondering.
Optional. Refuses to start a run when it would cross a per-run or per-day ceiling you set.
The pipeline reports what each agent turn used, in the dollars the coding CLIs report, and the budget gate compares the running totals against your per-run and per-day ceilings before anything starts. It never queues work for tomorrow: a refused run is refused, and says why. It is optional: runs use your own Claude and ChatGPT plans, so with no gate there is simply no ceiling. It is worth adding when the agents run on API keys, which are billed per token.
Only the listed people or teams may start a run. An empty list means nobody may.
On a public repository, a label anyone can apply is an invitation to use up your plans. The allowlist checks who asked before anything else happens.
Holds a run for a named person’s yes or no. A real run waits for the answer; a test run plays one.
Use it where a run should not start just because a ticket arrived — customer-reported bugs, anything expensive, anything touching production code. A real run stops here until somebody answers: with Approve or Reject in the run panel, or relay workflow approve in the repository. A no, or nobody answering before the timeout, takes the Rejected path. In a test run the answer is played: approved most of the time and rejected now and then, so both branches get exercised. The exported GitHub Action does not perform this step, and Export says so.
A flag re-read before every start. Turn it off and no new unattended run begins.
It does not stop runs already in progress; it stops the next one. That makes it safe to flip at any time.
How far a finished run carries its work: leave it, commit, push, open a pull request, or merge.
The delivery node turns a run into a change. A run started by somebody else — a ticket assignment, a label, a schedule — may open a pull request but may never merge; the validator will stop you from wiring that. A secret scan runs before anything is pushed.
Any run nobody pressed a button for — a ticket, a label, a schedule, a webhook.
Unattended runs are held to stricter rules: they may never merge, and the validator warns when there is no allowlist in front of the pipeline.
Checks the graph against the same rules the CLI enforces, as you edit.
Errors stop a test run and an export: a missing trigger, ports that do not fit, a loop, a reviewer that cannot be read-only, an unattended run that could merge, a required field left empty. Warnings are advice — no allowlist, the same agent grading its own work — and never block you.
Plays the workflow back in your browser with a sample ticket. Free: nothing is run and no agent is called.
A test run walks your graph node by node with the same phases, review rounds and refusals the real pipeline has, using a sample payload from the trigger (or one you type). It is seeded, so the same workflow replays the same run until you change it. Nothing is called and nothing is billed; the usage and times shown are drawn from typical ranges per phase, not measured. Its record is saved to your account like any other run. How fast it plays back is a setting.
Show meOne execution of a workflow, with every node it touched, what it used, and what it delivered.
Runs are recorded here with a timeline, the pipeline phases, the usage per phase, the diff, the tests and the pull request. Open one to see exactly what happened and why.
Show meThe steps inside the pipeline: fetch the issue, create the workspace, plan, review, implement, review, test.
Each phase names the agent that did it, how long it took and what it used, so you can see where the time and usage went. Plan review and code review repeat for as many rounds as the review level allows, and stop early once the reviewer has nothing left to raise.
Show meThe dollar figure the coding CLIs report for each turn. Relay bills nothing: a run uses your own plans.
Relay bills nothing for a run. The agents use your own Claude and ChatGPT plans, and the figure shown is what Claude Code and Codex report for each turn, summed per phase. On a subscription it measures how much of the plan a run used, and nothing extra is billed; on an API key it is what that account is charged. In test runs the figures are simulated from realistic ranges per phase. A Budget gate, if you add one, compares against the same number.
Show mePlaceholders like {{issue.title}} or {{run.prUrl}} that are filled in when the workflow runs.
Text fields marked as templates accept variables. Use the Variables button next to the field to insert one: issue.* comes from the trigger, run.* from the pipeline, workflow.* and product.* are always there.
Compiles the workflow into files a repository needs to run it on its own GitHub Actions minutes.
You get .relay/config.json (what the Relay CLI reads), the workflow compiled for the CLI under .relay/workflows/, a GitHub Actions workflow under .github/workflows/, a SETUP.md listing the secrets to add, and the graph as JSON so it can be imported again. Commit them, add the secrets, and the workflow runs on your repository with your own subscriptions: as drawn with relay workflow run and relay workflow serve, or on GitHub Actions. Nothing is hosted or billed by Relay. The Action is narrower than the canvas: it works on one GitHub issue per run and cannot evaluate a Condition or wait for an approval. So each step is placed by where it sits in the graph, a step the Action cannot decide is left out, and every such difference is listed as a warning in the export.
Values the exported Action reads from your repository settings: agent credentials and webhook URLs. The studio never sees them.
SETUP.md lists every secret an export needs, by name. Claude Code needs CLAUDE_CODE_OAUTH_TOKEN (subscription) or ANTHROPIC_API_KEY (API key); Codex needs CODEX_AUTH_JSON (subscription) or OPENAI_API_KEY (API key); Slack, Discord and bridged actions add their webhook URLs. Add them under the repository’s Settings → Secrets and variables → Actions, or with gh secret set.
Show meA real run executes on the runner you picked — your computer or Relay Cloud — and an exported workflow runs unattended on your repository’s own GitHub Actions minutes.
There are three places work happens, and they answer different questions. The runner you picked (/runners): "Run on your computer" sends the whole workflow there and performs every step of it, with your own sign-ins, streaming each back to the canvas; "Run in Relay Cloud" runs the pipeline and its delivery. A machine of your own, unattended: relay workflow serve keeps a workflow's trigger — an incoming webhook, a schedule, a label — and runs it each time. Your repository’s GitHub Actions: Export compiles the graph into plain files you commit; a label on a GitHub issue is a real trigger there, on your own Actions minutes, free on public repositories. Your browser: a test run never executes anything; it is played back node by node with simulated agents, usage and refusals. Hosted microVMs for exported runs and a self-hosted runner in your own network are planned, not built.
The place a run actually executes and your coding agents are signed in: your own computer through relay connect, or a machine Relay runs for you.
Two runners, one protocol, the same result either way. Your computer: relay connect inside a repository, reachable only on 127.0.0.1, with your sign-ins in the CLIs’ own files where they already are. Free, but only while that process is running. Relay Cloud (invite-only beta, where a deployment offers it): a Linux machine of yours that Relay makes, and puts to sleep after ten idle minutes. Nothing to install, no terminal, and it wakes in about a minute when you press Run, so it works from any browser even with your laptop shut. It runs one run at a time. It needs an account, because Relay Cloud knows your machine by your sign-in, and it has no public address: it dials out, and only your own signed-in studio reaches it.
Whichever you pick, the agents run with your own Claude and ChatGPT plans, the studio never asks you for a model credential and has no route that reads one, the code lands in your repository as a branch and a pull request, and test runs stay free in the browser. What does differ is where things sit: on your computer, your checkout and sign-ins never leave it; on Relay Cloud they live on your own cloud machine’s disk, which Relay operates and which goes away when you remove the machine. You choose which runner sign-ins and runs go to, and every run remembers the machine it started on, so switching never orphans one.
Show meThe Relay CLI on your computer, paired with the studio: it signs in your coding agents, runs workflows for real and installs exports.
The studio draws, checks and compiles workflows in your browser; your coding agents, their sign-ins and your repository are on your computer. relay connect, run inside a repository, starts a small server on 127.0.0.1 that only a paired studio may use, and prints a link that pairs this browser with it. From then on the studio can start Claude Code’s and Codex’s own sign-ins, run a workflow’s pipeline for real in that repository — streaming every phase back to the canvas — and install an export straight into it. Test runs stay free and in the browser either way. The pairing token never leaves the browser and your computer, and relay connect never reads an agent credential. Relay Cloud, where it is offered, is the same job on a machine Relay runs for you instead; /runners compares the two.
Which apps a workflow may talk to. Most connect for real, with a webhook or an API token the studio checks with the app; the rest can be marked ready.
You can design and test against the whole catalog without connecting anything. Slack and Discord take a webhook URL, which can post to one channel and do nothing else. Apps such as Linear, Sentry, Vercel and Notion take a key or token you make in their settings, which can do what you allowed it there. Either way the studio checks it with the app, keeps it encrypted in your account and only ever shows its last four characters; a run does not act through a stored token yet. Apps that need more than one pasted value can be marked ready, which records a label and signs in to nothing, until their own sign-in is built.
Show meClaude Code signs in with your Claude plan and Codex with your ChatGPT plan. No API keys to paste.
The studio asks the CLIs on your runner whether they are signed in, and can start their own sign-in flow from Settings → Coding agents. It never sees or stores a token: the credential lands in the CLI, exactly as if you had signed in from a terminal. For GitHub Actions, the export uses each vendor's supported way to carry a personal plan into CI (CLAUDE_CODE_OAUTH_TOKEN, CODEX_AUTH_JSON), or API keys if you prefer.
Show meReady-made workflows built from the live catalog. Use one, then change anything.
Each template is a complete, valid graph. Using it copies it into your workflows; the original is never changed.
Show meWhere runs happen
A real run happens wherever your coding agents are signed in, and there are two runners for that. Everything else about the run is the same, so the only real question is which machine should do the work.
| What differs | Your computer | Relay Cloud |
|---|---|---|
| Setting up | Install the CLI, then run relay connect inside a repository. It prints a link that pairs this browser. | None. Press Make my machine and it is made for you, in about five minutes the first time. |
| Who starts it | You, at your keyboard. | Relay, when you press Run. |
| When it is there | While relay connect is running. Close the terminal, or the lid, and there is no runner. | Always. It wakes for a run, sleeps when idle, and keeps every sign-in between runs. |
| Where your code is | In a worktree beside your own checkout. Your working copy is only read. | In a worktree on that machine’s disk, from the repository you name on the run. It stays there between runs, and goes with the machine when you remove it. |
| Where the sign-ins sit | In the CLIs' own files on this computer — the Claude and Codex you already signed in to. | In the CLIs' own files on that machine, signed in once through the browser and kept. Relay's code has no route that reads them. |
| Who holds your code | Only on your computer. Nothing of yours is copied onto Relay infrastructure. | On your cloud machine, and nowhere else: one VM per person, holding your checkout and your sign-ins. Relay operates the machine; your code and credentials sit on it until you remove it. |
| Needs an account | The studio does. The computer itself needs none: Relay never registers it, or knows it exists. | Yes. Relay Cloud verifies your session, so the machine is yours and nobody else’s. |
| What it costs you | Nothing but your own hardware. Model usage counts against your Claude and ChatGPT plans. | Nothing is billed to you during the beta. No API fees either, as on your own computer: model usage counts against your own plans. |
| Limits | Whatever your computer can take: each run has its own worktree. | One run at a time, on a small Linux machine. Places are limited during the beta: when every machine in a region is awake, yours waits for room. |
| Local-only work | Xcode builds, simulators, local services, private networks, localhost dependencies. | The Linux command line and the repository. No Xcode, no local services, no private network. |
| Who can reach it | 127.0.0.1 only, and only a studio holding the token from your terminal. | No public address. It dials out to Relay, and only your own signed-in studio reaches it. |
| Runs nobody is watching | Not yet: nothing can reach a computer that is switched off. Exported workflows on GitHub Actions run unattended. | Not yet: waking a machine from an event comes later. Exported workflows on GitHub Actions run unattended. |
The same either way
Work that starts by itself has two more places, neither with a Relay server in it. On a machine of your own, relay workflow serve keeps an exported workflow’s trigger (a webhook, a schedule, a label, an app’s own events) and runs every step. On your repository’s own GitHub Actions minutes, a label on a GitHub issue starts the pipeline.
So which one?
Pick your computer if…
you work on macOS, need Xcode or a private network, or want your code and sign-ins to stay on hardware you own.
Connect your computer →Pick Relay Cloud if…
you want to start a run from any browser, keep working while it runs, or never install anything at all.
Set up Relay Cloud →Pick either if…
the work is just “open a reviewed pull request”. You can set both up and switch between them; each run remembers where it started.
Switch in Settings →Real or simulated
Most of the studio is the real thing. Test runs are played back, so you can design and try a workflow before anything runs for real.
| What | Status | What that means |
|---|---|---|
| The catalog, the canvas and validation | Real | Every node and rule you see is the one the export and the CLI use. |
| The compiler and its files | Real | Export produces a config, an Actions workflow and a SETUP.md you can commit today. Steps the Action cannot decide are left out, and the export lists them. |
| Signing in to Claude Code and Codex | Real | Through the runner: runs the vendors’ own CLI logins on your computer, or on your machine in Relay Cloud, and reads their status. |
| Running a workflow for real | Real | On your computer, through relay connect or relay workflow run: every step, as drawn. The guardrails decide, the conditions are evaluated, the pipeline runs in the repository with your own sign-ins, and the steps after it post where they say. A Relay Cloud machine runs the pipeline and its delivery. |
| Human approval, Conditions, Filters, the AI step, waits and the cost estimate | Real | Performed in a real run. An approval waits for a person: answered in the run panel, or with relay workflow approve. A Filter is evaluated the same way in a test run. The exported Action still does not perform them. |
| A run started by a webhook, a schedule or a label | Real | relay workflow serve keeps the trigger on a machine of your own: it listens for the incoming webhook (signed deliveries, when a secret is set), keeps the clock for a schedule, and watches for a label on a GitHub issue. |
| A run started by GitHub, Linear or Sentry | Real | relay workflow serve reads the webhooks those apps send, signed with the secret you gave them: an issue assigned or labelled, a build gone red, a security alert, a new error. Written against the apps’ documented deliveries; a delivery it does not recognise starts nothing and says why. |
| Steps in Slack, Discord, GitHub and Linear, and HTTP requests | Real | Posted through a Slack or Discord webhook, done with gh, done through Linear’s API with your key, or sent to the URL. Each reads its credential from the runner’s environment; none is written into the workflow. |
| Installing an export into your repository | Real | Through relay connect on your computer, or by unzipping the download yourself. |
| An exported workflow running in your repository | Real | Runs on GitHub Actions with your own minutes and subscriptions, started by a label on an issue. The Action runs the pipeline and the steps it can place; it does not make the decisions the canvas draws. |
| Accounts, sync, share links and version history | Real | Kept in the studio’s database, under your account. |
| Describe-to-workflow and the usage forecast | Real | The sentence parser runs in your browser with no model call. The forecast is built from simulated runs, so it is an estimate. |
| Importing and exporting your data | Real | Everything in your account as one plain JSON file, and back again. |
| Slack and Discord connections | Real | A webhook you paste is checked with the app and kept encrypted. The studio posts test messages through it; an exported workflow posts with the same URL held as a secret in its repository. |
| Signing in to other apps with a key or token | Real | Linear, Notion, Sentry, Vercel and the other apps that take one pasted token: the app confirms whose it is, and the studio keeps it encrypted and asks again from the dashboard. A run does not act through it yet; it still reads its credentials from the runner’s environment. |
| Test runs | Simulated | Phases, review rounds, costs, refusals and pull request numbers are played back, seeded per workflow. |
| Steps in every other app | Simulated | Connected or marked ready, you can design against the whole catalog; “Mark ready” records a label and signs in to nothing. In a real run each such step is handed to a bridge of your own (BRIDGE_WEBHOOK_URL: n8n, a Zapier catch hook, your server), or skipped, and the run says which. |
| A run started by any other app’s own events | Not built yet | Nothing reads Zendesk, Slack, LaunchDarkly, Jira or the other CI services yet. Point the app’s webhook at an Incoming webhook trigger, which is real, or start the workflow by hand. |
| Transform, and approvals asked in Slack or by email | Not built yet | Transform passes its payload through unchanged. An approval is answered in the studio or at a terminal, not from a chat message. |
| A runner in your own network, or one isolated VM per exported run | Not built yet | A machine of your own can join Relay Cloud by hand; the studio does not offer it. Exporting to GitHub Actions is what runs unattended today. |
Keyboard shortcuts
Press ? anywhere to open this list in a dialog. Single-letter shortcuts are ignored while you are typing in a field.
Anywhere
In the builder
Questions
Costs, privacy, where things run, and what you get out of it.