Claude Code Tips and Tricks

Updated March 2026

Claude Code is powerful out of the box, but a handful of habits and configurations separate a productive session from a frustrating one. This guide covers the practical techniques that experienced users rely on daily — from project setup to prompt structure to session management.

Most of these tips cost nothing extra. They're about working smarter with the same plan and the same rate limits. If you apply even half of what's here, you'll use fewer tokens, hit rate limits less often, and get consistently better results.

Set up CLAUDE.md for every project

CLAUDE.md is a special Markdown file that Claude Code reads automatically at the start of every session. Place it in your project root and it becomes persistent memory — instructions that survive across sessions without you having to repeat them.

What goes in CLAUDE.md

Think of it as a briefing document for a new team member. Include anything Claude needs to know to work effectively in your codebase:

• Build commands — npm run build, swift build, cargo test, whatever your project uses. Claude will reference these instead of guessing.
• Test commands — how to run the full suite and how to run a single test file. Include any flags or environment variables needed.
• Coding conventions — naming patterns, formatting preferences, import ordering, error handling style. Be specific: "use camelCase for functions, PascalCase for types" is better than "follow standard conventions."
• File structure notes — where key modules live, how the project is organized, which directories matter most. A few lines here save Claude from exploring blindly.
• Things to avoid — patterns you don't want, libraries you've decided against, files that shouldn't be modified. Negative constraints are just as valuable as positive ones.

Why this saves tokens

Without CLAUDE.md, you end up typing the same instructions at the start of every session: "We use TypeScript strict mode, tests go in __tests__, run vitest to test, don't use default exports." Each time you type that, it costs tokens — both your input and Claude's acknowledgment.

With CLAUDE.md, those instructions load automatically. They're in context from the first message, and you never have to repeat them. Over dozens of sessions, the token savings add up significantly.

CLAUDE.md scope levels

Claude Code supports multiple CLAUDE.md files at different levels:

• Project root — CLAUDE.md in your repo root. Shared with the team if committed to git.
• Local override — CLAUDE.local.md in the project root. Gitignored, for personal preferences that shouldn't be shared.
• User-level — ~/.claude/CLAUDE.md. Applies to all projects. Good for universal preferences like commit message style or security rules.

All levels are loaded and combined. Use project-level for project-specific rules and user-level for personal defaults.

Use .claudeignore to keep noise out

.claudeignore works like .gitignore but specifically for Claude Code. It tells Claude which files and directories to skip when searching, reading, and exploring your project. Less noise means better results and fewer wasted tokens.

What to exclude

• Build artifacts — dist/, build/, .next/, DerivedData/. Claude doesn't need compiled output.
• Dependencies — node_modules/, Pods/, .build/. These are massive directories that Claude will never usefully navigate.
• Generated files — auto-generated types, protobuf output, GraphQL codegen. Claude should work with the source, not the generated result.
• Large data files — fixtures, sample databases, binary assets. Anything that would fill context without providing useful information.
• Lock files — package-lock.json, yarn.lock, Podfile.lock. Huge files with no value for code understanding.

Example .claudeignore

A practical starting point for a typical web project:

node_modules/
dist/
build/
.next/
coverage/
*.lock
*.min.js
*.min.css
*.map

Place this in your project root. Claude Code reads it automatically. The syntax is identical to .gitignore — glob patterns, directory slashes, negation with !.

The impact on token usage

Without a .claudeignore, Claude might search through node_modules when looking for a function definition, or read a minified bundle when you asked it to check the source. Each of these mistakes dumps thousands of irrelevant tokens into your context window. A well-configured ignore file prevents these entirely.

Master slash commands

Claude Code has built-in slash commands that give you direct control over the session. Most users know about one or two, but the full set is worth learning.

/compact — compress your context

The most important slash command. It summarizes the current conversation and frees up context space. Use it at natural breakpoints — after finishing a subtask, after a long debugging session, or whenever you notice Claude's responses getting less precise.

The power move: add a focus instruction. /compact focus on the authentication refactor tells Claude to prioritize that topic in the summary. Without focus, the summary tries to capture everything equally, which means important details might get compressed away.

/clear — start completely fresh

Wipes the entire context and starts a new session. Use this when switching to a completely different task, or when a session has degraded beyond what /compact can fix. It's faster than quitting and relaunching Claude Code.

/model — switch models on the fly

Switches the active model without restarting. Useful for matching model capability to task complexity. Use a faster model for straightforward tasks like renaming variables or writing boilerplate, and switch to a more capable model for architecture decisions or complex debugging.

/cost — check your token usage

Shows how many tokens the current session has consumed. Useful for getting a quick read on how much context space you've used, though for real-time monitoring across sessions, AI Battery gives you a persistent view without interrupting your workflow.

/init — generate a CLAUDE.md

If you don't have a CLAUDE.md yet, /init will generate one by analyzing your project structure. It detects the tech stack, build system, test framework, and creates a reasonable starting point. Review and edit the result — the auto-generated version is a starting template, not the final product.

Structure your prompts for better results

The way you phrase requests has a direct impact on the quality of Claude's output and the number of tokens consumed. Vague prompts lead to exploratory behavior — Claude reads more files, tries more approaches, and produces longer responses. Specific prompts lead to focused action.

Be specific about scope

Compare these two prompts:

• Vague: "Refactor the authentication code"
• Specific: "Extract the token refresh logic from src/auth/login.ts into a separate refreshToken function in src/auth/tokens.ts"

The vague prompt forces Claude to figure out what "the authentication code" means, which files are involved, what kind of refactoring you want, and how far to go. That exploration burns tokens and context space. The specific prompt gives Claude a clear target.

