# Choosing models > Winskel decides by default. Preferences set the boundaries, and Custom sets model roles, review rules, and approval requirements. - Canonical page: https://www.winskel.com/docs/choosing-models - Applies to: Winskel public download 0.7.0-alpha.1 (alpha channel), Apple Silicon, macOS 12 or later - Content updated: 2026-10-06 - Agent reference: https://www.winskel.com/agents.md ## Three levels of control - Autopilot: you give the objective and Winskel makes the orchestration decisions. - Preferences: Winskel still decides inside boundaries you set. - Custom orchestration: you set the implementation, review, and approval rules Winskel follows. ## Autopilot, the default If you give Winskel an objective and no model, agent system, or other orchestration instruction, Autopilot applies. Winskel decides whether to keep the work together or split it, what can run at the same time, what has to wait, which model owns each part, and when to add an independent review, only among the models your accounts can run. Usually one strong model owns the whole objective. See [model routing](https://www.winskel.com/docs/model-routing). You do not need to configure anything. ## Name a model Write the model's name, such as Opus 5.5 or GPT-5.6 Sol, in the objective. Winskel uses it instead of choosing. Nicknames are not guessed. - If the objective stays one task, that task runs on the named model - If you name more than one model, Winskel plans the work, gives each model the part it fits, and stops if it cannot tell which part you meant - If your account cannot run the named model, Winskel stops and explains instead of swapping in another ## Name an agent system Write "Use Codex" or "Use Claude Code", for the whole objective or for one part, such as "Use Codex for the tests". That part runs on the system you named, and a retry stays on it. Winskel recognizes the names Claude Code and Codex; "Claude" alone is not read as a choice. - If the named system is not available on your Mac, nothing starts and Winskel says why - If you also name a model from the other system, Winskel asks you to choose one - In a split where only one part names a system, only that part is held to it ## Default model During first-run setup you choose a default model. Winskel uses it only when none of its default strong models can run on your Mac. It cannot be changed in Settings yet. ## Explicit constraints always win Automatic routing, retries, and escalation never replace a model or agent system you named. If what you named cannot run, nothing starts. Settings, Models shows the models Winskel knows as a read-only list. ## Preferences - Allowed model pools, and models to never use. An excluded model never runs. - Preferred models by kind of work, and a preferred implementer and reviewer - Models to avoid, which lowers their rank - A quality, speed, cost, or balanced priority, and whether follow-up work stays on the same model - An account default that each project can inherit or override ## Custom orchestration You define the workflow for your account or one project: an implementer and a reviewer (each a model or an agent system), whether planning and review always run, whether the reviewer must use the other agent system, what happens after a failed review or failed checks, the model to escalate to, and whether Winskel asks before a plan starts or before escalating. Winskel plans with Claude Code and plans the steps and their dependencies for each objective. You can import a workflow file; free text becomes planning guidance, never a routing rule. See [orchestration](https://www.winskel.com/product/orchestration). Every model in a workflow must be one your plan can route to, and a role whose model cannot run either asks you or lets Winskel choose inside your limits, as you set it.