The pre-check step that saves you 40% on tokens

The $47 morning

A few months ago I woke up, checked my API usage dashboard, and saw $47 in overnight token spend. For twelve tasks. That's almost $4 per task, which would've been fine if the tasks were complex. They weren't. Half of them were adding CRUD endpoints to an existing Express app.

I opened the logs and found the problem immediately. The agent had rewritten my entire error handling utility from scratch. It already existed. It was sitting right there in src/lib/errors.ts, 80 lines, fully tested. The agent wrote its own version in a new file called src/utils/errorHandler.ts, with different function names and a different pattern. Then it spent another 2,000 tokens importing its new version everywhere.

That single rewrite burned about 15,000 tokens. For nothing.

Agents don't know what already exists

This is the thing nobody talks about when they show off AI coding demos. In those demos the repo is empty. You're starting from zero. The agent writes everything fresh and it looks amazing.

Real projects aren't empty. They have patterns. They have utilities that were written three months ago. They have naming conventions, existing abstractions, and files that already handle the exact thing the agent is about to reinvent. This is especially critical when you're running complex agent rewrites.

Without reading the codebase first, an agent will:

• Create duplicate utility functions
• Ignore existing patterns and invent new ones
• Import libraries that are already wrapped in a local module
• Write code in a directory that doesn't follow your project structure
• Reimplement error handling, logging, or validation that already exists

Every single one of those burns tokens. And every single one of those creates cleanup work for you in the morning.

The pre-check fix

Back in the nightloop.sh days, this was the first real improvement I made to the pipeline. Before the agent implements anything, it gets a separate step: read the codebase and understand what's already there.

Here's what that looked like in the bash script era:

# Pre-check: read before you write
claude -p "Read the following directories: src/lib/, src/utils/, src/types/.
List all existing utility functions, patterns, and conventions.
Then read this task: $TASK
Identify which existing code is relevant to this task.
If utility functions already exist that cover part of the requirement, list them.
Output a brief implementation plan that reuses existing code."

Simple. The agent spends 2-3 minutes reading. Then when it gets to the implementation step, it already knows what's there. It uses the existing error handler instead of writing a new one. It follows the naming pattern it saw in other files. It puts new code in the right directory.

Before and after numbers

I tracked this across 60 pipeline runs before and after adding the pre-check step. Same types of tasks, same model, same projects. Here's what I found:

Without pre-check (30 runs):

• Average tokens per task: ~32,000
• Tasks requiring rework due to duplicated code: 14/30 (47%)
• Average total pipeline tokens for a 10-task batch: ~320,000

With pre-check (30 runs):

• Average tokens per task: ~19,500
• Tasks requiring rework due to duplicated code: 3/30 (10%)
• Average total pipeline tokens for a 10-task batch: ~195,000

That's a 39% reduction in token usage. I round it to 40% because the math is close and it's easier to remember.

The pre-check step itself costs tokens, about 3,000-5,000 per task depending on codebase size. But it pays for itself immediately by preventing the agent from wasting 10,000-15,000 tokens rewriting things that already exist.

Why this works so well

Think about how you work when you join a new codebase. You don't just start writing code in the first file you open. You poke around. You read the existing utilities. You check how other people structured their modules. You look at the test patterns. Then you write code that fits.

The pre-check step makes the agent do exactly that. It's the equivalent of saying "spend 20 minutes reading the codebase before you touch anything."

Without it, the agent is like a contractor who shows up and starts tearing out walls before looking at the blueprints. Sure, they're working fast. But they're also going to rebuild the kitchen that was just renovated last month.

What a good pre-check prompt looks like

Over time I've refined what works best for the pre-check step. Here's the structure I use in Zowl pipelines:

## Pre-check Instructions

1. Read these directories: [list of relevant dirs]
2. Identify:
   - Existing utility functions related to this task
   - Naming conventions for files and functions
   - Error handling patterns
   - Test patterns and test file locations
3. For this task: [task description]
   - List which existing code should be reused
   - List which files will need modification vs creation
   - Flag any conflicts with existing patterns
4. Output a brief implementation plan (5-10 lines)

The key is being specific about what to look for. "Read the codebase" is too vague. "Read src/lib/ and identify existing utility functions related to database queries" tells the agent exactly where to look and what to notice.

The hidden second benefit

Token savings are the obvious win. But there's a subtler benefit that actually matters more in practice: code consistency.

When the agent reads existing patterns before implementing, the new code matches the old code. Same naming. Same error handling. Same structure. You don't end up with a codebase that looks like it was written by five different people (even though it was written by one agent on five different nights).

Before I added pre-check, I'd wake up and spend 30 minutes renaming things and reorganizing imports just to match the project conventions. After pre-check, the code usually fits right in. Still needs review, but the structural rework dropped to almost zero.

The single highest ROI change

I've optimized a lot of things in Zowl pipelines over the past year. Retry strategies, token budgets, prompt templates, validation steps. All of them help. But if someone asked me "what's the one thing I should add to my agent workflow today," it's pre-check. Every time. Managing token budgets and quota constraints becomes much more feasible when pre-check prevents waste.

Read before you write. It's such an obvious idea that it's almost embarrassing it took me weeks to figure it out. But the data backs it up: 40% fewer tokens, 80% fewer duplicate code issues, and mornings that don't start with git reset --hard.

That's worth the extra 3,000 tokens per task. Every single night.