Writing Lean Prompts That Don't Waste Tokens

Vague Prompts Are Expensive Prompts

Every broad, exploratory prompt triggers broad, exploratory behavior. "Review this codebase" reads dozens of files. "Improve performance" reads architecture files, source files, config files, and tests before settling on an approach. The cost scales with how much Claude has to scan before it can act.

Specific prompts are cheaper and faster. "Add input validation to the login function in src/auth/auth.ts" lets Claude open one file, make one change, and verify it. The difference in token cost between these two prompts is often 10x or more.

Give Claude a Starting Point

The most effective single habit for lean prompts: always name the file when you know it.

• Instead of "fix the auth bug" → "fix the 401 error in the token refresh endpoint in src/auth/auth.ts"
• Instead of "update the tests" → "add a test for the edge case in tests/auth.test.ts where the session token is expired"
• Instead of "look at the database schema" → "check the users table schema in docs/schema.md"

When Claude does not have to search for where to start, it does not read the files it searches through.

Describe Symptoms, Not Labels

When reporting bugs, describe the observable symptom rather than the diagnostic label:

• Less useful: "fix the login bug"
• More useful: "users are getting 401 after session timeout — the token refresh endpoint returns 401 and the session is not renewed"

A label gives Claude no information. A symptom gives Claude a location, a measurable condition, and a verification target — which means fewer exploratory reads before it starts making progress.

Plan Mode Before Implementation

Press Shift+Tab to cycle to plan mode. In plan mode, Claude explores the codebase and proposes an approach for your approval before making any changes. It takes more turns upfront — but it prevents the expensive scenario where implementation starts in the wrong direction and has to be unwound.

A typical plan-then-implement session is cheaper than a two-attempt implement-then-fix session, because the second attempt re-reads most of the same files. Catching a wrong direction in the plan saves at minimum one full implementation cycle.

Course-Correct Early

If Claude starts heading the wrong direction, stop immediately. Do not let it continue implementing an approach you can already see is wrong:

• Press Escape to interrupt the current operation
• Double-tap Escape or use /rewind to restore conversation and code to a previous checkpoint

The cost of a wrong-direction implementation is not just the tokens consumed — it is also the corrective turns that follow, each of which carries the wrong implementation in context. Catching it early eliminates both.

Include Verification Targets

Give Claude something to check its work against: paste the failing test output, describe the expected behavior, include a screenshot of the visual state you want. When Claude can verify its own work, it catches issues before you need to request fixes. Each fix cycle is another round of file reads and tool calls — verification targets reduce the number of cycles.

Test Incrementally

For large tasks, break them into stages and verify each stage before continuing. Write one component, test it, then move to the next. Issues caught early are cheap to fix. Issues caught after five more steps have piled context from all five steps on top of the problem.