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

# Use different models

> Run different steps on different harnesses, models and efforts

Run cheap steps on a small model and expensive steps on a large one by giving each step its own style. Define the styles in the workflow, or use the ones in **Settings > Presets**, then name one per step:

```toml
[styles.codex_review]
harness = "codex"
model = "gpt-6-sol"
effort = "high"

[steps.implement]
style = "balanced"
prompt = "Implement this goal: {{ inputs.goal }}"
next = "steps.review"

[steps.review]
style = "codex_review"
prompt = "Review the change. Report what you find. Do not change files."
next = "steps.done"
```

`balanced` ships with Orbital and names no harness, so `implement` runs on the harness of the run's preset. `review` always runs on Codex. [Styles and personas](/styles/) defines styles, and [Give steps a style](/styles/configure-steps/) walks through a complete example.

Orbital works out the harness, model, effort, connection and provider separately for every step. So a step that changes only its effort keeps the model it would have had.

## Before you start

- Sign in to each harness you want to use. Follow [Install Orbital](/get-started/install/#2-install-and-sign-in-to-a-harness) before you try a model.

## Name models in styles

A style names a model with `harness` and `model`, and how hard it thinks with `effort`. Put styles in the workflow, in a style file that several workflows `use`, or in **Settings > Presets**, where every workflow can name them. A style in Settings wins over a file style of the same name.

The harness names are claude, codex, opencode and pi. Effort accepts minimal, low, medium, high, xhigh, max and ultra, but each harness accepts only some of them. Orbital refuses a harness and effort that do not go together before any turn starts, so a run does not fail halfway through.

## Pick a preset for the run

**Settings > Presets** marks one preset as in use. On a fresh install it is the shipped `claude`; Orbital also ships `codex`. A run started without a preset follows the preset in use: switching the preset in use moves the run at its next turn. Choose another style in the Start page's preset picker, or pass `style` to `start_run`, to pin the run to it. A later switch of the preset in use then does not move the run. The run's preset comes after everything the workflow sets, so a step's own keys and styles, its groups' styles and the workflow's `style` still come first. [Which harness a step uses](/harnesses/#which-harness-a-step-uses) explains which steps follow it.

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

To start a run on a harness by name, use `--harness` with `orbital run start`, or `harness` and `model` in `start_run` or the API. A harness named this way removes `harness`, `model`, `effort`, `connection` and `provider` from every layer, so every step runs on it, as when you [switch a run's harness](/harnesses/switch-harness/). Harness sub-tables, personas and permissions stay. A model named this way becomes the run's model on its harness: a sub-table model on the step, in its styles or in its groups' styles still wins over it, and the workflow's own `style` does not. [Models and prices](/reference/models/) lists every suggested model and its price, and explains how Orbital estimates a run's cost.

## Resolution order

Orbital decides each setting on its own, from the first of these that sets it:

1. the step's own keys
2. the step's `style`, where later names in a list win
3. the styles of the groups that hold the step, the innermost first; an import step is a group for the steps it brings in
4. the workflow's top-level `style`
5. the run's preset: the one it was started with, or else the preset in use
6. the defaults in **Settings > Harnesses**

A key in a harness sub-table, such as `codex.model`, applies only when that harness runs the step, and there it beats the plain `model` beside it. [Workflow file](/reference/workflow-file/#how-a-steps-settings-resolve) gives the exact order.

Sub-table keys such as `claude.model`, `codex.effort` and `opencode.provider` work in styles and on agent steps. Orbital checks their names and values even when the step runs on another harness. So a typo shows up when you validate the workflow, not on the turn that needs it. [Harness-specific keys](/reference/workflow-file/#harness-specific-keys) lists them all.

An imported workflow's styles join the styles of the workflow that imports it, and the importer's own styles of the same name win. The import step's `style` reaches every step it brings in. See [Reuse a workflow](/workflows/reuse-a-workflow/).

:::note
Permissions default to auto-accept. Each harness treats `permissions` differently. Neither permissions nor the prompt limits what a step can do. [Permissions](/styles/#permissions) explains them.
:::

## See which model a run used

The run page names the harness and the model the latest turn reported. They appear in the footer under the composer, beside the workflow, the branch and the pull request. Where the composer is not on screen, such as on an ended run, the header names them instead.

Before a turn reports a model, the page shows the model the turn asked for, marked "(configured)", or "Model not known yet". A run that used several models shows the latest with a count of the others. The transcript records the settings each turn ran with. It is the fastest way to check that your settings did what you meant.

The **Tokens by model** table on the run's **Cost** tab lists each model the run used. A step whose spend ran on several models, such as Claude's main model with its auxiliary Haiku calls, names every one, and **Tokens by model** splits the step's spend between them.

A cost marked ≥ is the part Orbital could price, and a note under the table says what is missing:

- Claude reports no usage for the helper calls it makes outside its query pipeline, such as the permission classifier and token-count probes. Its SDK leaves them out of every report it gives, so no Claude step's cost is complete.
- Claude reports sub-agent and auxiliary spend only as running totals for its session. Orbital records those totals with the run, so a session the run resumes, after a restart or in a paused conversation, counts on from them. When it cannot tell what the totals counted from, such as after they reset or after a model call was cut off mid-reply, it records the main loop's own calls and leaves the rest out rather than count spend twice.

![A run's Cost tab shows tokens and cost for each step and a Tokens by model table.](/screenshots/run-billing.webp?v=01a803de81)

*Tokens by model lists every model the run used.*

## Change harness during a run

You can move a stopped run to another harness and retry its step there. [Switch a run's harness](/harnesses/switch-harness/) describes how, what carries over, and what the quota fallback does.

## Related

- [Give steps a style](/styles/configure-steps/): a worked example with step, group and workflow styles
- [Styles and personas](/styles/): what a style holds and what ships
- [Harnesses and models](/harnesses/): which harness a step uses
- [Switch a run's harness](/harnesses/switch-harness/): move a stopped run to another harness
- [Models and prices](/reference/models/): suggested models and how cost is estimated
- [Workflow file](/reference/workflow-file/#how-a-steps-settings-resolve): the exact resolution order