How to Reduce Claude Code Token Usage: The Cheapest Model That Does the Job

By 11 AM I was out of Claude credits. Every day.

The morning routine I described in part one was working. My day plan was waiting for me at 8:00, my standup wrote itself, my questions got answered. And then I would sit down to actually work, and by the middle of the morning I'd be staring at a "usage limit reached" message, waiting for the five-hour window to reset, with everything stopped.

This post is about how I cut my Claude Code token usage without giving anything up: not the routines, not the code review, not the quality. The short version is that I stopped paying top-tier prices for mechanical work, and gave each job to the cheapest model that does it well. The long version has four small agents in it, and a nickname.

Why Claude Code burns tokens faster than you think

When I looked at where the credits went, it wasn't one thing. It was three habits, all reasonable on their own.

The same model for everything. I used the most capable model to decide what to build and to read a diff. Reading a diff is mechanical. Deciding what to do about it is not. I was paying the same for both, and most of my tokens went to the mechanical half.

Every session started from zero. Each new session re-read Jira, Slack and GitHub as if it had never seen them. Pull request diffs went into the context whole: forty files to extract the three lines that mattered. Nothing I had already analyzed was reused.

Everything ran in the same window. The morning routine, the coding, the reviews. Claude's plans meter usage in five-hour windows, and I was spending mine by mid-morning.

The request I wrote down for myself was simple: do the same work with far fewer tokens, without losing judgment, and without the mechanical parts landing back on me.

Claude Code model selection: give every job the cheapest model that does it well

The way out was to delegate. Not to a person. To smaller models, with clear limits.

The rule is one sentence: each job goes to the cheapest model that does it well, with explicit boundaries. In practice that produced three tiers:

• Haiku reads. Fetching a pull request's checks, listing review comments, reading and writing my knowledge folder. Fast, cheap, and never asked to interpret anything.
• Sonnet executes. Writing code to a precise spec, drafting tickets in a fixed format. Real work, but bounded work.
• Opus decides. The main session, the one I talk to. It plans, it judges, it orchestrates the others. And above it, me: I approve and I merge.

Anthropic has a name for this shape in their guide to building effective agents: orchestrator-workers. A central model breaks work down, hands pieces to workers, and synthesizes what comes back. I didn't invent it. I applied it, with a twist that matters for cost: the workers run on cheaper models than the orchestrator, and each worker runs in its own context window, so the expensive session only ever sees a short answer, never the raw material.

Haiku · readsScout GitHub and CI status, review threads. Returns evidence, never interprets.Librarian Reads and writes the knowledge folder. Nothing is analyzed twice.Sonnet · executesCoder Code to a precise spec. Never commits.Ticket machine Tickets people read. Searches duplicates first.Opus · decidesMain session Plans, judges, orchestrates the others.You · approve and mergeHuman Reads what gets published. Marks the PR ready. Merges.Each job goes to the cheapest model that does it well. The expensive session only sees short answers.

In Claude Code this is a one-line decision per subagent: the model field in the agent's file takes haiku, sonnet or opus, and a tools list narrows what it can touch. That's the whole mechanism.

I didn't set out to copy a pattern, either. I kept fixing my own process until it worked the way I like, and it turned out to look like things that already existed. That happens a lot in this field, and it's a good sign.

Meet the Pepitos: four Claude Code subagents, four "nevers"

People call me Pepe. My grandmother started it, and the name has followed me everywhere since. The agents are extensions of me, so they became Pepitos.

A Pepito is a subagent I hand a job to, and it does that job correctly and within limits. The main session calls it, gives it a small task, and gets a short answer back. Each one has a model, a tool list, and a list of things it never does. The "nevers" are the part that took real incidents to learn.

The scout, on Haiku, reads GitHub and CI. Check status, review comments, unresolved threads. It returns evidence: file, line, snippet. It never interprets. If it did, the main session would act on a cheap and possibly wrong conclusion, and a wrong location costs more than not asking at all. "Not found" is a valid answer. A guess is not.

The librarian, on Haiku, is the memory. It reads and writes a knowledge folder in git: conventions per client, gotchas, a handoff file per ticket, the daily file. The agents read it before starting, so I never explain the same thing twice. More on this below, because it turned out to be the biggest token saver of all.

