You don’t have a token problem. You have a model allocation problem.
Most teams try to reduce tokens with prompt tricks. But the real cost driver is which model you use for each task.
The same workflow can cost 10-100x more depending on model selection.
This playbook shows you how to:
Most teams start with chat and stay well within limits, then move to coding tools and hit limits unexpectedly fast.
Why it matters: this is usually a workflow design issue, not just "too much usage."
Example: load a large repo, ask for a broad fix, retry three times, and resend most of the same context each cycle.
Takeaway: token control starts with workflow control.
Token usage = Context Size x Iteration Count.
This formula is the operational model behind nearly every limit incident.
Numerical example: Loading a full repo (200k tokens) and iterating 10 times burns ~2M tokens.
Token Explosion Loop
Repeated loops plus large context create compounding token growth.
Choose the right mode before you spend tokens: use chat for thinking, code tools for execution.
Use chat to explore ambiguity, frame the problem, and design solution options before execution.
When to use
Example: "Design a contract extraction pipeline with fallback logic"
Why it matters: planning in a low-cost mode prevents expensive execution retries.
Use code mode for precise execution, targeted changes, and validating outcomes against clear criteria.
When to use
Example: "Update M2 classification logic to include FX fee detection"
Why it matters: code tools multiply cost when prompts are broad or iterative.
Chat (Fast Path)
Coding (Full Execution Path)
| Dimension | Chat | Code |
|---|---|---|
| Primary intent | Explore and plan | Execute changes |
| Typical token pattern | Lower, shorter turns | High token usage with loops |
| Best input style | Open framing | Scoped, explicit constraints |
Takeaway: Chat helps you choose the right path. Code mode should run that path with tight scope and fewer retries.
Token burn is usually caused by a few repeated workflow patterns, not one bad prompt.
These mistakes are common because they feel productive in the moment.
Takeaway: every mistake above increases either context size or iteration count.
This is the recommended operating model for teams that want predictable cost and speed.
Why it matters: each step directly cuts either baseline context cost or retry count.
Example: define target files and acceptance tests in chat, then run one scoped execution pass in the code tool.
A structured before/after view makes the optimization practical and repeatable.
Inefficient workflow
Token usage: ~200k per cycle
Optimized workflow
Token usage: ~15k-40k per cycle
| Phase | Before | After |
|---|---|---|
| Context scope | full repo loaded by default | only impacted files + interfaces |
| Execution style | explore + patch in one loop | plan first, then scoped execution |
| Token usage | ~200k per cycle | ~15k-40k per cycle |
What changed: context was narrowed, retries were reduced, and validation became stage-specific.
Takeaway: most savings come from removing duplicate context-heavy loops, not from shorter wording.
Most teams route every task through one powerful model. That feels simple, but it is expensive and inefficient at scale.
High-performance workflows separate thinking, execution, and bulk processing. Use intelligence where it matters. Use cheaper models everywhere else.
High intelligence, use sparingly.
Purpose: high-quality reasoning and decision framing.
When to use: problem framing, architecture design, prompt design, complex reasoning, output review.
Example: "Design a multi-stage contract intelligence pipeline with fallback extraction rules, confidence thresholds, and validation gates."
Model examples:
Note: used sparingly, but critically important.
Primary execution layer.
Purpose: the main working layer for production tasks.
When to use: applying changes, structured extraction, transformations, coding tasks, deterministic workflows.
Example: "Extract pricing clauses, normalize fee fields into a JSON schema, and generate deterministic patch updates for downstream services."
Model examples:
Note: this is where most tokens should be spent.
Low-cost scaling layer.
Purpose: high-volume, low-risk throughput work.
When to use: filtering documents, preprocessing, repetitive agent steps, retrieval prep, batch processing.
Example: "Filter 50,000 incoming contracts, drop irrelevant records, and route only high-signal documents into the Tier 2 extraction workflow."
Model examples:
Note: built for scale, not deep intelligence.
Tiered Workflow Flow
Step 1: design with Tier 1. Step 2: execute with Tier 2. Step 3: scale repetitive work with Tier 3.
Use Tier 1 for everything
Use a tiered workflow
Final takeaway: Token optimization is not about using fewer tokens. It is about using the right model at the right stage.
This section is your practical toolkit for reducing repetitive prompt load in Claude workflows.
Why it matters: persistent instructions and targeted tool access reduce both prompt size and retries across sessions.
Example use case: compliance-heavy repo with strict output format and test gates.
Takeaway: place stable project rules in CLAUDE.md, not in every prompt.
Example use case: a review skill that always returns findings by severity with remediation steps.
Takeaway: use Skills for repeated task patterns that need consistent structure.
Example use case: pull only relevant error traces and schema rows for the current task.
Takeaway: use MCP when data access is the bottleneck, not prompt writing.
| Dimension | Skills | MCP |
|---|---|---|
| Purpose | reusable task logic | external access |
| Token impact | reduces repetition | reduces context |
| Best for | repeated tasks | large data |
| Not for | data retrieval | task logic |
Skills define HOW Claude works. MCP defines WHAT Claude can access.
Use this before long sessions to keep token spend predictable.
LLM efficiency is mostly workflow design, not wordsmithing.
High-performing teams spend less time trimming prompts and more time controlling context scope, iteration count, and execution sequencing.