The Precision Principle
Every word in your prompt that does not help the model produce a better answer is a wasted token. But precision is not the same as brevity - a precise prompt may be longer if the extra words eliminate ambiguity and prevent the model from making wrong assumptions.
The goal is signal density: every token in your prompt carries useful information. Noise tokens (pleasantries, repetition, vague instructions) increase cost without improving output.
Verbose Anti-patterns
These common patterns inflate token usage without adding value:
# Anti-pattern 1: Pleasantries
"Could you please kindly help me with something? I was wondering if you could
take a look at my code and perhaps explain what it does?"
-> 32 tokens for what should be "Explain what login() does" (5 tokens)
# Anti-pattern 2: Re-explaining known context
"As you know, this is a PHP application with a MySQL database. The code uses
PDO as we discussed. Given all of that..."
-> The agent already has this in CLAUDE.md. This is 35 wasted tokens.
# Anti-pattern 3: Open-ended output
"Can you explain this entire codebase to me in detail?"
-> Invites a 5,000-token essay. Never ask for unlimited output.
# Anti-pattern 4: Pasting whole files for one function
"Here is the entire 400-line UserModel.php, I need you to fix the
getUserById() function on line 67..."
-> Send lines 60-80 only. Saves 3,000+ tokens.
# Anti-pattern 5: Asking for alternatives you won't use
"Show me 5 different ways to implement this, then pick the best one"
-> You end up paying for 4 implementations you discard. Ask for the best one directly.Surgical Prompt Patterns
# Vague (expensive):
"Look at my auth code and see if there are any issues."
# Precise (cheap):
"In AuthController.php:45-80 (the login() method), why does the
session_regenerate_id() call fail when $remember_me is true?"
---
# Vague:
"Help me add a feature to allow users to upload photos."
# Precise:
"Add a file upload field to /templates/profile/edit.php.
Validate: JPG/PNG only, max 2MB. Save to /storage/uploads/avatars/
via the existing FileUploadService::store() method. Return the path."
---
# Vague:
"Fix the bug."
# Precise:
"The test UserTest::testFindByEmail() fails with 'Column not found: email_address'.
The column is named email in the users table (schema in /config/schema.sql:12).
Fix the query in UserModel::findByEmail() only."The precise versions tell the agent: where to look (file + line), what the constraint is (the failing test, the error), and what to change (which function, what output). The agent can act immediately without reading 10 files to orient itself.
Shaping the Output
You have full control over the output format. Using it reduces output tokens significantly:
| Instead of... | Say... | Token saving |
|---|---|---|
| "Explain this function" | "In one sentence, what does getUserById() return?" | ~80% |
| "Review this code" | "List only actual bugs, no style suggestions" | ~60% |
| "Rewrite this class" | "Show only the changed methods as a unified diff" | ~70% |
| "Generate tests" | "Write one PHPUnit test for the edge case where $id is null" | ~75% |
| "Refactor this file" | "Extract the email validation logic in lines 34-52 to a private method" | ~65% |
Ask for Diffs Not Rewrites
This is the single highest-leverage output-shaping technique. When the agent rewrites an entire file, every unchanged line costs output tokens. A diff shows only what changed.
# Scenario: fix one bug in a 200-line PHP file
# Full rewrite approach:
Output: 200 lines * ~10 tokens/line = ~2,000 output tokens
Cost: 2,000 * $15/M = $0.030 per fix
# Diff approach:
"Only show the changed lines and their immediate context (3 lines before/after)"
Output: ~30 lines = ~300 output tokens
Cost: 300 * $15/M = $0.0045 per fix (7x cheaper)
# In practice, tell the agent:
"Show me the fix as a diff. Only include changed lines
with 2 lines of context. Do not rewrite the full file."If you use the Anthropic API and apply diffs programmatically, ask for unified diff format (--- a/file +++ b/file @@ ... @@). It is compact and can be applied with standard patch tools. For interactive use in Claude Code, a markdown code block showing just the changed function is usually clearest.
Reusable Prompt Templates
Templates give you a consistent, tested format for common coding tasks. Build a personal library:
# Bug fix template
"Bug: [one-line description]
File: [path:lines]
Error: [exact error message]
Fix: change [function/variable] to [expected behavior].
Output: diff of changed lines only."
# Code review template
"Review [file:lines].
Report only: logic bugs, security issues, and N+1 queries.
Skip: style, naming, refactoring suggestions.
Format: bullet list, one line per issue."
# Feature add template
"Add [feature name] to [file].
Constraints: [list non-negotiables]
Use: [existing service/helper to leverage]
Output: only new/changed code, not full file."
# Test generation template
"Write one PHPUnit test for [ClassName::methodName()].
Test the edge case: [specific case].
Use the existing test setup in [TestFile.php].
Output: the test method only."