How to Use Different Models for Plan and Act Mode in Cline

Yes: turn on Cline’s separate Plan/Act model setting, assign one model to investigate and write the implementation contract, and another to make edits and run tests. The payoff isn’t a magic quality multiplier; it’s stopping yourself from paying for maximum deliberation while an agent spends ten turns fixing lint errors.

Set it up once, then let the mode switch do the boring part

In Cline Settings, enable “Use different models for Plan and Act.” Pick the model you want for Plan mode, switch to Act mode, and pick the execution model there. From then on, changing modes automatically restores the matching model selection. Cline carries the same conversation forward, so the Act model gets the repo findings, constraints, and agreed plan rather than a cold handoff.

This is worth doing even if you use the same provider for both modes. The important distinction is not vendor loyalty; it’s what you need the model to do. Plan mode can read the codebase, search, and discuss an approach, but it cannot modify files or execute commands. Act mode gets the editing and command-running tools. That difference should drive model choice.

Choose the Plan model for investigation, not for eloquence

Your Plan model needs to survive ambiguity. Give it work where a wrong assumption spreads into several files: tracing an authorization path, finding the real owner of a configuration value, or deciding whether a migration belongs in a background job or a request path.

A stronger reasoning model is often useful here, but only if you make it produce an artifact you can inspect. Don’t ask, “How should we add audit logs?” Ask for scope, evidence, and acceptance criteria. For example:

Explore this repository without editing anything. We need audit events for API-key creation and revocation.

Return:
1. the current request path and files involved;
2. the event schema and storage pattern already used here;
3. every test that should change or be added;
4. a numbered implementation plan;
5. assumptions or decisions that need my approval.

Do not propose new infrastructure if an existing event pipeline can carry this.

That prompt makes Plan mode useful because it leaves you with things to check: file paths, existing patterns, and a finite list of tests. If it comes back with “add an audit service” but cannot identify where other events are emitted, stay in Plan mode and ask it to search again. Switching to Act does not fix a vague plan; it merely gives a model permission to implement one.

Choose the Act model for tool use and tight feedback loops

The Act model’s job is less glamorous: make a small coherent diff, run the relevant command, interpret the failure, and repair the change without quietly widening scope. A model that writes attractive code but produces malformed tool calls, ignores command output, or keeps replacing whole files is a bad Act model regardless of how impressive it was in a chat benchmark.

Start with an Act model you have already seen complete routine repository work: targeted edits, test failures, formatter noise, and dependency-specific error messages. Keep the first implementation bounded. In the audit-event example, tell it to implement only the approved plan and run the narrowest useful check, such as pnpm test --filter audit-events, before reaching for the full suite.

This setup also gives you a practical cost control: use the expensive or slower model when the agent is mapping an unfamiliar system, then use the quicker model during the repetitive edit-test-fix loop. Don’t treat that as a reason to put a weak model in Act mode. The execution phase is where weak tool use can turn a five-file task into a cleanup review you never asked for.

Use a handoff that the second model can actually execute

After you approve the plan, switch to Act mode and give one short confirmation with explicit boundaries. Cline’s current Plan/Act flow preserves prior context, but an explicit execution instruction prevents the new model from treating a planning discussion as an invitation to reopen every design decision.

Implement the approved plan now.

Constraints:
- Touch only the API-key service, the existing audit-event writer, and their tests.
- Preserve the existing event naming convention.
- Run `pnpm test --filter audit-events` and the formatter.
- Stop and return to Plan mode if the event pipeline needs a schema migration or a new queue.
- Show the diff summary and test output before calling this complete.

The last two lines matter. They turn “finish the task” into visible stopping conditions. If Act discovers that the existing event pipeline cannot accept the new payload, that is a design change—not something to bury in a late-night migration file. Switch back to Plan mode, decide it there, then switch back.

Use /deep-planning when the plan is the deliverable

For a migration, an authentication change, or anything crossing frontend, backend, and deployment code, use Cline’s /deep-planning command before you select Act. It is designed to systematically explore the repository, identify affected dependencies, create a detailed plan, and ask clarifying questions. The goal is not a longer answer. The goal is to avoid discovering halfway through implementation that the planned change requires an API-version decision, a data backfill, or a compatibility window.

For a typo, an import, a one-line config adjustment, or a well-understood local refactor, skip it. Go directly to Act mode. Planning a two-minute edit is still overhead, and Cline’s own guidance treats small, obvious changes as Act-only work.

What this split is bad at

Two models do not create a review system. The Act model is still operating on the Plan model’s assumptions, and both can miss the same repository convention. You still need to read the diff, especially around authorization, data deletion, dependency upgrades, and generated files.

It also does not help when the task is poorly bounded. “Modernize our API layer” will make a thoughtful Plan model generate a large menu of options and make an eager Act model touch too much code. Narrow the requested outcome first: one endpoint family, one compatibility behavior, one measurable test target.

Finally, pin the models you intend to use rather than relying on a provider default. Cline’s model catalog and provider defaults change over time; its changelog explicitly notes default-model changes across providers. If a previously dependable Plan or Act behavior changes after an update, verify the selected model in each mode before assuming your prompt or repository is the problem.

A default pairing that’s easy to operate

1. Plan: use the more capable model you trust to inspect unfamiliar code, enumerate affected files, surface tradeoffs, and write acceptance criteria.
2. Act: use the fastest model that has already proven it can edit precisely, run commands correctly, and respond well to test output in your stack.
3. For medium work: Plan, approve a numbered plan, switch to Act, run focused tests, and return to Plan only when a new design decision appears.
4. For large work: start with /deep-planning, save the approved plan in the task or a Markdown file, then implement in small Act-mode slices rather than one sprawling run.

Run this split on one feature that normally takes you 30 to 60 minutes—not a toy bug. Afterward, inspect where the Plan model found useful constraints, where the Act model needed corrections, and whether the model switch reduced waiting or just added ceremony. Keep the pairing only if it makes the diff smaller, the tests more targeted, or the decisions easier to review.