Claude Code for WordPress: How I Cut My Token Usage by 37%

I run Claude Code all day. Two Max plans for regular coding work plus API tokens for site integrations, it is a meaningful part of my monthly infrastructure cost. When my Claude bill hit $160, I decided to actually look at where the tokens were going instead of assuming the spend was justified.

The breakdown was surprising. 37% was overhead, not complex tasks, not long reasoning chains, just inefficient habits I had settled into without thinking about them. The fixes were not complicated. They took about a week to make habitual, and the savings have held consistently since.

Everything here is specific to WordPress plugin development. Generic token optimization advice misses the patterns that make WordPress work expensive in particular.

What Makes WordPress Development Token-Expensive

A few patterns are responsible for most of the waste.

Warm-up cost on every conversation. Every session I was explaining the same plugin: this is a BuddyPress plugin, the main file is buddypress-hashtags.php, the classes are in includes/, the admin is in admin/. That is 300-500 tokens before any actual work happens, repeated across dozens of sessions per week.

Pasting entire files for single-function questions. WordPress class files run 400-600 lines. When a bug is in one function, there is no reason to paste the entire class. A 500-line file is about 1,500 tokens of context before Claude starts reasoning.

Asking Claude to do what phpcs already does. I was regularly asking Claude to check code against WordPress Coding Standards. phpcs runs in two seconds and reports exact line numbers. Claude doing the same analysis costs ten times as much and is less precise.

Unspecified output format. Without instructions on what kind of response to produce, Claude defaults to thorough and explanatory. For implementation tasks, that means hundreds of extra tokens per response explaining decisions you can already see in the code.

Fix 1: CLAUDE.md Files Per Plugin

This was the single biggest change. A CLAUDE.md at the root of each plugin repository tells Claude everything it needs to know before I say anything. No warm-up required.

# BuddyPress Hashtags

## Architecture
1. Save layer, parses hashtags on bp_activity_posted, stores as meta _bp_hashtag
2. Display layer, replaces #hashtag with link at render time
3. Search layer, REST endpoint /wp-json/bp-hashtags/v1/search

## Key Files
- includes/class-hashtag-parser.php, regex, sanitization
- includes/class-activity-hooks.php, all BP hook registrations
- public/js/autocomplete.js, vanilla JS, no jQuery

## Gotchas
- BP content double-filtered in some themes, hashtag links can appear twice
- Autocomplete fires on input not keyup, important for mobile touch
- # in URLs must be encoded as %23 in REST queries

## Response Rules
- Return only the changed function/section, not the full file
- No explanation unless I ask for it
- No suggestions outside the scope of what I asked
- No docblocks added to code I did not ask you to touch
- No jQuery suggestions, vanilla JS codebase

The Response Rules section is the part most developers skip. It is behavioral configuration, it prevents the default verbose output on every response. Those four constraints alone cut my average response length by 40% on implementation tasks.

Warm-up cost drops from 800-1,200 tokens per conversation to around 200 tokens to read the CLAUDE.md. For someone running multiple Claude sessions per day across 100+ plugins, this compounds significantly.

Fix 2: Send Functions, Not Files

When I need help with a specific function, I send the function, not the file it lives in.

Before (1,400 tokens of context):

Here is class-hashtag-parser.php [pastes 500 lines].
The parse_hashtags() function does not match Unicode hashtags.

After (80 tokens of context):

In class-hashtag-parser.php, parse_hashtags() uses: /#([a-zA-Z0-9_]+)/
Does not match Unicode like #hashtag in Hindi or Greek.
Fix the regex to support Unicode word characters with the u flag.
Keep the function signature unchanged.

For bug reports I follow a consistent template: file name, function name and approximate line, one-sentence problem description, current behavior, expected behavior, and only the specific function pasted, 20-50 lines at most. That structure delivers everything Claude needs in under 200 tokens.

Fix 3: Run phpcs Yourself, Show Claude Only the Errors

I enforce WordPress Coding Standards on every project with pre-commit hooks that block commits on WPCS errors. This means I never ask Claude to check standards, the hook does it automatically and reports exact errors.

