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

# Execution Engines

> Understand what changes and what stays the same when an agent step runs on the Overcut engine or the Claude engine, and how to pick one per step.

Every agent step in a workflow runs inside the same sandbox with the same repository checkout. The **Execution Engine** decides what drives the agent inside that sandbox: which runtime sends prompts to the model, executes tool calls, and decides when the task is done.

Overcut ships two engines. **Overcut** is the default and runs Overcut's own agent runtime. **Claude** runs Anthropic's Claude Agent SDK, the same runtime behind Claude Code. The agent definition is the same on both. What differs is the model providers you can use, the file and shell tools the agent works with, how sub-agents are delegated, and how usage is reported.

<Note>
  **Engine or harness?** The industry term for this layer is the **agent harness**: everything in an agent except the model, summarized as "Agent = Model + Harness". Anthropic describes the Claude Agent SDK as "a general-purpose agent harness", and you will see the same word in vendor comparisons and engineering blogs. Overcut's Workflow Builder labels the same choice **Execution Engine**, and this page uses "engine" to match the product. When someone says Overcut runs agents on "the Claude harness" or "Overcut's own harness", they mean the Claude and Overcut engines described here.

  Overcut also uses "harness" in a second, wider sense: a project's [agent harness](/docs/concepts/multi-project-workspaces) is the set of repositories, Skills, MCP servers, agents, and secrets an agent can reach. These are two layers of the same idea. The project defines what the agent can see and call, and the engine defines the loop that drives it.
</Note>

## Why engines are chosen per step

The engine is a property of a step, not of a workflow, an agent, or a workspace. Both the [Agent Run](/docs/workflows/agent-run) and [Multi-Agent Session](/docs/workflows/agent-session) actions expose it in the Workflow Builder under **Agent → Execution Engine**. Leaving it unset means **Overcut**.

