I use Claude Code eight to ten hours a day. It’s not a side tool — it’s the core of how I engineer software. I ship SaaS products, maintain production applications, and manage infrastructure with it. And I’ll be direct: most people complaining that Claude “doesn’t work” or that “ChatGPT is better” have never configured Claude beyond opening a terminal and typing a prompt.

That’s like buying a professional-grade espresso machine and complaining it makes bad coffee because you didn’t dial in the grind. The tool is exceptional. But it rewards engineers who take twenty minutes to set it up properly.

Here’s everything I’ve learned about getting the most out of Claude Code — from memory systems to context management to features most users don’t even know exist.

CLAUDE.md: The Single Most Important File You’re Not Using

Every project I work on has a CLAUDE.md file in the root directory. This is a persistent instruction file that Claude reads at the start of every conversation. It’s the difference between Claude understanding your project from the first message versus spending half your session re-explaining basic context.

Think of it as onboarding documentation for your AI pair programmer. You wouldn’t expect a new team member to be productive without telling them the tech stack, the build commands, the architecture, and the conventions. Claude is no different.

Here’s what goes in a good CLAUDE.md:

  • Build commands — pnpm dev, pnpm test, cargo build, whatever your project uses
  • Architecture overview — key directories, data flow, how components connect
  • Conventions — naming patterns, file organization, coding standards
  • Environment details — database info, API endpoints, deployment targets
  • What NOT to do — production safety rules, files to never modify, patterns to avoid

Don’t have one yet? Run /init and Claude will analyze your codebase and generate a starting CLAUDE.md automatically. It detects your build tools, test frameworks, and project structure. You’ll want to refine it, but it gets you 80% of the way there in seconds.

Where CLAUDE.md Files Can Live

This is where it gets powerful. CLAUDE.md isn’t limited to your project root. Claude loads instruction files from multiple locations, layered by scope:

  • Global — ~/.claude/CLAUDE.md applies to every project on your machine. I keep my personal preferences here: how I like commit messages formatted, my git workflow rules, tone preferences.
  • Project — ./CLAUDE.md in your repo root. Checked into git, shared with your team. Architecture, commands, conventions.
  • Local override — ./CLAUDE.local.md for personal project-specific notes. Add it to .gitignore.
  • Subdirectory — Put a CLAUDE.md inside src/api/ and it only loads when Claude is working with files in that directory. Perfect for specialized instructions without bloating every session.

All of these stack. Claude reads every applicable CLAUDE.md and follows all of them. This means your global preferences, project conventions, and directory-specific rules all work together without you repeating anything.

Keep It Under 200 Lines

Here’s a mistake I see: people write 500-line CLAUDE.md files with every possible instruction they can think of. That actually hurts performance. Every line of CLAUDE.md consumes context window space in every single conversation. Keep the main file concise — under 200 lines — and move detailed, specialized instructions into .claude/rules/ files that load conditionally based on file paths.

The Memory System: Claude Remembers Across Sessions

This is the feature that changed everything for me, and most people don’t even know it exists.

Claude Code has a persistent memory system. It can save notes to itself — things it learned about your project, your preferences, debugging insights, architectural decisions — and recall them in future conversations. Your project context doesn’t die when you close the terminal.

Memory files live in ~/.claude/projects/<your-project>/memory/. There’s a MEMORY.md index file (the first 200 lines load automatically every session) and individual topic files that Claude reads on demand.

Here’s the key insight: you can tell Claude what to remember. After figuring out a tricky deployment issue? Say “remember that the deploy hook URL needs to be in the .env file.” Claude saves it. Next week when you’re debugging deploys, it already knows.

You can also tell Claude to forget things that are no longer relevant: “forget the old database migration process, we switched to Flyway.” Memory stays current because you keep it current.

Memory types include:

  • User preferences — your role, expertise level, how you like to work
  • Project context — ongoing initiatives, deadlines, who owns what
  • Feedback — corrections and confirmations that shape future behavior
  • References — pointers to external resources, dashboards, documentation

Context Management: /compact, /context, and Why They Matter

Every AI model has a context window — a limit on how much text it can process at once. Claude Code’s Opus and Sonnet models support up to one million tokens, which is massive. But it’s not infinite, and how you use that space directly impacts the quality of responses you get.

Two commands you should know:

/compact — Summarizes your conversation history, preserving important decisions and code changes while freeing up space. When you’ve been working for hours and the conversation is getting long, /compact condenses everything into a clean summary. Claude re-reads your CLAUDE.md fresh, so your instructions fully survive compaction.

You can even guide what it preserves: /compact Focus on the API authentication changes tells Claude what matters most in the summary.

Claude Code also triggers compaction automatically when the context gets full — around 80% capacity. But running it manually when you’re switching focus areas within a long session keeps things cleaner.

/context — Visualizes exactly what’s consuming your context window right now. System prompt, memory files, CLAUDE.md content, conversation history, file reads, command outputs — all broken down so you can see where tokens are going. If you’ve never run this command, you’ll be surprised at what’s taking up space.

Practical Token Optimization Techniques

Here’s where we get tactical. These are the specific techniques I use daily to keep Claude Code fast, accurate, and cost-effective.

Read Files Surgically

The Read tool accepts offset and limit parameters. Instead of loading a 10,000-line file into context, read just the 50 lines you need. The difference in token cost is enormous — and the AI’s responses are better because it’s not drowning in irrelevant code.

