How to Optimize Claude Code Usage and Avoid Hitting Limits

Mar 25, 2026

I stared at the screen in frustration. “You’ve reached your session limit for this period.” Again. I’d been using Claude Code for maybe three hours, and I was already locked out. Meanwhile, I saw Reddit posts from developers working 10-hour days who never hit their limits. What was I doing wrong?

The Discovery

I posted my frustration on r/ClaudeCode and got some surprising responses. One user with a similar workflow said they only used “10-15% of their weekly limit in a day.” Another asked if I was using “optimizations to cut down on codebase reads.”

Optimizations? I didn’t even know that was a thing.

I started digging through the thread and realized my setup was bloated. I had every plugin I could find, a CLAUDE.md file that was 400 lines long, and I was using Opus for everything—including simple file reads. No wonder I was burning through tokens.

Fix 1: Slimming Down CLAUDE.md

My first mistake was obvious. My CLAUDE.md file contained everything: complete API documentation, all project conventions, every file pattern I could think of. It was a reference manual that got loaded into every single session.

# Project Configuration

## Complete API Documentation
[200 lines of API docs...]

## All Project Conventions
[150 lines of conventions...]

## Every File Pattern
[50 lines of patterns...]

I cut it down to essentials only:

# Project: MyApp

## Key Architecture
- Monorepo with apps/ and packages/
- React frontend, Node backend
- PostgreSQL with Prisma ORM

## Essential Conventions
- Max file size: 400 lines
- Test coverage: 80%
- Use TypeScript strict mode

## File Patterns
- `apps/web/src/components/` - React components
- `apps/api/src/routes/` - API endpoints
- `packages/shared/src/` - Shared utilities

## Critical Constraints
- Never commit .env files
- Always validate user input
- Use parameterized queries

The difference was immediate. Each session started faster, and my token usage dropped noticeably.

Fix 2: Model Selection Strategy

I was using Opus for everything. Need to read a file? Opus. Format some JSON? Opus. Write a simple function? Opus. That’s like hiring a senior architect to alphabetize your bookshelf.

I created a simple decision tree:

Task Type → Model Choice

Simple operations (read file, format, quick fix)
  → Use Sonnet (cost-effective)

Routine coding (implement feature, write tests, refactor)
  → Use Sonnet (good balance)

Complex reasoning (architecture decisions, difficult bugs)
  → Use Opus (when you need the power)

Ultrathink mode
  → Use SPARINGLY (massive token overhead)

The key insight: reserve Opus for when Sonnet struggles. I switched to Sonnet for routine tasks and watched my token consumption drop by roughly 40%.

Fix 3: Context Management with `/compact`

I used to let sessions run for hours, accumulating context until Claude started forgetting earlier conversations. Then I discovered /compact.

# Instead of one long session:
Session: 3 hours of work, massive context buildup

# Use compact regularly:
Session: Work for 30-60 minutes
Command: /compact
Result: Context reduced, key information preserved
Continue: Keep working with smaller token overhead

I also started a new pattern: instead of one marathon session, I’d break work into focused sessions with summaries.

Session 1 (Planning):
  "Help me plan the authentication feature"
  Model: Sonnet
  Output: Detailed implementation plan

[Start fresh session]

Session 2 (Implementation):
  "Implement auth following this plan: [paste plan]"
  Model: Sonnet for setup, Opus for tricky parts
  Output: Working implementation

[Start fresh session]

Session 3 (Testing):
  "Write tests for the auth feature"
  Model: Sonnet
  Output: Complete test suite

Each session started clean with just the necessary context, dramatically reducing token overhead.

Fix 4: Plugin Audit

I had installed every plugin that looked interesting. GSD, trailofbits, serenity MCP, plus a handful of others I’d forgotten about. Each one added overhead to every session.

I ran an audit:

Plugin Status Before:
- 7 active plugins
- Unknown token overhead per session
- Some plugins making background calls

Plugin Status After:
- 3 essential plugins (GSD, trailofbits, serenity)
- Reduced startup overhead
- Cleaner session logs

The Reddit thread confirmed this approach. One user with efficient usage mentioned: “All I have is GSD and trailofbits, and serenity mcp.” I cut down to my essentials and disabled everything else.

The Results

After implementing these changes:

Before Optimization:
- Session limits hit frequently
- Weekly usage: 40-50% in a single day
- Long sessions with massive context

After Optimization:
- No session limit issues
- Weekly usage: 10-15% in a day
- Focused, efficient sessions

My productivity didn’t drop—I actually got more done because I wasn’t constantly hitting limits and waiting for resets.

Optimization Checklist

Here’s the checklist I now follow:

CLAUDE.md under 100 lines (currently 60)
Only essential plugins enabled (3 plugins)
Using Sonnet for routine tasks
Compacting context regularly with /compact
Starting fresh sessions for new tasks
Monitoring weekly usage percentage

What I Learned

The problem wasn’t Claude Code’s limits—it was how I was using it. I treated it like an unlimited resource instead of a tool that requires thoughtful management.

The optimization isn’t about doing less work. It’s about removing waste. Bloated context, wrong model choices, unnecessary plugins—these were all adding overhead without adding value.

Now I can work through full days without hitting limits, and I’m more productive because each session is focused and efficient.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!