Skip to main content
Use this when you prefer to click to type, or you want to see a run as a diagram. The UI is part of the server, so there is nothing to install. Everything it does goes through the REST API, so anything you can click you can also script. Use the CLI is the same tour for the terminal. Prerequisites: open the server address in a browser: http://localhost:9858 by default. With no key configured (the default on loopback) the UI asks for nothing. When the server answers 401 or 403, the UI asks for the API key once and sends it as Authorization: Bearer <key>. The key stays in that browser tab and is gone when the tab closes. Change API key is in the account menu. Controls your key’s role cannot use are shown disabled. A narrow rail (a tab bar on a phone) links to Sessions, Runs, Plugins, Supervisors and Control. The search box and jump palette is on ⌘K (Ctrl+K), and the account menu holds the theme toggle (light, dark or system). A breadcrumb row shows where you are.

Find a session and its workflows

  1. Open Sessions (/sessions, also where / leads).
  2. Search by name or id, then select a row. The session page shows its description, tags, initiator and working directory, and one card per workflow with its node and edge counts and the status of its latest run.
  3. Select a card to open the workflow.
Create one with New session: it asks for an id, name, description, initiator and the working directory on the server, saves the session with a starter workflow main (an API trigger wired to a console terminal) and opens the editor on it. Import JSON creates a session from a file or pasted JSON. Export JSON on a session’s page downloads its configuration. Edit changes its name, description and tags. Delete asks you to type the id first, and deleting a workflow works the same way. New workflow on a session’s page opens the editor on an empty workflow.

Build or edit a workflow without JSON

  1. On a workflow page, select the pencil (Edit), or choose New workflow on a session page. The address is /sessions/<id>/workflow/<id>/edit.
  2. Add a node: pick a plugin type, grouped as triggers, processors and terminals, and select Add node. Each node gets a unique id such as mapper-1.
  3. Configure it: select the node to see its form. The form comes from the plugin’s own description of its options, so each option has the right control: a text box, a number box, a switch, a dropdown, a monospace box for expressions, a JSON box for lists and maps, and a credential box that expects a decrypted:<key> reference. An option you leave empty is left out, so the plugin default applies. A plugin that declares no options gets a JSON editor and its usage notes.
  4. Set failure behaviour: every node has an expandable section for retries, timeouts, what a failing message does and when a node with several parents starts. See Handle failures.
  5. Connect nodes: choose a source node, optionally one of its output ports, and a target, then Add edge. After you change a node, select Validate so its port list refreshes.
  6. Validate checks the draft with the rules the server applies before a run and shows the first problem, or “Workflow is valid.” Save validates first and, only if the draft is valid, saves the whole session and opens the workflow page.
The model behind the forms is in Define a workflow.

Run a workflow and watch it

  1. Open the workflow and select Run. A box accepts an optional JSON trigger payload, starts the workflow and selects the new run.
  2. Watch the graph. Each node is a card with an accent colour for its role and a state: done (green dot), active (pulsing dot, with a percentage when the node reports progress), waiting (dimmed), failed (red border; covers failure, error, timed out and aborted), paused (amber) and skipped (faded; covers stopped, cancelled and upstream failed).
  3. A workflow whose node ids share a prefix before the first dot (or declare a group) is grouped into stages. A stage with a failed node opens by itself; ?stages=all in the address shows every node.
  4. Switch between Graph and Timeline. The timeline draws one bar per node, so you see what ran in parallel and where the time went.
  5. Select a node to open its panel: status and timing, its configuration (secrets masked), the log lines it wrote and the actions that fit its state. The node is kept in the address as ?node=<id>.
  6. Open Workflow progress for three blocks: the execution summary, the Result (what reached the terminals, streamed live), and the task sequence in execution order.
  7. Execution logs at the bottom streams the run’s lines with time, level and node, and has a filter box, a follow switch with Jump to latest, a copy button, and a menu for line wrap, raw lines and downloads (.log or .jsonl). It keeps the newest 20,000 lines and says how many earlier ones are hidden.
Run History in the breadcrumb row lists the runs of this workflow, newest first. The selection is kept in the address as ?exec=<id>, so you can link to a run.

Steer a run

The run controls sit above the graph. Each one asks only for what fits the run’s state: Every node has a menu with only the actions that make sense for its state: pause, resume, stop, skip, retry a failed node, step mode and Step once, Set breakpoint…, and Restart from here. The stop modes are the same as in the API. See Control a run. Copy as… gives the same action as a yukta-cli command, a curl call or an MCP tool call, ready to paste into a script. Versions (in the Workflow actions menu) opens the saved versions. For each one you can see what changed against the current definition, write a note, or Roll back. A rollback becomes a new version, so you can undo it. See Validate and roll back.

Answer an approval

When a node waits for a person, the Inputs panel above the graph lists the open requests with the prompt, the risk and the run. Choose an option (Approve or Reject for an approval), type a free answer, or select Escalate to hand it to the next tier. A high-risk answer asks for confirmation. See Ask for input and Route input requests.

Search past runs

Open Runs (/runs, also where /history leads). It searches the runs of every session, newest first. Filter by session, workflow, status, text in the run id and a time range. The chips above the table count runs by status, and selecting one filters the table. Each row opens the workflow page with that run selected.

Browse the plugin catalogue

Open Plugins (/plugins). Plugins are grouped as triggers, processors and terminals. Select one for its description, its option table, its output ports, a node you can copy, and the workflows that use it. A plugin you add yourself appears here too: see Write a plugin.

See supervisors

Supervisors (/supervisors) is a list on the left and the chosen supervisor on the right. Each row shows whether it is live or in dry run, the id of its decision maker and how many targets it owns; Direct control is last, for the workflows nobody owns. Selecting one shows its numbers (applied, refused, rate limited, what it owns, its last decision), a map of who decides, who it reports to and what it owns (click a supervisor, workflow or node to open it), and tabs: Owns, Allowed operations, Hierarchy, Decision maker, Settings, Changes and Decisions. The address keeps the choice: ?supervisor=<id>&section=<tab>. Decision maker types opens the catalogue of kinds you can choose for a supervisor, and New supervisor (/supervisors/new) creates one; each supervisor has its own editor at /supervisors/<id>/edit. What the supervisors did, across all of them, is on the Activity tab of Control. The workflow page also shows who owns the run you are looking at. For what to do with them, see Assign a supervisor.

Check the server

Control (/control, titled Control bus) has three tabs. Overview shows pending input requests, supervisors, the Mission Control dashboard (throughput, latency, capacity, live runs, workers and system), the scheduler’s limits with Edit (ADMIN), and the remote workers with their pools and use. Activity is a live feed of events from all runs. Audit lists the newest control commands with the time, actor, command, run, and whether each was applied or refused and why. Commands sent without a named key show as api. From a workflow page, Control commands of this run in the Workflow actions menu opens the audit for that run. See Use the control dashboard for what to read there, and Tune capacity and limits for the scheduler.

Verify it worked

Open the UI, create a session with New session, Run its main workflow, and confirm that the graph turns green and the logs panel shows lines. Reload the page and check that the run is still selected from the address (?exec=).

Variations that matter

  • A phone or narrow window. The rail becomes a tab bar and tables stack their cells.
  • A server behind a proxy. The UI is the same server: the proxy must pass event streams unbuffered, or the graph and logs stop updating. See Deploy Yukta.
  • The page asks for a key every time. The key is kept for the tab only. Open Change API key in the account menu to replace it.