Provide context upfront

If you know which files are relevant, say so. "The bug is in src/api/handlers.ts around line 140 — the error response doesn't include the status code" is far more efficient than "there's a bug in the API error handling somewhere." Every file Claude reads while searching adds to your context. Point it in the right direction.

Reference specific files and functions

Claude can read files by path. Use that. "Read src/utils/format.ts and add a formatCurrency function that follows the same pattern as formatDate" gives Claude everything it needs in one message. No searching, no guessing.

Break large tasks into steps

A single prompt like "add user authentication with OAuth, email/password, and magic links" is likely to produce a sprawling response that fills your context. Instead, break it down:

1. "Set up the auth database schema in src/db/schema.ts"
2. "Implement email/password login in src/auth/password.ts"
3. "Add the OAuth flow in src/auth/oauth.ts"

Each step gets focused attention, produces a reviewable result, and gives you a natural point to /compact before continuing.

Use git effectively with Claude Code

Git is your safety net when working with an AI code editor. The undo button is git checkout, and it only works if you've committed before Claude started editing.

Commit before risky changes

Before asking Claude to do anything destructive — a large refactor, deleting files, restructuring a module — make sure your working tree is clean. Run git add -A && git commit -m "checkpoint before refactor" or let Claude do it. If the result isn't what you wanted, git reset --hard HEAD gets you back instantly.

Use branches for experiments

When you're not sure if an approach will work, have Claude create a branch first. git checkout -b experiment/new-parser isolates the changes. If the experiment fails, you delete the branch and lose nothing. If it works, you merge it.

Let Claude read git diffs

Claude can run git diff and git log to understand recent changes. This is useful when:

• You're continuing work from a previous session and want Claude to see what changed
• You need Claude to review changes before committing
• You want Claude to write a commit message based on the actual diff
• You're debugging a regression and want to narrow down which commit introduced it

Use git stash when switching tasks

If you need to switch tasks mid-session but have uncommitted changes, git stash saves them without creating a commit. When you come back, git stash pop restores everything. This is cleaner than committing half-finished work.

Small, atomic commits

Ask Claude to commit after each logical change rather than accumulating a massive diff. Small commits are easier to review, easier to revert, and give you more granular undo points. "Commit what we've done so far with a descriptive message" is a prompt you should use frequently.

Manage multiple sessions wisely

Claude Code lets you run multiple sessions in parallel — different terminal windows, different projects, different tasks. This is powerful but comes with tradeoffs.

One session per task

Don't try to do everything in a single session. A session working on database migrations shouldn't also be handling frontend CSS fixes. Each task gets its own session with its own clean context. The context stays focused, and Claude's responses stay relevant.

Parallel sessions share rate limits

Running several sessions at once increases your total Claude Code usage. It does not create extra headroom by itself. If you are already close to your usage limits, parallel sessions can push you there faster.

If you're already approaching your rate limit, running a second session will push you over the edge faster. Be strategic: run parallel sessions when you have plenty of headroom, and stick to one session at a time when limits are tight.

Know when to start fresh

Sometimes a session is too far gone. Signs that you should start a new session instead of continuing:

• Claude keeps re-reading files it has already read
• Responses are getting longer but less accurate
• Claude has forgotten constraints you set earlier
• The session has already been auto-compacted once
• You've switched to a completely different task

Starting fresh costs nothing. A new session gives you a full context window and a clean slate. The few minutes of re-establishing context are almost always worth it compared to fighting a degraded session.

Use the right session for the right work

Heavy exploration sessions — "understand this codebase," "find all the places where we handle errors" — burn through context fast. Keep those separate from focused implementation sessions where you're writing code. The exploration session fills up and gets discarded; the implementation session stays lean and productive.

Monitor your usage

Knowing where you stand — how much context you've used, how close you are to rate limits, how many tokens a session has consumed — lets you make better decisions about how to work.

Without visibility, you're guessing. You don't know if you should start a new session or keep going. You don't know if that next big refactor request will push you over your rate limit. You don't know which of your three running sessions is closest to auto-compaction.

The /cost slash command gives you a snapshot, but it's per-session and requires interrupting your work. For persistent, cross-session visibility, you need something running in the background.

Frequently asked questions

What's the best model to use in Claude Code?

It depends on the task. Claude Sonnet is faster and cheaper for straightforward work — writing tests, renaming variables, generating boilerplate, simple bug fixes. Claude Opus is better for complex reasoning — architecture decisions, subtle bugs, multi-file refactors that require understanding relationships across the codebase. Use /model to switch on the fly. Start with Sonnet and upgrade to Opus when you need deeper thinking.

Can I use Claude Code offline?

No. Claude Code requires an internet connection to communicate with Anthropic's API. All model inference happens on Anthropic's servers. If you lose connectivity mid-session, your session state is preserved locally, and you can resume when you're back online. Your conversation history and any files Claude modified on disk are not lost.

How do I reset my session?

Use /clear to wipe the context and start fresh within the same Claude Code process. This keeps your terminal open and your working directory intact but gives you a completely empty context window. Alternatively, press Ctrl+C to exit and run claude again — this also gives you a clean session. If you just want to free up space without losing everything, use /compact instead, which summarizes rather than clears.

Does Claude Code work in any IDE?

Claude Code is a terminal application, not an IDE extension. It runs in any terminal emulator — Terminal.app, iTerm2, Warp, Ghostty, Kitty, the integrated terminal in VS Code or any JetBrains IDE. It doesn't integrate directly into an editor's UI, but since most editors have a built-in terminal panel, you can run Claude Code side-by-side with your code. It works with any project in any language, regardless of which editor you use.