The coder, on Sonnet, writes code to a precise spec. Files, behavior, conventions, what not to touch. It never commits and never pushes. That rule exists because early on it started taking changes into git on its own, without passing through me or through the stronger model that decides. Nothing broke, I caught it in time, but the coder runs on Sonnet for a reason: it executes, it doesn't get the last word. The orchestrator owns that boundary now.

The ticket machine, on Sonnet, writes tickets a human wants to read. The format came from a concrete piece of feedback. The client's product lead wrote it in the team channel, in public: "These walls of text are a bit overly verbose." They were right. Nobody read them. Now a ticket is a short description for people, with context, scope, acceptance criteria and open questions, plus one collapsed comment with the full detail for whatever AI implements it. And before it creates anything, it searches for duplicates. That gate came from a real mistake: two tickets for the same request ran in parallel for ten days with two different assignees. A missing ticket costs one run. A duplicate costs two implementations.

Memory is the biggest token saver

The librarian's folder is the piece I'd keep if I had to throw everything else away.

The idea is simple: anything analyzed once gets written down, so it never has to be analyzed again. A repo's conventions, how to run its tests, which CI checks matter, the gotchas that cost me an afternoon. When a ticket is interrupted, a handoff file records where it stopped, so the next session doesn't start from scratch. The daily file from part one lives in the same place.

knowledge/ · private● in gitknowledge/├── clients/│ └── <client>/projects/<project>/│ ├── overview.md# stack, how to run and test, CI, base branch, gotchas│ └── conventions.md# the code standards reviewers actually enforce├── handoffs/│ └── <TICKET>.md# where an interrupted ticket stopped, to resume it└── personal/ ├── daily/<date>.md# the file the 08:00 routine writes ├── routines/# the documents the routines run └── claude/agents/# the Pepitos themselves, versionedAnything analyzed once gets written down here, so nobody, human or agent, analyzes it twice.

Two rules keep it useful. Reuse before re-scanning: if today's daily file already has the section you need, read it instead of hitting the sources again. And the main session should never hold raw material: GitHub payloads go through the scout, files go through the librarian, and what comes back is condensed.

Every correction I make follows the same path. Claude does something, I correct it and say why, the librarian writes it down, the next session starts from there. Without the why, the rule breaks on the first odd case.

Two workflows I repeated every day, now delegated

There were two things I did daily with exactly the same steps: implementing a ticket, and reviewing a pull request. A process you can write down is the easiest thing to delegate. So both became skills that run the whole flow.

Implement a ticket. I type a command with the ticket key. First it asks. It reads the knowledge base and the ticket, checks for duplicates, and asks me questions until nothing is unclear. Then it shows a plan: files, approach, what stays out of scope. No code until I say go; I borrowed that discipline from Matt Pocock's workflow, which we already used at Streaver. After that: branch, the coder writes, tests and lint and build run, a draft pull request in our format, CI, a self-review, and it answers every thread the other AI reviewer opens. At the end it writes a handoff. The PR stays in draft. I mark it ready.

Two limits I don't relax: the diff I review is the approved plan and nothing else, and the agent has no database access. If it needs data, it writes the exact query and I run it.

Review a pull request. The first stop is a gate: checks must be green and another AI must have reviewed already. Then three lanes run in parallel. One reads the code, with few findings and high confidence. One looks only for security issues that can actually be exploited. One is functional: a browser driven by Playwright tries what the ticket promises, not just what the diff changed. The second stop is a merged, numbered list, each item with a why and a one-line fix. I choose the numbers. Only then does it comment on GitHub, on the exact line, under my account. It never approves, never requests changes, never merges. That's mine.

Stop 1 · GateChecks greenAnother AI has reviewedOtherwise it asks first›Three lanes, in parallelCode: few findings, high confidenceSecurity: only what's exploitableFunctional: Playwright tries what the ticket promises›Stop 2 · PickMerged, numbered listA why and a one-line fix eachThe human picks the numbers›PublishComments on the exact lineUnder the human's accountNever approves, never mergesTwo stops, three lanes. The agent proposes; the human picks what gets published.

The coder learns every Friday

None of this worked the first time. The coder took changes into git on its own. The routine invented work. The tickets were bricks. What made it work was writing down every correction, and one routine that turns those corrections into rules.

