Quick wins and what's possible

Before we go deeper into how Claude Code works under the hood, here are eight things you can do today that most users only stumble onto weeks or months in. None of them needs configuration, and each one lifts your results right away.

The quick wins

Let me break each one down.

1. Let auto-routing pick the model, escalate to Opus max for cognitive load

Claude Code gives you access to multiple models (Haiku, Sonnet, Opus) at multiple effort levels. The old advice, the one I used to give, was "pin Opus at max effort and never think about it again." That advice is now outdated.

Two things changed. Haiku 4.5 closed most of the quality gap with Sonnet on routine work. And Claude Code shipped auto-routing. It reads the task in front of it and picks the right tier. Cheap models for cheap turns, the heavy ones when the task earns it. Forcing Opus everywhere now means burning money and rate-limits on tasks that did not need it.

So the default is simple: leave auto-routing on. Do not pin a model. Let the harness do its job.

The escalation is the rule that matters. When you feel the cognitive load yourself (you are writing a spec, you are making an architectural call, you are debugging something that has resisted two attempts) that is when you reach for /effort max. That command bumps the active model up to maximum reasoning depth for the next turn. Use it like a gear shift, not like a setting.

/effort max

You can confirm the routing is doing what you expect at any point with /model to see the current tier. If you want the 1 million token context window, opt in once via the model selector ([1m] suffix on Opus) and stay opted in for the session.

On the Pro plan ($20/month), Opus usage has rate limits. The Max plan ($100-200/month) gives significantly more headroom. On the API, Opus is the most expensive tier. Auto-routing protects you from those limits by default; max-effort escalation costs you the credits it actually uses.

2. Drop into Plan Mode for slow-down moments

Plan Mode (Shift+Tab twice) used to be the recommendation for "anything non-trivial." That was the right advice when autonomy was the opt-in. It is now the wrong advice, because autonomy is the default.

The Cherny "autonomy dial" framing (which Anthropic now treats as canonical) flips the question. The dial sits at "let Claude run" by default. Plan Mode is the opt-in escape: you drop into it when you want to slow down before the agent touches your code.

So the new question is not "is this non-trivial enough to plan?" The new question is "do I want Claude moving freely here, or do I want to read a plan first?"

Concretely, drop into Plan Mode when:

• The change is high-stakes and undoing it would be painful (a migration, a refactor that touches a lot of files, anything in production-adjacent code)
• The scope is unclear and you suspect Claude might solve the wrong problem
• You are debugging and you want to see Claude's hypothesis before it starts editing
• You are working in unfamiliar code and you want a guided tour before the changes start

Otherwise, leave autonomy on. Small edits, follow-ups inside a thread you have already framed, simple feature work in code Claude already understands. Those do not need plan mode. They were never the bottleneck.

3. Run /init for your CLAUDE.md

CLAUDE.md is a file Claude reads at the start of every session. It contains your project's build commands, code style rules, testing instructions, and architectural decisions. It is the single most important configuration file in Claude Code.

You do not have to write it from scratch. Run /init and Claude analyzes your project (build system, test framework, code patterns) and generates a CLAUDE.md for you. It is 80% right on the first pass. Tweak the remaining 20% based on what you know about your project.

4. Browse the skills marketplace, install two or three

Skills moved out of beta. They are GA now, and the ecosystem caught up fast. There is a marketplace of community and Anthropic-published skills covering most of what you would build first anyway: code review, test scaffolding, refactor passes, design-to-code, deploy checklists, doc-aware library helpers.

A skill is a markdown file with a frontmatter trigger. The trigger tells Claude when to load it: "when the user asks for X." Until the trigger fires, the skill costs zero context. That is the design that makes "install several" actually viable. Three good skills you never used today still cost you nothing in this session.

The fast win is the same one you used with /init: do not start by writing your own. Open the skill marketplace, install two or three that match work you do every week, and use them for a few days. You will learn faster what a skill is for by running someone else's than by trying to design yours blind.

