Shift Note: One Planner, Many Small Execution Jobs

A useful pattern for AI-assisted work is to give the difficult decisions to one model and the routine steps to another. The planner decides what needs doing, breaks the job into bounded tasks, and defines success. The executor carries out those tasks without having to rediscover the whole strategy.

Think of a shift lead preparing a work order for an operator. The operator needs clear instructions, relevant context, and a way to report problems. Sending only “finish the project” defeats the point of having a planner.

The planner owns decisions, not every keystroke

A strong planner is useful when a request is ambiguous, touches several systems, or involves trade-offs. For a code change, it might inspect the requirements, identify affected components, and decide which tests should protect existing behavior.

The lower-cost executor handles narrower work: updating a function, drafting documentation from an outline, or transforming records according to explicit rules. “Cheaper” should mean a lower measured cost for that workload, not an assumption that the model is always faster or sufficiently accurate.

For example, you could evaluate Claude Opus 5.5 for planning and Gemini 2.5 Flash for execution. Treat that pairing as a candidate to test, not a guaranteed capability ranking. Actual suitability and cost depend on your prompts, context size, tool use, and retries.

A password-reset change becomes a bounded work order

Suppose you want to add rate limiting to a password-reset endpoint. Asking an executor to design and implement the entire feature leaves it responsible for security decisions, architecture, and code at once.

Instead, let the planner inspect the existing flow and produce a small work order. That handoff should contain enough information to act without encouraging guesswork.

• The task should state the desired behavior, including what happens when a request exceeds the limit.
• The scope should identify which files or components may change and which must remain untouched.
• The constraints should name existing interfaces, approved dependencies, and security requirements.
• The acceptance checks should describe observable results, including relevant tests and failure cases.
• The stop conditions should tell the executor when to ask for help instead of inventing a missing policy.

The executor can then implement one bounded change and return a patch, test results, and unresolved questions. It should not silently choose a rate-limit policy that the planner left unspecified.

The return path matters as much as the handoff

A two-model workflow needs a review loop. Otherwise, the planner produces instructions and everyone simply hopes the executor followed them.

Start with checks that do not depend on another model's opinion. Run tests, validate output formats, inspect the diff, and confirm that the executor stayed within scope. A successful tool call is not evidence that the requested behavior is correct.

Send failures or ambiguous results back to the planner with the relevant evidence. Avoid forwarding the entire conversation by default; it adds cost and can bury the actual problem. The planner can clarify the task, revise the plan, or take over a step that proved too difficult. Security-sensitive changes still need appropriate human review.

The savings live in total cost per accepted result

This pattern does not automatically save money. Planning, repeated context, reviews, and retries all contribute to the bill. A cheap execution call followed by several repairs may cost more than completing the task with one capable model.

Compare total cost per accepted result across representative tasks. Record review effort and completion time too. Keep a single-model baseline so you can tell whether the extra coordination helps. Small, straightforward jobs may not need a separate planner at all.

A shared relay can simplify the model plumbing

Once the workflow is useful, a shared access layer can make experimenting with model pairs less awkward. Relay365 is a pay-as-you-go relay desk for multiple model families and works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. Its API base is https://api.api365relay.com; OpenAI clients add /v1.

Relay365 is worth considering when your planner and executor use different families. Check model availability, pricing, tool support, and data-handling requirements before routing real work. If that fits your setup, create a Relay365 account and start with a small, non-sensitive test.

The operating rule is simple: let the planner resolve uncertainty, let the executor perform bounded work, and require evidence before calling the job complete.