Every Friday at 17:30 a routine reads the week's review comments on my pull requests, from my teammates and from the other AI reviewer, plus the corrections I typed into my sessions. It groups what repeats, writes each pattern as a short rule inside the coder's own definition, and backs up the previous version first. Then it reports what changed.

After nine Fridays the coder carries 29 learned rules, and the list is pruned every time so it stays readable. Three of my favourites:

• A regression test must fail against the bug it guards. It came from a test that passed against the buggy implementation. Now the coder mutates the fix to prove the test goes red.
• A status code is not a classification. Treating every 422 as user-correctable input hid real errors.
• The diagnosis is the analysis, not the deliverable. The coder once did a correct analysis, decided the task wasn't worth doing, and documented that in a comment instead of doing it. My reply became the rule: correct diagnosis, wrong conclusion.

My favourite thing about this loop: when a teammate leaves a comment on my pull request, they're also teaching the coder. One comment I left on a colleague's PR, about a test that never clicked Save and then asserted that nothing was saved, was a coder rule by the following Friday.

What changed: no more hitting the 5-hour usage limit

I measured this the crude way, in hours rather than tokens. Before, I was out of credits at 11 AM and waiting until 2 PM to work again, most days. Since these changes it has happened a handful of times in ten weeks. The routines run on Haiku and Sonnet and are close to free, and the expensive model is spent on the one thing that deserves it: implementing tickets with judgment.

The footprint as of September 28, 2026, ten weeks in and running mostly unattended: 47 working days logged, 129 meetings archived, 35 ticket handoffs, 9 Friday reviews, 29 rules the coder learned, and 33 context documents nobody has to write twice. All of it in a git repo, so every run leaves a trace and the next one starts from there.

Six principles that survived

What stayed after ten weeks of iterating, and what I no longer negotiate:

1. One requirement, one ticket. No routine writes a ticket on its own; the ticket machine searches first.
2. Evidence, never conclusions. The cheap agent returns file, line and snippet. Interpreting is the main session's job.
3. Scope discipline. What ships is the approved plan.
4. One source of truth. Standards live in the coder, formats in the ticket machine, conventions in one file. Anything repeated in two places drifts.
5. Questions don't block. They're written down, numbered, and repeated until answered.
6. Everything in git. Every change has history, including the agents themselves.

If you take one: one source of truth.

Build your own Pepito

A Pepito is a text file. This is my scout, trimmed, and it fits on a screen:

---
name: scout
description: Cheap, mechanical helper for the orchestrator. Fetches CI status
  and review comments for a PR. Returns concise, structured results.
  Does not write code or make decisions.
model: haiku
tools: Bash, Read, Grep
---

You are a cheap, mechanical scout. You run the reads the orchestrator asks
for and return concise, structured results. You decide nothing.

## Rules
- Don't write or edit app code. Don't open or merge PRs.
- Don't interpret or decide whether a comment applies. The orchestrator does that.
- Short responses: no full logs, no huge JSON. Extract only what was asked.
- Never search for, read, or use credentials or secrets, even if a task seems to need them.
- If a task is outside your tools, stop and say so. Do not improvise a workaround.

The top is metadata: the description the main session uses to decide when to call it, the cheapest model that does the job, and only the tools it needs. The body is the role, the typical tasks, and the nevers.

You don't need to learn a format to write one. Ask Claude: "write me a subagent that does X and never does Y." Then fix it every time it fails, and write down why. That's how all of mine were born.

One thing I learned when two teammates asked for help after the talk: neither of them wanted my Pepitos. They wanted a hand thinking through their own flow, mostly how to turn meeting transcripts into tickets people would actually read, and we left each session with a plan they could run themselves. The agents are the easy part. The flow is the work.

Or use mine. The Pepitos are becoming a plugin in Streaver OS, the harness every machine at Streaver runs, with nothing of mine or my client's inside. Your coder learns from your pull requests, not from mine.

What I don't automate

Approving or merging a pull request. Publishing anything under my name without reading it. The Pepitos propose. I decide.

Want this running inside your team?

Streaver builds applied AI and agentic systems that own real work end to end, with humans on the decisions. If your engineers are burning credits on mechanical work, or you'd rather have an operated agentic pipeline than another tool, let's talk.