Chapter 4 covers how skills work in detail: the SKILL.md format, when to choose a skill over CLAUDE.md or MCP, how to design good triggers. Today you just need to know the marketplace exists and that installing from it is the fastest path in.

5. Give Claude verification criteria

This is the single highest-leverage habit you can build.

When you end a prompt with "run the tests after" or "check that the build passes," Claude verifies its own work. When a test fails, it reads the error, fixes the issue, and runs the tests again. Without criteria, Claude may skip verification entirely and move on.

6. Use /compact, /cost, and /context

/cost shows where your tokens are going: input tokens consumed, output tokens generated, breakdown by tool category. Run it periodically to stay aware of your budget.

/context visualizes your context usage as a colored grid and shows optimization suggestions, flagging context-heavy tools, memory bloat, and capacity warnings. Think of it as a dashboard for your session health.

/compact summarizes older conversation history, freeing space for new work. Use it between unrelated tasks. The key: you can give it focus instructions. /compact Focus on the API changes tells Claude what to preserve and what to summarize aggressively. Without instructions, Claude guesses what matters. With instructions, you direct the compression.

/compact Focus on the auth implementation and test results
/compact Preserve the file list and migration steps, summarize everything else
/compact Keep the architecture decisions, drop the debugging context

Think of /cost as checking your battery percentage, /context as the battery health dashboard, and /compact as a strategic save that preserves what you choose.

7. Interrupt and rewind

Esc stops Claude mid-action. Context is preserved. You can redirect without losing anything.

Esc+Esc opens the rewind menu. You can restore conversation, code, or both to any previous state. Every action Claude takes creates a checkpoint. If something goes wrong, you go back.

Anthropic's best practices add one more rule: "If you've corrected Claude more than twice on the same issue, /clear and start fresh with a more specific prompt. A clean session with a better prompt almost always outperforms a long session with accumulated corrections."

8. Use /clear between unrelated tasks

Long sessions with irrelevant context reduce performance. When you finish debugging a bug and want to start a new feature, run /clear. The new task starts with a clean context window instead of wading through a conversation about the old bug.

This feels wasteful. You are throwing away everything Claude learned. But a focused 10-minute session beats a cluttered 40-minute session every time.

What becomes possible

Those eight quick wins get you from default to solid. But Claude Code is more than a coding tool. It is an extensible system. Let me show you what becomes possible when you configure it.

The plugin landscape

There are community-built systems that extend Claude Code with specialized workflows. Each takes a different approach:

None of them covers everything. The right move is to pick one, live with it for a while, see what fits your workflow, then build your own. Once you understand how your system works, you know how to use it properly. Someone else's 57 commands will include 40 you never touch.

Beyond code

A configured Claude Code goes well beyond writing code. This is the part most people never reach.

Marketing. I type /copywriting and Claude rewrites my landing page copy using marketing psychology principles: scarcity, social proof, loss aversion. I type /seo-audit and it crawls my site, checks meta tags, analyzes heading structure, and finds fifteen issues I would have missed manually.

Research. I point Claude at documentation and it produces structured research briefings I can reference later. Not summaries. Structured analysis with key insights, comparisons, and recommendations I can act on.

Design-to-code. I paste a Figma URL and Claude implements the design using my project's existing components, matching spacing, typography, and color tokens. Not generic HTML. Production-ready code that follows my design system.

Deployment. Claude runs my pre-deployment checklist: database migrations applied, environment variables set, DNS configured, smoke tests passing. It tells me what is missing before I ship.

These are not hypothetical. They are commands I run on my own projects. The gap between "Claude writes code for me" and "Claude handles half my work" is what this course closes.

The gap

Quick wins get you from default to 3x. A configured system gets you to 10x. The difference is not installing more plugins or memorizing more commands. It is methodology: you learn how Claude Code actually spends its resources, build around that reality, and end up with a system that gets a little better every time you use it.

That methodology is what Chapters 2 through 7 teach. The rest of this chapter sets up the one resource it all protects, starting with the question you are probably already asking: didn't the 1M context window make all of this go away?