Skip to main content
  1. Posts/

Stop burning your best model's tokens on grep

··1070 words·6 mins·
Nick Liu
Author
Nick Liu
Building infrastructure for Facebook Feed Ranking at Meta. Previously at Walmart, Twitter, AWS, and eBay. MS in Computer Science at Georgia Tech.
Table of Contents
I kept slamming into my Claude subscription's usage limits, and the workload didn't feel heavy enough to explain it. The culprit was allocation, not volume: my main session ran on the most capable model available, and that model was also doing the grep runs, the batch edits, and the yes/no verification passes. Flagship reasoning, billed at flagship rates, spent on work a model a tenth the price does identically well.
Tested with Claude Code 2.1.x · macOS

Where the tokens actually go
#

Two things surprised me when I looked at my consumption honestly.

First, the main conversation loop is the expensive part. Every turn re-reads the accumulated history, so a long-running session pays for its own past on every message, cached or not. Keeping that loop on a top-tier model means the priciest per-token rate multiplies against the largest token base.

Second, mechanical work is indifferent to model quality. A task like “run this experiment exactly as specified and capture the outputs” or “check these eight criteria and report PASS or FAIL” produces the same result from a mid-tier model as from a flagship. I checked, repeatedly, because the whole scheme depends on it. The delta shows up in judgment tasks: design, debugging, writing. It does not show up in checklists.

When I set this up in July 2026, the list prices told the story: the flagship tier cost ten times the cheapest tier per output token, with the mid-tier around a third. Current numbers live on Anthropic’s pricing page; the ratios are the durable part.

The mechanism: subagents carry their own model
#

Claude Code lets you define custom subagents as markdown files in ~/.claude/agents/. The frontmatter takes a model field, and that is the entire trick. The main loop stays on the expensive model for orchestration and judgment; anything delegated to one of these agents runs on the model named in its file, in its own separate context window.

each in its own context window

main loop
flagship model
plans, judges, writes

bulk-worker
mid tier

scout
mid tier

verifier
cheapest tier

results come back as short reports

each in its own context window

main loop
flagship model
plans, judges, writes

bulk-worker
mid tier

scout
mid tier

verifier
cheapest tier

results come back as short reports

I defined three:

AgentModel tierJob
bulk-workermidFully specified mechanical work: batch edits, scripted experiments, boilerplate
scoutmidRead-heavy reconnaissance that returns conclusions, not file dumps
verifiercheapestChecklist verification, grading, link checking, lint triage

The bulk-worker definition, in full, because the shape matters more than the words:

---
name: bulk-worker
description: >-
  Use for well-specified mechanical work that needs no deep judgment:
  applying a known edit pattern across many files, batch renames,
  frontmatter updates, formatting fixes, writing boilerplate or config
  from a clear spec, converting data between formats. The task must be
  fully specified by the prompt; if it requires design decisions or
  debugging, use the main loop or a stronger agent instead.
model: sonnet
---

You are a mechanical execution agent. You receive a fully specified task
and carry it out exactly as described.

The description field does double duty. It documents the agent for me, and it is what the orchestrating model reads when deciding whether to delegate, so the “use for X, not for Y” boundary goes right there.

The second benefit took me longer to appreciate than the pricing: delegated work happens in a separate context window. When the verifier churns through a fifty-step checklist, none of that transcript lands in my main session’s history. The main loop stays lean, which compounds, because a lean history is cheaper on every subsequent turn.

What a week of this looks like
#

Some real delegations from my logs, with the token counts their runs reported:

  • A port-collision experiment for a blog post: the bulk-worker started two dev servers, captured the exact error output, tested the fix, and cleaned up. About 32,000 tokens on the mid tier.
  • A seven-point site health check after three weeks away: the verifier ran git, curl, and GitHub CLI checks and reported PASS on each with evidence. About 25,000 tokens on the cheapest tier.
  • Pre-publish checklists for new posts, eight criteria each including fetching every reference URL: roughly 25,000 tokens per post, cheapest tier.

In one heavy session that came to roughly 110,000 tokens of work that never touched the flagship model. Priced at the ratios above, the same work through the main loop would have cost several times more against my limits, and the checklist transcripts would have bloated the main history on top of it.

The gotcha that cost me a restart
#

Agent definitions are read once, when a session starts. I wrote the three files, dispatched work to the verifier in the same session, and got back “Agent type ‘verifier’ not found”. Nothing was wrong with the files. New definitions simply do not exist until the next session. Create, restart, then dispatch. It is documented behavior, but the error message does not say “restart”, so it reads like a typo hunt until you know.

Where the line sits
#

The allocation rule I converged on: the expensive model plans, decides, writes, and reviews; everything else gets a spec and a cheaper executor. Writing the spec is the tax. A delegation prompt has to be complete enough that a literal-minded executor cannot go wrong, which occasionally means the spec takes longer than doing the task. For one-off ten-second tasks, delegation loses. For anything repetitive, anything verifiable by checklist, or anything that would dump noise into the main context, it wins by a wide margin.

Lessons
#

  • Usage limits are an allocation problem before they are a volume problem. Audit which model does your mechanical work before rationing your prompts.
  • A subagent’s model field is the cost lever. The description field is the routing logic. Write both like they will be read by a machine, because they will.
  • Delegated transcripts stay out of the main history. The savings compound on every later turn of the expensive loop.
  • Agent definitions load at session start. Create, restart, then dispatch.
  • Delegation is only as good as the spec. If the task cannot be specified completely, it was never mechanical work to begin with.

References
#

Related

Running six agents made tab patrol my biggest time sink. So: a herdr trial.

Once I had six Claude Code sessions open at once, the most expensive part of my workflow was not writing code. It was patrol: cycling through tabs to see which agent was still running and which one had been sitting on a question for ten minutes. tmux has no concept of any of this. To tmux, every pane is a rectangle of terminal, equally interesting, equally mute. herdr’s pitch lands exactly on that pain: panes are still real terminals, but a sidebar shows each agent’s live state. So it got a one-month trial, with exit conditions written down before it started. The verdict lands on August 16, and this post is honest about still being inside the window.

Four review claims sounded right. Each took two minutes to disprove.

··1323 words·7 mins
After a month of overhauling my dotfiles with AI in the loop, the real value was not "the AI writes my configs". It was two much more boring properties: the research side keeps finding things I cannot see, and I verify every claim it makes before acting. Skip the first and you only ever fix problems you already knew about. Skip the second and a plausible-sounding wrong answer walks you into a ditch. The loop # claim fails verification

Hooks are guarantees, skills are knowledge, subagents are other people.

··1101 words·6 mins
My Claude Code config now holds two hooks, ten skills, and three custom subagents, and most of them started life in the wrong layer. The instruction the model followed nine times out of ten lived in a prompt until I accepted that nine out of ten is a coin I lose every day. The workflow I pasted into chats became a skill. The bulk work that was draining my priciest model's quota became a fleet of cheaper agents. Same features, different failure modes. Taming Claude Code Sessions · Part 6 of 6 1 2 3 4 5 6 🧪 Tested with Claude Code 2.1.x · macOS The four layers # Claude Code has four extension points, and they answer four different questions: