LBZ Advisory – AI Execution Playbooks

The problem we are trying to solve

Claude is getting more and more expensive, and many of us are getting “botblocked” sooner and faster than ever before.

Claude 4.7 can do harder coding work with less hand-holding, but that creates a trap: teams let sessions run too long, dump too much into context, and pay for noise instead of progress. The result is not just higher token spend. It is degraded reliability — and faster exhaustion of usage limits.

The real problem is token waste plus context rot.

That usually shows up as:

• repeated corrections
• bloated sessions that keep re-reading dead context
• expensive vision inputs that were bigger than necessary
• overuse of Opus for work a cheaper model could handle
• weak prompts that trigger exploration instead of execution
• missing verification, which forces multiple cleanup turns
• poor handoffs, which make every fresh session rebuild context from scratch

This playbook is designed to solve that. The goal is to make Claude need less context, do less unnecessary work, verify more of its own output, and hand off state cleanly so tokens buy real progress instead of repetition — ultimately stretching your usage limits and reducing how often you hit the bot block wall.

What Options Do You Have?

This guide separates three kinds of advice:

• Anthropic-confirmed: documented behavior or guidance from Anthropic
• Strong operator practice: patterns repeated by experienced Claude Code users and consistent with the docs
• Heuristics: useful rules of thumb, but not something to treat as physics

That distinction matters since so much sloppy advice gets repeated online as fact.

1. The real token problem

Yes Claude 4.7 can use more tokens. And what’s worse is that your long, expensive sessions usually degrade over time while costing you more.

Long threads accumulate:

• old instructions
• command output
• file contents
• screenshots
• incorrect turns you had to fix
• duplicate explanations

That creates two costs at once: higher spend and lower reliability, which accelerates hitting hard usage limits and triggers bot blocking.

Core rule: the cheapest session is not the shortest one. It is the one with the least irrelevant context and the fewest repeated corrections.

2. Anthropic-confirmed controls

These are the controls Anthropic documents and you should treat them as baseline discipline, not optional polish.

Effort
Claude 4.7 uses an effort setting that trades off thoroughness against token use. Anthropic says Opus 4.7 adds an xhigh tier and that in Claude Code the default effort for Opus 4.7 was raised to xhigh for all plans. Anthropic recommends starting with high or xhigh for coding and agentic work, then adjusting based on the task.

Practical guidance:

• use lighter effort for routine, obvious tasks
• use higher effort for architecture, tricky debugging, or review
• do not assume the highest setting is best
• if Claude starts over-analyzing easy work, reduce effort or narrow the prompt

Context management commands
Use these on purpose. Anthropic explicitly documents /clear, /compact, /cost, /rename, /resume, and /btw as practical controls for cost and session hygiene.

Use these on purpose:

• /clear to start fresh between unrelated tasks
• /compact to compress session context when a thread is getting bloated
• /context to inspect what is being sent
• /cost to watch usage instead of guessing
• /resume and /rename to manage sessions cleanly
• /btw for side questions that should not enter history

Memory loading
Keep CLAUDE.md lean. I made mine a bit too long and heavy, apparently.

Anthropic documents that root and parent CLAUDE.md files are loaded in full at launch, while subdirectory files load on demand when Claude works in those folders. Anthropic also now recommends .claude/rules/ for modular instructions, with path-scoped rules loading only when matching files are being worked on. That is one of the cleanest ways to cut baseline context while keeping guidance specific.

Auto memory
Claude Code also supports auto memory through MEMORY.md. Use it for compact durable facts, not for dumping every thought the agent ever had. Keep it small and stable.

Verification
Anthropic is clear on this: Claude performs better when it can verify its own work. That means tests, screenshots, expected outputs, lint, typecheck, or other concrete checks. Verification saves tokens because it reduces the number of corrective loops later. Anthropic also introduced /ultrareview in Claude Code as a dedicated review session for finding bugs and design issues in changes before merge.

3. Strong operator practice

These are not all formal Anthropic rules, but they line up with the docs and show up repeatedly in experienced-user workflows.

The anti-rot protocol
This is the core operating pattern for keeping token spend from turning into reliability loss (and faster bot blocking).

Do not let your correct chat session become the memory system.
Use files for durable state:

• CLAUDE.md for stable repo rules and commands
• PROGRESS.md for current state
• ARCHITECTURE.md for enduring technical decisions
• TODO.md for prioritized next steps
• HANDOFF.md for fresh-session continuation

The chat should hold the task. The repo should hold the project memory.

Fresh sessions beat heroic memory
Once a session is bloated, you usually do better by resetting than by arguing with it.

A good reset pattern:

1. ask Claude to update PROGRESS.md, TODO.md, HANDOFF.md, and any architecture notes
2. require exact file paths and current status
3. start a fresh session
4. seed the new session with the handoff, not the whole prior conversation

Use subagents instead of one god-agent
Push noisy work into subagents or specialized review flows.
Good subagent jobs: scouting the codebase, finding relevant files, digging through logs, regression review, design critique, issue triage.
The main implementation thread should stay focused.

Use the cheaper model for scouting
Do not spend premium tokens on tasks that are basically search.
A practical split:

• cheaper model or lightweight subagent for file discovery and low-risk inspection
• Sonnet for most implementation work
• Opus for harder architecture, nasty debugging, synthesis, or high-stakes review

Bundle coherent work, not random work
Good bundle: fix the landing page hero brightness, verify locally, run checks, merge and deploy, update docs, perform final design audit.
Bad bundle: fix hero brightness + rewrite pricing strategy + refactor backend + draft launch copy.
One coherent work packet is efficient. A random pile is not.

4. Heuristics that are useful if you treat them like heuristics

The 20 to 40 message rule
This is a decent warning sign, not a law.
If a thread has gone 20 to 40 meaningful turns, touched a lot of files, and accumulated logs or screenshots, assume performance may be slipping and costs may be compounding. Treat it as a trigger for judgment.

Reset sooner when:

• Claude repeats itself
• you have corrected it twice already
• the task changed categories
• it is hauling around logs from an old debugging branch
• /context shows a lot of dead weight

Context size thresholds
Even with a large context window, retrieval quality still degrades when too much irrelevant material is present. If /context shows lots of old logs, screenshots, dead branches of reasoning, or files that no longer matter, reset before they become a tax on every turn.

Question bundling
Bundle related questions into one message when they truly share the same context. Do not abuse this — bundling unrelated asks often makes Claude roam too widely and spend more.

Project-level file reuse
For recurring specs, PDFs, and reference docs, keep them in project memory or stable repo docs where possible instead of repasting them into chat repeatedly.

Ignore and exclude discipline
Use .claudeignore, scoped rules, and local exclusions to keep irrelevant files out of Claude’s working set.

Tokenizer awareness
Treat model upgrades as a reason to re-benchmark cost assumptions. Do not carry forward old spend estimates without measuring.

5. Vision is a silent token burn

Claude 4.7 can handle higher-resolution images than earlier models. That is great for UI work and bad for careless uploads.

Default image discipline:

• crop first
• then resize
• only send full-page screenshots when layout hierarchy matters
• only send full resolution when tiny text or exact pixel issues matter

A good default for UI review: long edge around 1400 to 1800 px, JPG or WebP at medium-high quality.

How to downsample screenshots

Mac Preview: open the image → Tools → Adjust Size → set the long edge to around 1600 px → export as JPEG.

Windows: open in Photos or Paint → resize by pixels → set long edge to around 1600 px → save as JPG.

ImageMagick: magick input.png -resize 1600x1600\> -quality 82 output.jpg

6. Prompt structure that saves tokens

Claude responds better to structured prompts than vague, chatty requests.
Use boundaries like: , , , , .
Do this because it reduces ambiguity, not because XML is magic.

Good prompt pattern (example): Fix the remaining hero form visual issue, verify locally, merge and deploy, run checks, update handoff docs, and perform a final design audit. Keep scope tight. No unrelated refactors. Use subagents for exploration or review. - identify root cause - fix the issue - rebuild and verify locally - run build, lint, typecheck, and relevant tests - validate the landing page and results flow - update PROGRESS.md, ARCHITECTURE.md, TODO.md, HANDOFF.md - return files changed, checks run, merge status, deploy status, and design critique

Planning bloat is real
Do not ask for a giant plan unless the task genuinely needs one. Planning wastes tokens when the fix is obvious or the files are already known.

7. Verification is the highest-leverage token saver

The reason sessions spiral (and burn through limits) is not usually the first implementation. It is the five follow-up prompts needed because nobody forced verification.

Require proof in the same prompt: build status, lint result, typecheck result, relevant tests, UI validation if applicable, regression review, exact files changed.
Do not accept “done” without evidence.

8. Use handoffs to reset cleanly

When closing a session, ask Claude to prepare the repo for a new agent by updating PROGRESS.md, ARCHITECTURE.md, TODO.md, and HANDOFF.md.

Fresh-session handoff template Goal: [end state] Completed: [files changed and logic verified] Open issues: [bugs, weak spots, design debt] Deploy status: [local only / merged / deployed] Next step: [single next atomic task] Files to read first: [2 to 5 exact paths] Commands to know: [build, test, run, deploy]

9. A practical operating loop

For a real coding project, the clean loop is:

1. define one coherent work packet
2. keep the prompt structured
3. require implementation plus validation plus handoff in the same prompt
4. use subagents for noisy work
5. update repo docs before stopping
6. reset after meaningful milestones
7. seed the next session with the handoff only

10. When to start fresh

Start a fresh session when:

• Claude is repeating itself
• the task category changed
• you have corrected the same issue more than twice
• the session is dragging around logs, screenshots, or outdated assumptions
• you need a clean final review
• /context shows a lot of irrelevant material

11. What people get wrong

• Wrong: more context is always better → It often makes the model worse.
• Wrong: one giant prompt is always cheaper → Only if the work is tightly related.
• Wrong: root CLAUDE.md should contain everything → No. It should contain only what every session truly needs.
• Wrong: I can ask for tests later → That usually costs extra and often gets skipped.
• Wrong: every screenshot should be full resolution → Usually false.
• Wrong: the highest effort setting always gives the best answer → It often just spends more tokens.

12. Pre-merge review workflow

This is where cost control and quality control meet.
A stronger workflow: implementation pass → local validation → review pass → deeper review for substantial changes → design audit if the work touches UI → final handoff update.
Use /review during development and /ultrareview before merging larger or riskier changes.

13. What I would not state as fact

A few claims circulate heavily but should not be presented as settled truth unless you have your own benchmarks (e.g., a fixed universal token inflation multiplier, a hard context-size breakpoint, XML having special magic, or one mega-prompt always being cheaper). These can be directionally useful. They are not laws.

Final rule
Your goal is not to make Claude remember more. Your goal is to make Claude need to remember less.

What’s your biggest token waster or fastest path to bot blocking right now with Claude 4.7?
Share your reset triggers, handoff tweaks, vision habits, or before/after usage stories in the comments.

If your teams are burning limits too quickly and you want this playbook customized into an organization-wide system, book a call.

Book a Call
Subscribe for more AI Execution Playbooks

Part of the LBZ AI Execution Playbook series.