> For the index of every page in Orbital's docs, read https://docs.beta.runorbital.dev/llms.txt.

# Styles and personas

> Named sets of turn settings that cascade from the workflow to each step

A style is a named set of settings for an agent's turn: which harness runs it, which model it uses, how hard it thinks, which persona it speaks as and how the harness approves its actions. A persona is a named prompt that the agent receives with the step's own prompt. A style picks a persona with its `persona` key.

Styles cascade like CSS. The workflow sets a base style for every step, a group adds its own for the steps inside it, a step names its own, and a key set on the step itself beats them all. Each setting is decided on its own, so a step that changes only its effort keeps the model it would have had.

```toml
[styles.careful_review]
extends = "reviewer"
effort = "max"
codex.sandbox_mode = "read-only"
```

The same name means the same thing on every step that uses it. Change the style called `reviewer`, and every step that uses it changes.

## What a style holds

| Key | What it sets |
| --- | --- |
| `extends` | One style this one starts from. |
| `harness` | The harness that runs the turn: `claude`, `codex`, `opencode` or `pi`. |
| `model` | The model the harness uses. |
| `effort` | How hard the model thinks: `minimal`, `low`, `medium`, `high`, `xhigh`, `max` or `ultra`. Each harness accepts only some of them. |
| `connection` | The connection the harness routes the turn through. |
| `provider` | The model provider. OpenCode only. |
| `persona` | A persona name from **Settings > Personas**. `""` means no persona. |
| `permissions` | How the harness approves the agent's actions: `auto-accept`, the default, or `full`. See [permissions](#permissions). |

A style can also hold a sub-table for each harness: `claude.model`, `claude.effort` and `claude.setting_sources`; `codex.model`, `codex.effort`, `codex.sandbox_mode` and `codex.approval_policy`; `opencode.model`, `opencode.connection` and `opencode.provider`; `pi.model` and `pi.effort`. A plugin harness reads a sub-table of its own name. A sub-table applies only when that harness runs the step, and there it beats the plain key it sits beside. So a style can say `effort = "high"` for every harness and `codex.effort = "medium"` for Codex alone.