Choosing per step lets one workflow mix engines. A triage step can run on an OpenAI model through the Overcut engine while the implementation step that follows runs on the Claude engine. The workflow catalog and the run details view show an engine logo on each step, so you can see which engine a step used without opening its configuration. See [Agent Engine Indicators](/docs/workflows/workflows#agent-engine-indicators).

## What stays the same

An agent definition does not depend on the engine. You can switch a step between **Overcut** and **Claude** without changing the agent, and everything in this list carries over:

* **Agent definition and instructions**: the role, persona, and step instructions.
* **Sub-agents**: the agents a coordinator can delegate to.
* **Skills**: assigned [Skills](/docs/reference/skills) load on both engines.
* **MCP servers**: assigned [MCP Servers](/docs/reference/mcp-servers) and their allowed-tool lists.
* **Agent memory**, **project secrets**, and **context parameters**.
* **Repository checkout**: the same cloned repositories in the same sandbox.
* **Run logs and streaming**: messages, tool calls, and thread views in run details look the same.
* **Overcut integration tools**: tickets, pull requests, code review, CI, memory, scratchpad, orchestration, and semantic code search all behave the same. On the Claude engine they reach the agent through an MCP server that Overcut runs inside the sandbox, but the tool set is the same.

### Repository instruction files are not loaded on either engine

Files such as `CLAUDE.md`, `AGENTS.md`, `.claude/settings.json`, `.claude/skills/`, and `.cursor/rules` are present in the checkout, and an agent can read them like any other file. Neither engine puts them in context on its own. This is also true on the Claude engine, which runs with the SDK's isolation defaults rather than loading project settings the way Claude Code does on a developer's machine.

This is deliberate. Repository instruction files are written for interactive coding with a person in the loop, and an agent that silently inherited them would behave differently per repository with no visible cause. To apply conventions consistently, put them in the agent's instructions or in a Skill. Both work identically on both engines. To use a file that already lives in the repository, tell the agent to read it in the step instructions, for example "read `CLAUDE.md` before making changes".

## What differs

| Dimension            | Overcut engine                                                          | Claude engine                                                                                                       |
| -------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Model providers      | OpenAI, Azure OpenAI, Anthropic, AWS Bedrock, OpenRouter                | Anthropic, AWS Bedrock, or any Anthropic-compatible gateway such as LiteLLM                                         |
| Credentials          | Your own custom models, or Overcut's system models                      | A custom Anthropic or AWS Bedrock model in your workspace. No system-model fallback                                 |
| Custom LLM gateway   | Any provider, with base URL, credential, auth method, and extra headers | Gateways that serve the Anthropic `/v1/messages` API, through the Anthropic model's **Base URL**, with API-key auth |
| File and shell tools | Overcut tools such as `read_file`, `edit_file`, and `run_terminal_cmd`  | Claude Code's native tools such as `Read`, `Edit`, `Bash`, and `Grep`                                               |
| Sub-agent models     | Each sub-agent uses its own model and credentials                       | One provider and one set of credentials per session; a pinned sub-agent model changes only the model name           |
| Usage reporting      | One record per LLM call                                                 | One record per model per session result                                                                             |

### Models and credentials

The Overcut engine accepts every provider on the [LLM Models](/docs/reference/llm-models) page, including Overcut's system models, so a step can run with no credentials of your own.

The Claude engine speaks the Anthropic wire format, so it accepts Anthropic and AWS Bedrock models, plus any gateway that exposes the Anthropic `/v1/messages` API. LiteLLM, Portkey, and similar proxies qualify: create an **Anthropic** model, set its **Base URL** to the gateway, and authenticate with an API key. The gateway can route to whatever model it serves behind that endpoint. OpenAI, Azure OpenAI, and OpenRouter models cannot serve the Claude engine because they use a different wire format, and this is not a roadmap gap. The model must be an active custom model in your workspace. If the step resolves to a system model, a deactivated model, or a model on another provider, the step fails before it starts with an error naming the model and the cause. A failure on either engine fails the step. Neither engine falls back to the other.

The two engines resolve the step's model through different cascades. The Claude engine has its own workspace default, **Default Claude Engine Model**, and does not fall back to a system model. See [Model Cascade](/docs/reference/llm-models#model-cascade) for both orders and [Claude Agent SDK Integration](/docs/integrations/claude-agent-sdk) for setup.

### Tools

Both engines give the agent the same Overcut integration tools. The difference is in file and shell access.

On the Overcut engine, the agent uses the file system and code utility tools documented in the [Agent Tools Reference](/docs/reference/tools). On the Claude engine, those are replaced by Claude Code's built-in tools, and run logs show their names (`Read`, `Write`, `Edit`, `Bash`, `Grep`) instead of the Overcut names. The Overcut integration tools keep their names on both engines.

<Note>
  On the Claude engine, the coordinator's configured tool list restricts Overcut integration tools but not Claude's built-in file and shell tools. Removing `run_terminal_cmd` from an agent does not prevent the coordinator from running shell commands on the Claude engine. Sub-agents on the Claude engine do respect their tool lists. If a step must be read-only or must not run commands, run it on the Overcut engine.
</Note>

### Sub-agents

Delegation works the same way on both engines. The coordinator decides when to hand work to a sub-agent based on the sub-agent's description, can delegate several independent tasks in one turn, and run details show each delegation as its own thread. What differs is which model and credentials each sub-agent runs on.

On the Overcut engine, each sub-agent runs with its own model configuration, including its own provider and credentials.

On the Claude engine, one session uses one provider and one set of credentials, taken from the coordinator's resolved model. Pinning a model on a sub-agent changes which model answers, and nothing else: the API key, region, gateway, and billing stay the coordinator's. A sub-agent pinned to a model on a different provider than the coordinator fails the step at dispatch. Pin it to a same-provider model, or leave it on the default.

<Warning>
  On AWS Bedrock, a pinned sub-agent's inference profile must exist in the coordinator model's region and account. A mismatch surfaces as an AWS error during the run, not when you save the workflow.
</Warning>

### Usage reporting

Both engines report to the same [Token Usage Analytics](/docs/workflows/token-usage-analytics) views and the same billing records. The grain differs:

* The Overcut engine records one row per LLM call, so **LLM Calls** counts API requests.
* The Claude engine records one row per model per session result. **LLM Calls** counts results, which is lower than the number of API requests for the same work. Retries and follow-up messages in a session each produce their own result.
* On the Claude engine, usage is attributed to a sub-agent only when that sub-agent is pinned to a model no other agent in the step uses. Sub-agents on the default model are counted under the coordinator.
* Every call a Claude-engine step makes, including the SDK's own background calls, runs on the model you configured. You will not see a model you never set up in your usage or your provider bill.
* Claude-engine usage is reported for visibility. Spend is billed by Anthropic or AWS on your own account, and Overcut does not charge credits for it.

## Choosing an engine

Use the **Overcut** engine when the step:

* Needs a model from OpenAI, Azure OpenAI, or OpenRouter, or a gateway that only speaks the OpenAI format.
* Should run on Overcut's system models without your own provider credentials.
* Must enforce a restricted tool list on the coordinator, for example a read-only review step.
* Needs per-call usage records for cost analysis.
* Needs sub-agents on different providers or with separate credentials.

Use the **Claude** engine when the step:

* Benefits from Claude Code's native coding behavior and built-in file and shell tools.
* Runs on an Anthropic or AWS Bedrock model you already pay for.

Mixed workflows are common: planning and review steps on the Overcut engine, implementation steps on the Claude engine. Because the agent definition is engine-independent, you can try a step on the other engine by changing one field and re-running.

## Related

* [Claude Agent SDK Integration](/docs/integrations/claude-agent-sdk): set up a Claude-compatible model and select the Claude engine.
* [LLM Models](/docs/reference/llm-models): providers, credentials, and the model cascade for each engine.
* [Agent Tools Reference](/docs/reference/tools): the Overcut tool set.
* [Token Usage Analytics](/docs/workflows/token-usage-analytics): where usage from both engines appears.
* [Agent Run vs Multi-Agent Session](/docs/workflows/agent-differences): choosing the step type before choosing the engine.