novitckii
← All resources
Gated setup · Claude CodeFable 5Sonnet 5/advisor

Your smartest model shouldn't be writing boilerplate.

You're hitting Claude limits because your most expensive model is doing everything, including the grunt work. Claude Code has three built-in ways to split the job: a strong model makes the decisions, a cheap model does the typing. Same quality where it counts. Far fewer tokens where it doesn't.

You commented setup — here's the exact pairing: Sonnet 5 as the executor, Fable 5 as the on-demand advisor, so most of your tokens bill at the cheaper rate. It's the pattern Anthropic's @ClaudeDevs posted.

The pattern from @ClaudeDevs — most tokens bill at the lower executor rate.

Why it works

Thinking is rare. Typing is constant.

iA coding session is a handful of hard decisions wrapped in thousands of lines of routine output. Only the decisions need your best model — so expensive tokens go where judgment lives (planning, architecture, error triage) and cheap tokens handle file searches, edits, and code generation. Your limit then drains at the worker rate, not the planner rate.
The kit

Paste-ready config.

The worker subagent file plus a one-page cheatsheet of the three commands. Grab the zip, or copy the pieces off the page below.

The setup · three ways, stack them

Strong model decides. Cheap model types.

Use whichever fits the session, or run all three. Every one is built into Claude Code — no hacks.

01
Plan expensive, execute cheap

opusplan

The strong model handles plan mode, then Claude Code auto-switches to the cheap model the moment execution starts. Top-tier planning without paying top-tier rates for every edit.

/model opusplan
02
The advisor · the tweet's pattern

Cheap driver, expensive advisor

Run a cheap model as your main session and set a stronger one as the advisor. The main model consults it automatically at key decision points — planning, recurring errors, completion checks. Documented feature, not a hack.

/advisor fable   # or: /advisor opus
03
Delegate the grunt work

Worker subagents

Keep an expensive orchestrator for the big picture and hand token-heavy work to a cheap worker. Drop this in .claude/agents/worker.md — it's in the kit:

---
name: worker
description: Executes well-scoped implementation tasks. Use for writing code, running searches, and making edits once the plan is set.
model: sonnet
tools: Read, Edit, Write, Grep, Glob, Bash
---

You are an implementation worker. Execute the task exactly as scoped.
Do not redesign the approach. If the plan is ambiguous, stop and report back.
Straight answers

The honest FAQ.

Is /advisor some hidden trick?

No — it's a documented Claude Code feature. You're just using it on purpose: cheap model in the driver's seat, strong model on call for the moments that matter.

Doesn't running two models cost more?

The strong model only fires at decision points instead of on every token. The bulk of your usage moves to the cheap model — that's the whole point, and why most tokens bill at the lower executor rate.

Should the worker be Sonnet or Opus?

Sonnet. The worker executes a plan that's already made, and it handles that well. Save Opus and Fable for the roles where judgment matters — planning and advising.

Where this comes from

This is the executor/advisor pattern Anthropic's @ClaudeDevs posted. I've run a version of it since Fable came back — first with Opus as the advisor, and honestly Sonnet as the worker holds up better than I expected. Try it, then ping me on Instagram with your token graphs, or compare setups on Skool.

Get my exact setup — free

Drop your email and I'll send you the opusplan config, the advisor setup, and the worker subagent file, ready to paste into your project. Plus every other resource in the library.

Keep going

One email a week. Edges like this.

The Claude Code settings, skills, and workflows that quietly save you money and limits — the exact steps, while they still work.