How to Reduce Claude Code Token Waste Without Lowering Your Engineering Standards

Practical lessons from building a personal operating system with AI agents, local models, and automated workflows.

There is an awkward moment when you are halfway through building something, the work is progressing, and Claude tells you that you have reached your usage limit.

I used to reach that point within three or four days of the week.

I have a Claude Max subscription: $200 a month, or $242 after tax. Yet with several projects running in parallel, I kept exhausting the available allowance.

I wanted to keep the quality of the work and the pace of delivery. That meant understanding where the capacity was going.

Once I looked closely, I found repeated status checks, oversized conversations, unnecessary coordination, and investigations that continued without a clear stopping point.

These were familiar software engineering problems appearing in a new form. The resource being wasted happened to be tokens.

The context: building LifeOS

I am building LifeOS around a personal philosophy: the key to happiness is health, wealth, and wisdom.

LifeOS is my personal operating system, not a commercial product. It helps me organise work and decisions around those priorities.

I currently have 62 agents that I treat as employees, across Authority, Revenue, Wisdom, Content Studio, Delivery, Health, Governance, and System. Every employee has a contract defining its responsibilities and boundaries. Its work is measured and governed against that contract.

Those 62 employees are a mixture of deterministic n8n workflows, shell-based automation, and model-powered agents, including a Qwen model running locally on my Mac mini. Together, they support an operation that runs around the clock.

Local execution keeps the ongoing operation economical. For work that needs additional capability, I also maintain subscriptions or API balances for models from providers such as Gemini, DeepSeek, Kimi, and GLM.

The Claude Code work happens in three development offices:

• Architect: handles architecture, shared interfaces, and decisions across projects.

• Builder: implements changes and coordinates delivery.

• Auditor: independently checks the work and its evidence.

These offices build the system. My Delivery pod runs multiple projects in parallel through their own agentic workflows.

You do not need this setup to apply the lessons below. The same waste appears in a single Claude Code session working on an ordinary project.

The problem: useful work was surrounded by expensive overhead

When I reviewed the workflow, several patterns stood out.

Some scheduled checks found nothing actionable nine times out of ten. One change went through eleven review rounds. Agents passed long explanations between offices. Senior sessions absorbed raw logs and broad code searches when they needed only a specific finding.

Each activity looked reasonable in isolation. Together, they consumed capacity without producing enough progress.

Long conversations added another source of overhead. Claude Code manages context through mechanisms including caching and compaction, so it would be inaccurate to say every previous token is always processed at full price. Nevertheless, unnecessary context and repeated processing remain worth reducing. Anthropic’s own guidance recommends context management, appropriate model selection, and delegating verbose operations. Claude Code cost guidance

I began evaluating the workflow around a more useful question:

How much work does it take to produce a verified result?

That includes implementation, investigation, review, correction, and coordination.

How I changed the workflow—and what you can do

1. Replace repeated model checks with deterministic tools

I had agents repeatedly checking whether something had changed, whether a process was healthy, or whether work was ready.

Many of these questions had answers a small tool could produce.

I built tools that gather operational status, detect changes, check prerequisites, and return concise results. Background monitors now watch for meaningful events and wake an agent when judgement is needed. Scheduled checks remain as a fallback.

The same principle applies inside a coding project. Formatting, checking file existence, validating configuration, and running known tests usually do not require fresh reasoning.

The tool itself can perform that work without model inference. Asking Claude to invoke it and interpret its output still uses tokens, which is why compact output matters.

Try this instruction:

Review the repeated checks in this workflow. Identify which can be performed reliably by a script, test, hook, or existing tool. Propose the smallest useful automation. Return a concise status with evidence, and distinguish failure from an inability to check.

Start with the check you repeat most often. You do not need to build an entire automation platform.

2. Keep the main conversation focused on decisions

A large log can be useful evidence. It rarely needs to become the centre of a long-running conversation.

I moved noisy investigations into narrowly scoped sub-agents. They inspect the relevant material and return a short report containing the conclusion, supporting references, and unresolved questions.

Claude Code’s separate sub-agent contexts support this kind of isolation. Sub-agent documentation

However, delegation has overhead too. Creating several agents for a simple task can increase consumption. I use it when an investigation is substantial enough to justify the separation.

Try this instruction:

Investigate this specific failure. Start with the relevant logs and files, and widen the search only if necessary. Return the finding, evidence locations, uncertainties, and recommended next action in approximately 150 words. Keep detailed output available for follow-up.

The word limit applies to the report. It should never prevent an agent from reporting a material risk or unresolved failure.

3. Define the assignment before starting the work

Treating agents as employees changed how I briefed them.

A person given a vague assignment will make assumptions. An agent does the same, often at considerable speed.

My contracts establish responsibilities and authority. Individual assignments then define the immediate deliverable, scope, acceptance criteria, and evidence required.

For a coding task, that means being explicit about what should change and how we will know it works.

Try this instruction:

Implement [specific outcome] within [scope]. Preserve [important constraints]. Completion requires [observable acceptance criteria]. Run the relevant checks and report their results. If missing information prevents a correct implementation, identify the exact decision needed. Record unrelated findings separately.

This reduces exploratory wandering and makes review more efficient.

