Claude Sonnet 3.5 Optimization: What Actually Works

Claude's context window sounds great until you actually try using it. Just because you can dump your entire codebase doesn't mean you should.

Tried loading like 600K tokens of some old Java mess once. Took forever to respond and the suggestions were shit because Claude couldn't figure out what was actually relevant. Classic case of more != better.

What Actually Works for Context Management

Stop overthinking this shit. Here's what works:

• Keep your system prompt short - anything over like 8K tokens and Claude starts ignoring half of it
• Only load files you're actually editing - I know you want to dump everything "just in case" but resist the urge
• Leave room for thinking tokens - if you max out context, extended thinking throws some useless CONTEXT_TOO_LONG error

Somewhere around 100-150K tokens works for most stuff. More than that and you're wasting time and money on worse results.

Extended Thinking: When It's Worth the Cost

Extended thinking costs extra but it's not magic. When I use it:

• Production fires where being wrong costs more than the API bill
• Architecture stuff that affects the whole team
• Security reviews where I need to be really sure

For normal dev work? Skip it. Made the mistake of using "think harder" for every little bug fix and watched my bill explode. Each extended thinking response adds a bunch of tokens and it adds up quick if you're not careful.

Real Problems You'll Hit

Problem 1: Context gets polluted with old conversation junk
Claude remembers that huge error stacktrace from 3 tasks ago. Hit /clear between major tasks or your context fills up with useless shit.

Problem 2: Extended thinking fails when context is full
"think harder" just errors out with CONTEXT_TOO_LONG instead of doing something useful. Super annoying.

Problem 3: Everything slows to a crawl during work hours
Claude gets sluggish 9-6 Pacific when everyone's using it. Response times go from "fine" to "did this thing break?" Try working earlier or later if you can.

Git Worktrees for Parallel Development

This actually works for keeping Claude focused:

git worktree add ../feature-auth feature/auth
git worktree add ../feature-api feature/api

## Run separate Claude sessions
cd ../feature-auth
## Auth work here

cd ../feature-api  
## API work here

Each worktree is isolated so Claude doesn't get confused about what codebase you're working on. Without this, Claude tries to "help" with auth code when you're asking about API stuff, which is useless. Took me way too long to figure out this was even a thing.

Cost Optimization That Actually Saves Money

Model switching saves money if you're not lazy about it:

1. Haiku for simple stuff - code formatting, docs, basic refactoring
2. Sonnet 3.5 for most dev work - best bang for buck
3. Opus only when Sonnet shits the bed - which isn't often

Cut my monthly bill roughly in half by actually thinking about which model to use instead of defaulting to the expensive one. Sonnet handles most coding tasks fine and costs way less than Opus. Only real difference is Opus sounds fancier when it's wrong.

The Truth About Those Benchmark Numbers

Those benchmark numbers are pretty meaningless for actual work. They test on clean, simple coding problems, not the mess of legacy code and weird business logic you're probably dealing with.

In practice, Claude is decent at:

• Writing boilerplate
• Explaining existing code
• Basic debugging if you give it good error messages
• Simple refactoring

It's shit at:

• Figuring out what you want from vague descriptions
• New frameworks it hasn't seen much of
• Domain-specific business logic

Don't expect miracles. It's a useful tool but it's not replacing developers anytime soon. The benchmarks look impressive but real performance varies wildly depending on what kind of code you're working with.

Batch Processing Without Breaking the Bank

I do code reviews by batching 3-5 files together instead of loading them one by one. Costs way less in API calls:

## Instead of this:
## claude review file1.py
## claude review file2.py  
## claude review file3.py

## Do this:
## claude review file1.py file2.py file3.py

Claude keeps context between files and catches issues that span multiple files. Saves money and actually works better. I tried doing files individually for a while and my bill went up for worse results.

Multi-Model Workflows That Save Money

Here's what I do:

1. Haiku for simple stuff: Code formatting, docs, basic refactoring
2. Sonnet 3.5 for development: Bug fixes, features, code reviews
3. Opus only when Sonnet fails: Complex architecture stuff, when I'm really stuck

Cut my monthly bill roughly in half. The trick is not defaulting to the expensive model for everything. Used to just use Opus for everything because "why not use the best" and burned through money fast. Self-control actually matters here.

Context Management for Real Projects

Forget all that "hierarchical context loading" bullshit from Medium articles. Here's what actually works:

For bug fixes: Load the failing file + maybe relevant test files. Don't go crazy.

For features: Load the files you're changing + what they depend on. Keep it reasonable.

For refactoring: You might load more context, but expect slow responses.

Don't dump your entire codebase. Tried this with a big React app once and waited forever for shitty responses. More context doesn't mean better results, especially past a certain point.

Git Worktrees: Actually Works

Multiple Claude sessions on isolated branches prevents context pollution:

git worktree add ../feature-auth feature/user-auth
git worktree add ../feature-api feature/api-rewrite

## Separate Claude sessions
cd ../feature-auth
## Auth work without API confusion

cd ../feature-api  
## API work without auth confusion

Stops Claude from mixing up your features. Without this, Claude tries to "help" with auth when you're asking about API stuff, which is useless. Saved me a lot of frustration.

Prompt Caching: Actually Saves Money

When it works. I cache:

• System prompts with coding standards
• Project context and architecture overview
• Common code patterns and style guides

Cache dies after 5 minutes of inactivity, so only helps when you're actively working. Still saves a decent amount. But step away for coffee and you're back to paying full price. The expiration is pretty aggressive.

Performance Optimization Debugging

Claude is decent at obvious performance issues but misses subtle stuff:

Good at:

• N+1 query problems
• Inefficient loops and data structures
• Memory leaks from unclosed resources

Bad at:

• Cache invalidation problems
• Network bottlenecks
• Complex database optimization

I use it for the obvious stuff first, then dig into real problems myself. It catches amateur mistakes but misses the weird edge cases that actually kill performance. Still useful as a first pass.

Error Analysis with Large Context

Stack traces + relevant code + config works well for debugging. Don't load debug logs from multiple days - Claude gets lost.

Structure it:

1. Current error (stack trace, error message)
2. Relevant code files (not everything)
3. Recent changes (git diff)
4. Config files (if relevant)

This helped me debug some connection pooling issue that had stumped multiple people for days. Turned out to be a timeout setting in environment variables. One of those "seriously?" moments. Would've been faster to check the docs first.

Quality Gates and Code Review

I have Claude do a first pass before human review:

1. Claude reviews for basic errors, code style, obvious security issues
2. Human review for business logic, architecture, edge cases

Catches maybe half the shit that would waste my colleagues' time. The rest still needs human brains, especially for business logic. Tried letting Claude handle all reviews for a while and it approved something that would've crashed production.

Lesson: Use Claude to filter obvious mistakes so humans can focus on stuff that actually matters. Claude catches facepalm errors, humans catch the subtle "how did this work in dev" problems.