Using Opus for Planning with Cheaper AI Models as Executors

Apr 2, 2026

The Problem

My Claude Opus API bill was getting out of hand. I was spending hundreds of dollars a month on coding tasks, many of which were straightforward implementation work that didn’t require Opus-level reasoning.

The insight that changed everything: “As long as you instruct Opus to create a plan that a junior developer can follow, MiniMax and GLM perform well as executors.”

This isn’t about being cheap. It’s about matching model capability to task complexity. Opus excels at architecture decisions and complex reasoning. But for following a detailed plan to write boilerplate code? A cheaper model works just fine.

The Planner-Executor Pattern

The pattern splits work into two phases:

Planner (Opus): Strategic thinking, architecture decisions, breaking down complex tasks into step-by-step instructions.

Executor (GLM 5.1, MiniMax 2.7, Kimi 2.5): Following structured instructions, writing code based on clear specifications, implementing individual components.

I tried this approach and it works. My costs dropped by about 70% while maintaining code quality. The key was learning how to write plans that the executor models could actually follow.

Why Cheaper Models Struggle Without Planning

When I first tried using budget models directly, the results were disappointing. Code would be syntactically correct but architecturally wrong. Functions would miss edge cases. Database schemas would lack proper indexes.

The problem wasn’t the model’s coding ability. The problem was insufficient context about what to build and why.

DIRECT EXECUTION:
  Request: "Add user authentication"
  Budget Model: [Makes assumptions]
  Result: Works but missing rate limiting, no password reset,
          wrong session timeout, inconsistent error handling

