01 · Orchestration

Winskel decides.
Until you want to.

Winskel supports three orchestration modes: Autopilot, Preferences and Custom. Autopilot is the default.

How do I orchestrate Claude Code and Codex?

Give Winskel one objective. In Autopilot it decides whether the work stays with one model or splits into missions, which eligible model runs each part, what runs at the same time, and when to add an independent review. Preferences constrain those decisions; Custom defines them. Both apply to your account or to one project.

ORCHESTRATION.MODESettings

Autopilot: Winskel decides
Preferences: Your boundaries, Winskel decides
Custom: Your workflow

Mode 1

Autopilot

Winskel decides. You give it the objective and nothing else.

Keep it together: Most objectives go to one strong model that investigates, changes, tests and repairs its own work, because every handoff loses context.
Split into missions: Winskel plans the work when you ask, when you name an agent system for part of it, or when it is high risk or very large. The plan may still keep it with one owner, and small parts are merged back.
Pick the model: From the models your Claude Code and Codex can run. By default Claude CodeSonnet 5.5, Claude CodeOpus 5.5 or CodexGPT-5.6 Sol.
Run at the same time: Independent missions start together, each in its own Git worktree. Missions with unmet dependencies wait.
Add a review: An independent review for high-risk work in security, migrations, infrastructure or architecture, and whenever you ask.
Recover: If checks fail, the same model gets one repair turn. If they still fail, the step moves once to a stronger model. If that also fails, the objective stops as Failed and shows the reason.

A settings form fix kept with one model. Winskel says the validation, the button state, and the test all touch the same form, so one owner can change it, run the tests, and fix what fails without a handoff. One Claude Code Sonnet 5.5 mission is running. — Autopilot keeps a settings form fix with one model: the validation, the button and the test touch one form.

You can still name a model

Write "Use Opus 5.5" or "Use Codex for the tests" in an objective and Winskel uses it, in every mode. If what you named cannot run, Winskel stops and says why instead of swapping in another model.

Mode 2

Preferences

You set the boundaries. Winskel still decides.

Preferences constrain automatic orchestration rather than replacing it. Winskel still plans, splits and routes the work, and ranks models inside your rules.

Model roles

Choose the implementation model and the reviewer model.

Models per kind of work

Set a model for any of 15 kinds of work, such as frontend changes, backend work, testing, migrations, documentation and debugging.

Model pool

Allow models, exclude models, or exclude an agent system. The pool applies in every mode, and a project can allow an excluded model back. Models to avoid are a preference that lowers their rank.

Priority and continuity

Prefer balance, quality, speed or cost. Keep follow-up work on the same model, prefer an independent one, or let Winskel decide.

Preferences rank models. They never bring back a model you excluded.

PREFERENCES.RULESexample

Implementation: Codex · GPT-5.6 Sol
Reviewer: Claude Code · Opus 5.5
Backend work: Codex · GPT-5.6 Sol
Frontend change: Claude Code · Sonnet 5.5
Avoid: Fable 5
Priority: Quality
Continuity: Winskel decides

Mode 3

Custom orchestration

You define the workflow. Winskel runs it the same way every time.

A Custom workflow belongs to your account or to one project. A project workflow replaces the account workflow as a whole.

Roles

An implementer and a reviewer, each set to a model or an agent system. If a role cannot run, Winskel asks you (the default) or chooses for you, as you set.

Planning

Winskel plans with Claude Code. Custom can make planning always run, even for a small objective.

Reviews

Review automatically or always. Let the reviewer come from either agent system, or require the other one.

Failures

After a failed review, add a fix step or ask you. After failed checks, retry then escalate, retry the same model, or ask you. Choose the model to escalate to.

Human gates

Ask before a plan starts. Ask before any escalation.

CUSTOM.WORKFLOWexample

01PlanClaude Code · always
02ImplementCodex · GPT-5.6 Sol
03ReviewClaude Code · the other agent system
04Review failsa fix step, run by the implementer
05Checks failretry, then GPT-6 Astra · ask first

In parallel

The same workflow holds when an objective splits. Independent missions each run on the implementer in their own worktree. With review set to always, Winskel reviews each change or reviews them all together.

Import a workflow

Upload a .yaml, .json, .md or .txt file of up to 16 KB in Settings. A structured file becomes these exact fields; any key Winskel does not know is refused. Markdown or text of up to 4,000 characters becomes planning guidance, never a routing rule.

WORKFLOW.YAMLthe shape Winskel imports

version: 1
planning: always
roles:
  implementer:
    model: gpt-5.6-sol
    ifUnavailable: ask_me
  reviewer:
    harness: claude_code
    ifUnavailable: winskel_choose
review:
  mode: always
  independence: other_harness
failure:
  failedReview: add_fix_step
  failedChecks: retry_then_escalate
  escalateTo: gpt-6-astra
human:
  beforeStart: false
  beforeEscalation: true

What Custom does not set

Winskel plans the steps and their dependencies for each objective. How many missions run at once depends on your Mac. There is no setting for a number of repair rounds.

Read the guide to choosing models

Winskel decides.Until you want to.