In your CLAUDE.md, you can instruct Claude to always use offset/limit: “Use offset/limit on Read tool — never read full files unless under 100 lines.” Claude follows this consistently.

Delegate Research to Subagents

This is a power-user feature that most people never touch. When Claude needs to investigate something — reading multiple files, searching the codebase, exploring architecture — it can spawn a subagent. The subagent does the research in its own separate context window and reports back a summary.

Your main conversation stays clean. Instead of ten file reads polluting your context, you get one concise summary. I instruct Claude to “delegate research involving 3+ file reads to Explore agents.” That single rule has dramatically improved my session longevity.

Filter Command Output

Running npm test might produce 500 lines of output. Most of it is passing tests you don’t care about. Pipe it: npm test 2>&1 | tail -30 gives you just the results. pnpm build 2>&1 | tail -20 shows you the outcome without the entire webpack compilation log.

This is free optimization. Less output in context means more room for actual work.

Use the Right Model for the Task

Claude Code supports multiple models, and you can switch mid-session with /model:

  • Haiku — Fast and cheap. Perfect for simple refactors, file renaming, straightforward code generation.
  • Sonnet — The daily driver. Balanced capability and speed for most engineering work.
  • Opus — The heavy hitter. Complex architectural decisions, intricate debugging, multi-system reasoning.

Don’t use Opus to rename a variable. Don’t use Haiku to architect a distributed system. Match the model to the complexity of the task.

Adjust Effort Levels

The /effort command controls how deeply Claude reasons about each response. Low effort for straightforward tasks, high effort for complex problems. This directly impacts token usage — low effort means fewer reasoning tokens, which means faster and cheaper responses when deep thinking isn’t needed.

Skills and Hooks: On-Demand Context, Not Always-On Bloat

Your CLAUDE.md loads every session. Every line costs tokens whether you need it or not. For specialized workflows — database migrations, PR reviews, deployment processes — that’s wasteful.

Skills are instruction files that load only when invoked. Put your detailed deployment checklist in .claude/skills/deploy/SKILL.md and invoke it with /deploy only when you’re actually deploying. Every other session, those tokens stay free.

Hooks are shell commands that run automatically at specific lifecycle points. A PostToolUse hook can filter test output before Claude sees it, strip noise from build logs, or auto-format code after edits. Hooks are deterministic — they always run, unlike CLAUDE.md instructions which are advisory.

Between skills and hooks, you can move substantial amounts of logic out of your always-loaded CLAUDE.md and into on-demand systems that activate only when needed.

The /init Setup Flow

If you’re starting fresh with a project, /init is your first command. It scans your codebase and generates:

  • A CLAUDE.md with detected build commands, frameworks, and patterns
  • Suggestions for memory and skill configuration
  • Baseline conventions inferred from your existing code

For existing projects, running /init when you already have a CLAUDE.md will suggest improvements based on what it finds. It’s not destructive — it shows you what it wants to change and asks first.

I’ve started treating /init the same way I treat git init — it’s the first thing that happens when a new project gets created. Twenty seconds of setup that saves hours across every future session.

The Trick Nobody Uses: Just Tell Claude to Optimize

Here’s something that baffles me about the complaints I see online. Claude Code is a reasoning AI. You can literally tell it: “Optimize your token usage for this session. Read files with offset/limit, delegate research to subagents, keep responses concise, and pipe long command outputs.”

And it will do it. Consistently. For the entire session.

Better yet, put those instructions in your global ~/.claude/CLAUDE.md and they apply to every project, every session, automatically. You set it up once and forget about it.

People will spend an hour complaining on social media that Claude is too expensive or burns through context too fast, but they won’t spend five minutes writing instructions that fix both problems. The tool does what you tell it to do. So tell it.

A Word on “ChatGPT Is Better”

To each their own. I mean that genuinely — if another tool works better for your workflow, use it. I’m not here to argue brand loyalty.

But I will say this: most “Claude vs. ChatGPT” comparisons I see online are comparing an unconfigured Claude session against a well-prompted ChatGPT conversation. That’s not a fair fight. A configured Claude Code environment with CLAUDE.md files, memory, skills, and proper context management is a fundamentally different experience from a bare terminal session.

I’ve engineered production applications — full-stack SaaS products, prediction engines, CRM systems — using Claude Code as my primary tool. Not prototypes. Production software serving real users. The results speak for themselves when the tool is used correctly.

Getting Started: The 20-Minute Setup

If you take nothing else from this post, do these five things:

  1. Run /init in your project directory to generate a CLAUDE.md.
  2. Create ~/.claude/CLAUDE.md with your global preferences — git workflow, response style, optimization rules.
  3. Enable memory (it’s on by default) and start telling Claude to remember important decisions and context.
  4. Learn /compact and use it when switching focus areas in long sessions.
  5. Add context optimization rules to your CLAUDE.md: use offset/limit on reads, delegate research to subagents, pipe command output.

Twenty minutes of setup. Then watch the difference in every session that follows. Claude Code is the most capable AI engineering tool available today — but only if you give it the context it needs to do its best work.

Have questions about configuring Claude Code for your specific workflow? Get in touch. I’ve been optimizing this setup across a dozen production projects and I’m happy to share what works.