PLANNER-EXECUTOR:
  Opus Plan: "Add authentication with these specs:
    - Email/password with bcrypt (cost factor 12)
    - Rate limit: 5 attempts per 15 minutes
    - Session: 24 hour expiry, refresh on activity
    - Password reset: token valid 1 hour
    - Error messages: generic (don't leak user existence)
    - Files to modify: auth.py, models/user.py, routes/auth.py"

  Budget Model: [Follows plan precisely]
  Result: All requirements met, consistent implementation

The plan bridges the gap between “what I want” and “how to build it.”

Setting Up the Workflow

I use Claude Code Router (CCR) to switch between models. It provides a GUI and handles the configuration complexity.

Installation

# Install Claude Code
npm install -g @anthropic-ai/claude-code

# Install Claude Code Router
npm install -g @musistudio/claude-code-router

# Start the GUI for configuration
ccr ui

Configuration for GLM 5.1

{
  "defaultModel": "glm-5.1",
  "apiProvider": "zhipu",
  "baseUrl": "https://open.bigmodel.cn/api/paas/v4",
  "apiKey": "your-glm-api-key-here"
}

Configuration for MiniMax 2.7

{
  "defaultModel": "MiniMax-M2.7",
  "apiProvider": "minimax",
  "baseUrl": "https://api.minimax.chat/v1",
  "apiKey": "your-minimax-api-key-here"
}

You can also use environment variables if you prefer:

# For GLM 5.1
export ANTHROPIC_AUTH_TOKEN="your-glm-api-key"
export ANTHROPIC_BASE_URL="https://open.bigmodel.cn/api/paas/v4"

# For MiniMax 2.7
export ANTHROPIC_AUTH_TOKEN="your-minimax-api-key"
export ANTHROPIC_BASE_URL="https://api.minimax.chat/v1"

The Planning Prompt That Works

After trial and error, I landed on a planning prompt that produces reliable results:

# Task: Create Implementation Plan

Create a detailed implementation plan that a junior developer can follow.

## Requirements
- [List your requirements here]

## Constraints
- [List any constraints]

## Output Format
Provide:
1. File structure changes needed
2. Step-by-step implementation instructions
3. Code snippets for each step
4. Testing recommendations
5. Potential pitfalls to avoid

Make each step clear and self-contained.

The key phrase is “a junior developer can follow.” This forces Opus to be explicit about assumptions that a senior developer would make implicitly.

My Workflow

I’ve settled into a rhythm:

#!/bin/bash

# Step 1: Create plan with Opus
echo "Step 1: Creating plan with Opus..."
claude --model claude-opus-4-6 "Create a detailed implementation plan for [task]"

# Step 2: Save the plan
# (I copy the plan to a file or the next prompt)

# Step 3: Switch to executor model using CCR or config edit
echo "Step 2: Switching to executor model..."
# Use cc-switch or edit ~/.claude.json

# Step 4: Execute the plan
echo "Step 3: Executing plan with budget model..."
claude "Follow this plan: [paste plan from step 1]"

# Step 5: Review with Sonnet or Opus
echo "Step 4: Reviewing implementation..."
claude --model claude-sonnet-4-6 "Review this implementation for quality"

The review step is important. I always have Sonnet or Opus check the executor’s work before considering the task complete.

Model Comparison

After using all three executor models, here’s what I found:

Model	Best For	Notes
GLM 5.1	Standard coding tasks, Chinese projects	Strong coding ability, needs detailed instructions
MiniMax 2.7	Fast iterations, well-defined components	Good instruction following, fast responses
Kimi 2.5	Large context, documentation-heavy work	Long context window, newer with less community feedback

For most coding tasks, GLM 5.1 and MiniMax 2.7 are interchangeable. I pick based on which API is more responsive at the moment.

Cost Comparison

The numbers speak for themselves:

Model	Input (per 1M)	Output (per 1M)	Typical Use
Claude Opus 4.6	$15	$75	Planning, complex reasoning
Claude Sonnet 4.6	$3	$15	Review, medium complexity
GLM 5.1	~$0.15	~$0.60	Execution, routine coding
MiniMax 2.7	~$0.20	~$0.80	Execution, routine coding

For a typical feature that requires 50K input tokens and 20K output tokens:

Opus Only:
  Input:  50K * $15/1M  = $0.75
  Output: 20K * $75/1M = $1.50
  Total:  $2.25

Planner-Executor (Opus for planning 20%, budget model for execution 80%):
  Opus Input:   10K * $15/1M   = $0.15
  Opus Output:  5K * $75/1M    = $0.375
  GLM Input:    40K * $0.15/1M = $0.006
  GLM Output:   15K * $0.60/1M = $0.009
  Total:  $0.54

Savings: 76%

Actual savings vary, but 60-80% reduction is typical.

Mistakes I Made

Mistake 1: Vague plans

My first attempts failed because the plans were too high-level. “Add a user model” isn’t enough. The executor needs specifics: fields, types, constraints, relationships.

Mistake 2: No review step

I got cocky and skipped the review. Then I shipped a bug that the executor introduced because it misunderstood an ambiguous instruction. Always review.

Mistake 3: Using executor for architecture decisions

Budget models struggle with system-wide implications. When I asked GLM to “design the authentication system,” it produced a naive solution. Plans should be detailed enough that architectural decisions are already made.

Mistake 4: Forgetting context handoff

When switching models, context is lost. I now save the complete plan and any relevant context to a file that the executor can read.

When to Use Which Model

USE OPUS FOR:
  - Architecture decisions
  - Complex debugging
  - Breaking down ambiguous requirements
  - Designing APIs and schemas
  - Code review of critical paths

USE SONNET FOR:
  - Code review (most cases)
  - Medium complexity implementation
  - Refactoring
  - Test writing

USE BUDGET MODELS FOR:
  - Following detailed plans
  - Writing boilerplate
  - Implementing well-defined functions
  - Converting specs to code
  - Documentation

The rule of thumb: if you can write a detailed enough spec that a junior developer could implement it, a budget model can too.

What I’d Do Differently

If I were starting fresh, I’d begin with the planner-executor pattern from day one. The discipline of writing detailed plans actually improves my code regardless of which model implements it. I catch issues during planning that I’d previously discover only during debugging.

The workflow also scales better. As my team grows, they can use the same plans I write, whether they’re implemented by humans or AI.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 Claude Code Model Configuration
👨‍💻 GLM-5 vs MiniMax-M2.5 Performance Comparison
👨‍💻 Claude Code with GLM Configuration Guide
👨‍💻 Claude Code Router Configuration
👨‍💻 Coding Plan Comparison Platform

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!