vendor/bin/phpcs --standard=WordPress includes/class-hashtag-parser.php

FOUND 3 ERRORS
 45 | Missing comment for class variable $hashtag_regex
 89 | Expected 1 space after comma
127 | Spaces must be used to indent; tabs not allowed

Then:

Fix these three WPCS errors in class-hashtag-parser.php:
- Line 45: add class variable docblock
- Line 89: fix spacing after comma
- Line 127: convert tab to spaces

Token cost for coding standards work drops about 70%. The pre-commit hook setup takes 30 minutes once and eliminates this category of request entirely.

Fix 4: Batch Related Tasks

Every new conversation pays a fixed context establishment cost. Structure work to minimize how often you pay it.

Three things in buddypress-hashtags today:

1. Fix Unicode regex in class-hashtag-parser.php (function below)
2. Add filter hook bp_hashtags_before_save before saving
3. Update REST endpoint to accept lang parameter

Do them in order, wait for my review after each one.

One context load. Three tasks done. The “wait for review” instruction prevents Claude from running ahead if task 1 needs discussion before proceeding.

Fix 5: Specify Output Format Explicitly

“Return only the modified function, no explanation needed” is in the CLAUDE.md Response Rules for every plugin I work on. It is also the most single useful instruction I have added to my workflow.

Without it, a request to add transient caching to a function produces: explanation of why transients work, three different approaches with trade-offs, code for the chosen approach, explanation of the code, suggestions for further optimization. Roughly 1,200 tokens of output.

With “return only the modified function, no explanation needed”: the modified function. Around 200 tokens. When I want an explanation, I ask for it explicitly.

Fix 6: Fresh Conversations Per Discrete Issue

Long conversations get progressively more expensive. As the context window fills with prior exchanges, each new response costs more because Claude maintains awareness of the entire conversation history. A 40-exchange debugging session has meaningfully higher per-turn cost at exchange 35 than at exchange 5.

My practice: one issue per conversation. When the fix is done and the PR is open, start fresh for the next issue. The reset takes seconds. The savings over a full working day are real.

Fix 7: Weekly Maintenance Cleanup

Claude Code generates debug logs, shell snapshots, and stale session files as part of normal operation. Left uncleaned, these slow down session startup and pollute the memory system with outdated context.

I run a weekly cleanup that covers Claude debug logs, old todo files, stale memory entries, and temp files in the projects directory. It takes five minutes. Without it, the session overhead creeps up over weeks and the memory system starts surfacing context that was relevant a month ago but is now misleading, like a WordPress database that has not been optimized in years.

This is maintenance, not optimization. It keeps the baseline clean so the other efficiency gains hold.

The Numbers

Session type	Before	After
Debugging session	8,400 tokens avg	4,200 tokens avg
Feature implementation	12,000 tokens avg	7,800 tokens avg
Code review	5,200 tokens avg	2,100 tokens avg
Monthly spend	$160	$101

CLAUDE.md files alone accounted for roughly 18% of the total reduction, the single biggest lever. Scoping requests to functions rather than files was another 12%. The remaining 7% came from output format constraints, task batching, and session discipline.

What I Still Spend Tokens on Deliberately

Not everything should be optimized down.

Full codebase analysis before major features. When adding something significant that touches many parts of a plugin, I load the entire plugin and let Claude map all the dependencies first. More expensive upfront, but it prevents bugs from interactions I did not think to check.

Pre-release security audits. Full plugin, all files, structured security review covering input sanitization, nonce verification, SQL injection via wpdb, and capability checks. I run this before every major release.

Cross-plugin compatibility checks. With 100+ plugins, conflicts happen. When I suspect an interaction issue, I load both plugins and ask Claude to map all shared hooks and data stores. This is where the 1M context window becomes genuinely useful, I covered that in a separate post on this site.

The goal is not minimum token spend. It is spending tokens where AI reasoning adds value, on complex interactions, architectural decisions, security analysis, and eliminating overhead where it does not.