As AI-assisted development becomes more powerful, it also becomes easier to waste tokens. As more AI tools move toward usage-based pricing, usage caps, and token-aware workflows, getting more value out of every token is becoming more important. Sometimes the waste comes from using your strongest model for everything. Planning, implementation, debugging, refactoring, test writing, code review, and final validation. While that works, it can get expensive fast.
The better pattern is what I think of as valuemaxxed model orchestration. The idea is to use the strongest model where judgment matters most, and use cheaper models where the work is clear, scoped, and easy to verify. In my workflow, that usually means using higher-reasoning models for planning, architecture, risk analysis, and review. Then I delegate the more mechanical or well-scoped implementation work to Codex via the Codex plugin for Claude Code. The goal is to maximize the value created per token.
The Role of CLAUDE.md
One way to make this repeatable is to put the model-routing strategy directly into your CLAUDE.md file. I gave the agent a decision framework for choosing the right model based on the type of task.
Here is an example of how this looks in my CLAUDE.md file:
## Picking the right models for workflows and subagents
Rankings, higher = better. Cost reflects what I actually pay (OpenAI has
really generous limits), not list price. Intelligence is how hard a problem
you can hand the model unsupervised. Taste covers UI/UX, code quality, API
design, and copy.
| model | cost | intelligence | taste |
| --- | --- | --- | --- |
| gpt-5.5 | 9 | 8 | 5 |
| sonnet-5 | 6 | 5 | 7 |
| opus-4.8 | 4 | 8 | 8 |
| fable-5 | 2 | 9 | 9 |
How to apply:
- These are defaults, not limits. You have standing permission to override
them: if a cheaper model's output doesn't meet the bar, return or redo the work
with a smarter model without asking. Judge the output, not the price tag.
Escalating costs less than shipping mediocre work.
- Cost is a tie-breaker only; when axes conflict for anything that ships,
intelligence > taste > cost.
- Bulk/mechanical work (clear-spec implementation, data analysis, migrations):
gpt-5.5 - it's very cheap and token efficient.
- Anything user-facing (UI, copy, API design) needs taste ≥ 7.
- Reviews of plans/implementations: fable-5 or opus-4.8, optionally gpt-5.5 as
an extra independent perspective.
- Never use Haiku.
- Mechanics: gpt-5.5 is handled natively via the `openai/codex-plugin-cc`
plugin inside Claude Code, automatically adopting your user-level
configurations from `~/.codex/config.toml`. Avoid writing custom bash scripts;
instead, utilize the plugin's built-in tools and skills:
- `/codex:review` - Run non-destructive, read-only code quality assessments.
Supports `--base <ref>` for branch analysis.
- `/codex:adversarial-review` - Perform a skeptical design review to
pressure-test tradeoffs, auth, and reliability. Append custom focus text at
the end of the command to steer the focus.
- `/codex:rescue` - Subcontract active debugging, multi-file refactoring, or
implementation loops to Codex when a second pass is required.
- `/codex:status` / `/codex:result` / `/codex:cancel` - Use these to check,
fetch, or abort asynchronous jobs when using the `--background` flag on heavy
tasks.
- Claude models (sonnet-5, opus-4.8, fable-5) run via the Agent/Workflow model
parameter.
Using gpt-5.5 inside workflows and subagents:
- Subagents and automated workflows should call the plugin's native slash
commands or its exposed `codex-cli-runtime` skills to delegate tasks directly,
omitting the need for raw terminal wrapping.
- For closed-loop quality assurance, keep the review gate turned on via
`/codex:setup --enable-review-gate`. This ensures a stop hook automatically
challenges Claude's outputs using Codex before finalizing, preventing broken
code or weak design assumptions from reaching the main session unvetted.
## Fable Orchestration Mode
When using Claude Fable 5, act as the orchestrator, not the default implementer.
Your responsibilities:
- Read `CLAUDE.md`, the active `SPEC.md`, and relevant source files before planning.
- Create a task ledger before coding begins.
- Split work into small, independently verifiable tasks.
- Delegate implementation or second-opinion review to Codex when useful.
- Do not let worker agents change scope.
- Review worker output against the original spec before accepting it.
- Integrate only changes that satisfy the acceptance criteria.
- Run or request the most relevant verification commands before claiming completion.
Use Fable for:
- Planning
- Architecture decisions
- Risk analysis
- Scope control
- Reviewing Codex output
- Final synthesis
Use Codex for:
- Focused implementation tasks
- Bug investigation
- Test writing
- Refactoring a clearly scoped file or component
- Adversarial code review
Do not delegate vague tasks to Codex. Every delegated task must include:
- Goal
- Files likely involved
- Constraints
- Acceptance criteria
- Tests to run
- Expected output format
Rankings are scored from 1 to 10, where higher is better. Cost efficiency reflects my actual usage limits and subscription setup, not necessarily public list price. Intelligence means how difficult or ambiguous a task the model can handle with limited supervision. Taste covers UI/UX judgment, code quality, API design, product sense, and copywriting. These scores and just defaults are can be changed.
The agent can override the matrix when quality requires it. If a cheaper model does not meet the bar, the work should be retried or escalated to a stronger model.
For this workflow, Codex is handled through the openai/codex-plugin-cc plugin inside Claude Code. That's right, the orchestration layer can delegate directly to Codex using the plugin’s built-in commands!
Planner-Worker Orchestration
The pattern looks like this:
Claude/Fable plans the work
↓
Spec is broken into scoped tasks
↓
Codex performs bounded implementation or review
↓
Claude/Fable evaluates the result
↓
Only accepted work is integrated
↓
Final review checks the implementation against the spec
Here's an example of how that looks in Claude Code on a real project. I'm building an app where users customize championship rings with their name, number and position. I do not want the strongest model spending all of its time renaming props, wiring handlers, and updating tests. I want the stronger model to define the component contract, identify edge cases, review accessibility concerns, and decide whether the implementation actually satisfies the spec. Once that plan is clear, Codex can handle the bounded implementation work.
Here's an example of Codex's work being rejected by Fable:
The part that is important is that this pattern introduces a controlled loop where the smarter model controls the cheap model and verifies the output. The smarter model uses the CLAUDE.md and SPEC.md files along with skills such as playwright and chrome dev tools to verify the output.
The Bigger Point
The days of tokenmaxxing or being able to use the best models with xhigh reasoning within our subscriptions without constantly hitting token limits seem to be coming to an end. Engineers will now need to be smarter about their AI usage to get the most out of the tool. The challenge now is about routing the right work to the right model at the right time. Use the smarter model for judgment, cheaper models for implementation, and verify everything against the spec.