An agent step takes the same keys, except `extends`, directly. [Style keys](/reference/workflow-file/#style-keys) and [harness-specific keys](/reference/workflow-file/#harness-specific-keys) give every value.

## How styles cascade

Orbital decides each setting of a step from the first of these that sets it:

1. the step's own keys
2. the step's `style`
3. the styles of the groups that hold the step, the innermost group first
4. the model picked when the run started, if one was
5. the workflow's top-level `style`
6. the run's preset: the preset the run was started with, or else the preset in use
7. the defaults in **Settings > Harnesses**

```toml
style = "balanced"

[steps.coder]
style = ["implementer", "codex"]

[steps.coder.check]
effort = "low"
prompt = "Run the project's checks and fix what they find."
```

Here `coder.check` takes its effort from its own key, `low`. Its persona comes from `implementer` and its harness and model from `codex`, both through the `coder` group. The workflow's `balanced` style sets only effort, which the step already has, so it decides nothing here. An import step counts as a group for the steps it brings in, so its `style` reaches every imported step that does not choose for itself.

[How a step's settings resolve](/reference/workflow-file/#how-a-steps-settings-resolve) gives the exact order.

## Lists of styles

`style` takes one name or a list. In a list, later names win, key by key:

```toml
[steps.review]
style = ["careful_review", "thorough"]
```

`thorough` sets `effort = "high"`, so the step thinks at `high` even though `careful_review` says `max`. It still takes the persona and the Codex sandbox from `careful_review`, because `thorough` leaves them alone.

## Extend a style

`extends` names one style to start from. The new style keeps every key of the one it extends and replaces the keys it sets itself. `careful_review` above is the shipped `reviewer` with more effort and a read-only sandbox on Codex. A style may extend a style from the app, from a style file or from the same workflow.

## Style files

A style file is a TOML file with `version = 3` and only `[styles.*]` tables. A workflow pulls style files in with `use`, a list of paths relative to the workflow file:

```toml
version = 3
entry = "steps.plan"
use = ["shared/team.toml"]
```

Several workflows can `use` the same file, so a team keeps its styles in one place.

Orbital builds the styles a workflow can name from four sources. A later source wins, key by key, when two define the same name:

1. the style files in `use`, in list order
2. the styles of workflows this file imports as steps
3. the workflow's own `[styles]`
4. the presets in **Settings > Presets**

[Style files](/reference/workflow-file/#style-files) and [how styles merge](/reference/workflow-file/#how-styles-merge) give the details.

## Presets: styles saved in Orbital

**Settings > Presets** holds presets: styles saved in Orbital, which every workflow can name without defining them. A step names a preset with `style`, just as it names a style its workflow defines. A preset wins over a file style of the same name on every key the app sets. So you can change the shipped `reviewer` in Settings and every workflow that names it follows.

To change a shipped preset for one workflow only, extend it under a new name in that workflow, as `careful_review` does, rather than redefining `reviewer` in the file. Your Settings would win over the file's copy.

## The run's preset

Every run also has a preset of its own, below everything the workflow sets. **Settings > Presets** marks one preset as in use. A run started without a preset follows the preset in use, and when you switch the preset in use, those runs move to it at their next turn. Pick a preset on the Start page, or pass `style` to `start_run`, to pin a run to that style instead: a later switch does not move it.

The run's preset fills in what the workflow leaves open. On a fresh install the shipped `claude` preset is in use, so every step that names no harness runs on Claude Code. Switch the preset in use to `codex`, and those steps move to Codex at their next turn. A step whose own styles name a harness stays where it is.

When the harness of the preset in use runs out of quota, a banner on **Settings > Presets** offers to switch the preset in use. Orbital never switches it by itself.

## Change, reset and restore styles

Orbital adds the shipped presets on every start and never overwrites one you edited. **Reset to default** returns an edited shipped preset to Orbital's version. Deleting a shipped preset hides it until you choose **Restore**. [Settings](/reference/settings/#presets) describes the page.

## Personas

A persona says who the agent is. It is a named prompt, such as "You review work you did not write", that the agent receives along with the step's own prompt. Personas live in **Settings > Personas**. A style or a step names one with `persona`, and `persona = ""` gives a step no persona even when a style below it names one.

## What ships

Orbital ships these presets. Apart from `claude` and `codex`, none names a harness or a model, so each runs on whichever harness the run's preset gives it.

| Style | Settings |
| --- | --- |
| `balanced` | `effort = "medium"` |
| `deep_thinking` | `effort = "high"` |
| `planner` | `persona = "planner"`, `effort = "high"` |
| `implementer` | `persona = "implementer"`, `effort = "medium"` |
| `reviewer` | `persona = "strict_reviewer"`, `effort = "high"` |
| `researcher` | `persona = "researcher"`, `effort = "medium"` |
| `claude` | `harness = "claude"`. In use on a fresh install. |
| `codex` | `harness = "codex"` |

It also ships these personas:

| Persona | Who the agent is |
| --- | --- |
| `planner` | Plans the change before code is touched. |
| `implementer` | Makes the planned change and checks it. |
| `strict_reviewer` | Reviews others' work and reports defects. |
| `researcher` | Finds things out and cites its sources. |
| `supervisor` | Looks after your runs. [The Supervisor](/supervisor/) speaks as it, on the preset in use. |

[Shipped presets](/reference/workflow-file/#shipped-presets) gives each persona's prompt.

## Permissions

`permissions` decides whether the harness asks before the agent acts. It does not take tools away: a step can use every tool its harness offers. The default is `auto-accept`. When a harness asks you something, the run shows as Question until you answer. See [standings](/runs/#standings).

To set permissions for a whole workflow, put them in a style and name it in the workflow's top-level `style`.

:::caution[A prompt is not a limit]
A prompt that says "do not change files" is a request, and the agent can ignore it. On Codex, `codex.sandbox_mode = "read-only"` in a style keeps the step from writing.
:::

### Claude Code

| Setting | What happens |
| --- | --- |
| `auto-accept` | Claude Code's auto mode approves what it judges safe. Whatever auto mode does not settle, the run asks you as a Question. |
| `full` | Claude Code bypasses its permission checks. Nothing is asked. |

### Codex

| Setting | What happens |
| --- | --- |
| `auto-accept` | Codex defaults to `workspace-write` and `on-request`: it can change files in the workspace and run sandboxed commands, and decides when to ask for approval to act outside the sandbox. Each approval request appears as a Question for you to approve or decline. Set `codex.sandbox_mode` and `codex.approval_policy` to override these defaults. |
| `full` | Codex runs with full access and never asks, whatever `codex.sandbox_mode` and `codex.approval_policy` say. |

[Harness-specific keys](/reference/workflow-file/#harness-specific-keys) lists the sandbox modes and approval policies.

### OpenCode

| Setting | What happens |
| --- | --- |
| `auto-accept` | Every permission OpenCode raises is asked as a Question. Your OpenCode permission settings decide what it raises. |
| `full` | Every permission is approved. Nothing is asked. |

### Shipped workflows

Of the shipped workflows, `pursue-goal` and `port-project` use `full`. The others use `auto-accept`.

## Quick reference

| To decide | Where to set it |
| --- | --- |
| Settings for every step | `style` at the top level |
| Settings for every step in a group | `style` on the group |
| Settings for one step | `style` on the step, or the key itself on the step |
| Who the agent is | `persona` |
| Harness, model and effort | `harness`, `model`, `effort` |
| A setting for one harness only | `claude.*`, `codex.*`, `opencode.*` or `pi.*` |
| Whether the harness asks before it acts | `permissions` |
| Styles shared between workflows | `use` with a style file |
| Settings for every run that picks no preset | The preset in use, in **Settings > Presets** |

## Related

- [Give steps a style](/styles/configure-steps/): a worked example.
- [Use different models in one workflow](/harnesses/use-different-models/): styles on several harnesses.
- [Workflow file](/reference/workflow-file/#styles): every style key and the exact resolution order.
- [Settings](/reference/settings/#presets): the Presets and Personas pages.