4. Put a checkpoint on investigations

An agent can keep investigating long after it has stopped making useful progress.

In my workflow, short-lived work units have a fifteen-tool-turn checkpoint. At that point, the agent records what it completed, what it measured, what remains uncertain, and the next useful step.

Fifteen is a rule for my environment, not a universal optimum. The important part is having a checkpoint that exposes progress.

A written instruction also needs enforcement if you require a hard limit. In an automated workflow, that belongs in the runner or orchestration layer.

Try this instruction:

After fifteen tool calls, pause for a progress checkpoint. State what has been established, what remains unknown, and whether continuing the current approach is justified. If handing off, preserve the evidence and the next concrete step.

Difficult tasks can continue. They should continue with a reason.

5. Match capability to the task

I reserve stronger reasoning for architecture, ambiguity, and difficult trade-offs. Suitable implementation work goes to Sonnet; narrowly defined mechanical edits can go to Haiku. Repeatable operations increasingly move into tools.

LifeOS follows the same principle more broadly: local models handle appropriate routine work, and external models are available when additional capability is justified.

The useful comparison is the total cost of reaching an accepted result. A cheaper model that needs repeated correction may be the more expensive choice.

Try this instruction:

Classify the work into deterministic operations, bounded implementation, and decisions requiring substantial reasoning. Recommend an execution approach for each. Keep the acceptance criteria and verification requirements consistent across models.

If your setup cannot route models automatically, use the classification to make the choice yourself.

6. Store decisions where the next session can find them

Long conversations often become informal project databases.

That makes it expensive to recover a decision, and easy to recover the wrong version of it.

I keep durable records of decisions, project state, and handoffs. Agents read the authoritative source when they need it. A fresh session can begin from a compact account of the current work.

For a smaller project, a short decision log and a current handoff file may be sufficient.

Try this instruction:

Before ending this task, update the handoff with the current state, decisions and their rationale, changed files, verification results, blockers, and next action. Link to detailed evidence. Remove superseded guidance so the next session can identify the current position.

Keep that record concise. Copying the whole conversation into a file merely relocates the clutter.

7. Make review answer a specific question

Eleven review rounds on one change made me examine how review was being conducted.

I moved toward a focused review followed by targeted verification of the resulting fixes. Additional review must have a clear purpose, such as resolving a remaining defect or checking a newly affected area.

Automated gates handle repeatable checks. Human and model judgement can then focus on behaviour, design, security, and gaps in the evidence.

During this work, our main verification gate grew from 86 to 104 checks. That increase does not prove software quality by itself, but it reflects the direction of the process: more enforceable verification while reducing repetitive discussion.

Try this instruction:

Review this change against its acceptance criteria and relevant risks. Report actionable findings with evidence. After fixes, verify those findings and any newly affected behaviour. Expand the review if the changes introduce a new risk or expose a broader defect.

Saving tokens should never mean leaving a known correctness issue unresolved.

8. Require evidence before calling work complete

Some of my most expensive failures began with an apparently reassuring status message.

An agent announced an action that had not completed. A failed query returned an empty result that looked healthy. A fix existed in the repository while the running system still used the old version.

Each incident generated more investigation and rework.

I now require the workflow to distinguish between an intention, an attempted action, and a verified outcome.

Try this instruction:

Report completed actions with their evidence. Distinguish “passed,” “failed,” and “could not verify.” For deployed changes, check the running version or behaviour. State any unverified outcome explicitly.

This is also where governance becomes practical. I have published research on AI governance and continue collecting operational data for that research. Contracts, measurements, and verifiable outcomes give me something concrete to study.

They also make the system easier to operate.

How to start on your own project

You can apply these ideas without three offices or dozens of agents.

For your next few tasks, record:

• The outcome you wanted.

• Elapsed time and usage consumed.

• Repeated checks or investigations.

• Review and correction rounds.

• The evidence that established completion.

Then change one recurring source of waste. Automate a repeated check, narrow an assignment, or reduce a noisy investigation’s impact on the main conversation.

Compare similar tasks using the same quality criteria. Watch both usage and completion time. Token consumption alone cannot tell you whether the workflow improved.

You can begin with this request:

Audit how we are using Claude Code on this project. Look for repeated deterministic work, unnecessary context, duplicate investigation, vague assignments, and review loops. Identify the three most useful improvements, with evidence from the available history. Preserve required testing and acceptance criteria. Explain how we can measure whether each change reduces usage without increasing defects or delivery time. Do not estimate savings without data.

What optimisation means to me

My subscription still costs $242 a month. Improving the workflow does not lower that fixed price. It makes the included capacity more useful. Separately metered API spending is a different measure and should be tracked separately. Claude Code usage and cost guidance

I do not have a controlled benchmark that supports a precise savings percentage or a universal claim about speed.

What I have is a practical process shaped by decades of software development: clear assignments, appropriate tools, bounded investigations, durable decisions, and evidence-based completion.

Those disciplines help me deliver production-grade software with AI while keeping the work measurable.

If you keep running out of Claude capacity, examine what happens between the useful coding steps. The repeated checks, oversized handoffs, and uncertain definitions of “done” may be consuming more than you expect.

That is where I found much of my waste—and where I would start again.