Claude Code power tips

Resume and continue a session

Every Claude Code session stores a conversation transcript (the full back-and-forth history) locally. When you close the terminal or lose your connection, that context is not gone. Two flags let you pick it back up.

--continue reopens the most recent session automatically. You do not have to remember any ID. Run claude --continue from the same project folder and Claude Code reloads the last conversation and lets you keep typing where you left off.

--resume gives you a choice. It lists your recent sessions with timestamps and short summaries, so you can pick the right one when you have been switching between several tasks. Pass a session ID directly to skip the list: claude --resume <session-id>.

• Use --continue for the simple case: one active task, just broke off.
• Use --resume when you need to return to an older or a specific session.
• Context reloaded this way counts against your active context window (the token limit per conversation), so very long old sessions may be trimmed.
• Both flags work inside the interactive CLI, the VS Code extension, and the JetBrains plugin.

Rewind: roll back safely

Claude Code creates a checkpoint (a saved snapshot of your conversation and file state) every time you send a message. If an edit goes wrong, you can jump back to any earlier checkpoint without losing your project history.

The command /rewind opens the checkpoint picker. You scroll through past turns, choose the one you want to return to, and Claude Code restores both the conversation context and the on-disk files to that exact moment. It is non-destructive: the discarded turns are removed from the active session but your git history (if you have one) is untouched.

Common reasons to rewind:

• Claude introduced a bug you cannot easily undo with a single edit.
• You approved a large refactor and then changed your mind.
• You want to try two different approaches from the same starting point (safe experimentation).
• The conversation drifted off-topic and earlier context gave better results.

Safe experimentation is the real power here: rewind to a clean checkpoint, try approach A, note the outcome, rewind again, try approach B, then keep the winner. No manual backup files needed.

Paste images and screenshots

Claude Code accepts images directly in the chat input. You can drag and drop a file onto the terminal window, paste from your clipboard with Ctrl+V (or Cmd+V on Mac), or supply a file path. The image is encoded and sent alongside your text prompt in the same request.

This works across all three surfaces: the CLI (terminal), the IDE extension (VS Code, JetBrains), and the web UI at claude.ai used with Claude Code projects. On the CLI, dragging a file into the terminal window inserts its path, and Claude Code resolves and uploads it automatically.

Common use cases for image input in a coding session:

• Bug screenshots: paste a browser console error or a broken UI state and ask Claude Code to diagnose it.
• Design references: drop a Figma export or a mockup and ask for matching HTML/CSS.
• Error dialogs: capture a crash dialog or a log panel that is hard to copy as text.
• Architecture diagrams: share a whiteboard photo and ask Claude Code to scaffold the described structure.

Vision capability (the ability to understand image content) is available on claude-opus-4-8 and claude-sonnet-4-6. Haiku (claude-haiku-4-5) also supports images but with lower reasoning depth. For complex UI analysis or detailed diagrams, prefer Sonnet or Opus.

Reference files fast

Claude Code gives you three fast ways to pull a file into your prompt without typing a full path. Mastering them cuts the friction of referencing code, configs, or docs mid-conversation.

Drag and drop works in any terminal that supports it: drag a file from your file explorer onto the Claude Code prompt and the absolute path is pasted instantly. No typing, no mistakes.

The @ mention (type @ followed by a filename or partial path) opens an inline file picker. Claude Code searches your project and lets you select the file. The resolved path is inserted into the prompt and the file content is attached as context for Claude.

Three ways to reference files quickly:

• Drag and drop: drag a file from your OS file explorer onto the terminal prompt.
• @ mention: type @filename and pick from the autocomplete list.
• Tab completion: type a partial path and press Tab to complete it, just like a normal shell command. Works for /read, /edit, and plain file references in your message.

Run a command inline with !

In Claude Code's interactive shell (the REPL you get when you type claude with no arguments), you can prefix any shell command with ! to run it and inject its output directly into your conversation context. Context here means the working memory Claude reads before it responds.

This matters because Claude cannot see your file system or terminal history on its own. The ! prefix is the fastest way to hand Claude real, live data without copy-pasting.

Common uses of the ! prefix:

• !git log --oneline -10 shows the last ten commits so Claude can reason about history.
• !cat package.json lets Claude read a config file without you opening it separately.
• !npm test 2>&1 pipes test output (including errors) into context so Claude can diagnose failures immediately.
• !ls src/ gives Claude a directory listing it can reference when suggesting file edits.

The output appears in the conversation turn, visible to both you and Claude. If the command produces a lot of lines, Claude still sees all of it, but very long outputs can consume a significant portion of your context window (the total token budget for a session).

Save a memory with #

Claude Code can remember facts, preferences, and rules across sessions. The fastest way to write a memory is to start your message with #. That single character tells Claude Code to save what follows, rather than treat it as a regular instruction.

When you type something like # always use TypeScript strict mode, Claude Code decides where to store it: either in CLAUDE.md (a plain text file in your project or home folder that acts as a persistent instruction sheet) or in its internal memory store. You do not have to choose manually; Claude Code picks the right location based on whether the fact is project-specific or general.

Common things worth pinning with #:

• Coding style rules (naming conventions, formatter settings)
• Project-specific context (stack, folder layout, environment quirks)
• Personal preferences (language, tone, no em-dash, no emoji)
• Recurring commands or scripts you always forget the flags for

You can review what has been saved by opening CLAUDE.md in your editor or by asking Claude Code: what do you remember about this project?. Memories written to CLAUDE.md are plain text and fully editable, so you can clean, reorder, or delete entries at any time.

Interrupt and redirect

When Claude Code is running, pressing Esc sends a soft interrupt. Claude finishes its current atomic step, then stops and waits for your next instruction. You do not lose the session context, the file edits already written, or the conversation history.

This is different from Ctrl+C, which kills the process entirely and forces you to restart. Esc is the surgical tool: use it when Claude is heading in the wrong direction but you want to steer, not restart.

After the interrupt, you can:

• Type a correction and press Enter to redirect Claude toward the right approach.
• Ask Claude to undo the last set of file changes with /undo before giving new instructions.
• Paste additional context (an error message, a file path, a constraint you forgot) so Claude can continue with better information.
• Type /clear if the conversation has drifted too far and you want a clean slate while staying in the same session.

The practical rule: interrupt early. If you see Claude taking the wrong architectural decision in the first tool call, Esc immediately. Letting it run five more steps before interrupting means more undoing.

Thinking keywords

Claude Code lets you dial up how hard the model reasons before it answers. Three plain-English keywords control this: think, think hard, and ultrathink. You drop one of them into your prompt and Claude Code activates an extended internal reasoning pass (sometimes called a "thinking budget") before writing its reply.

The tradeoff is simple: more thinking means better answers on hard problems, but it also means more tokens consumed and a longer wait. Tokens are the chunks the model reads and writes; every extra reasoning step costs tokens, which costs time and, if you are on a paid plan, money.

When to use each level:

• think: light extra reasoning, good for moderately tricky questions where the default feels shallow.
• think hard: deeper pass, useful for architecture decisions, tricky bugs, or multi-step plans.
• ultrathink: maximum budget, reserved for the hardest problems (complex refactors, subtle security issues). Noticeably slower.

These keywords work in any Claude Code context: the terminal prompt, inline chat inside your editor, and the web UI. You can combine them with other instructions in a single sentence.

Make your own slash commands

Claude Code lets you define custom slash commands as plain Markdown files stored inside a .claude/commands/ folder at the root of your project. When you type /your-command in the Claude Code prompt, it reads that file and runs it as an instruction.

The file name becomes the command name. A file called .claude/commands/review.md creates the command /review. The content of the file is the prompt Claude receives, so you write it exactly as you would write any careful prompt.

Arguments let you pass dynamic values into a command. Inside the Markdown file, use the placeholder $ARGUMENTS (all caps). Whatever you type after the command name in the prompt is substituted in place of that token at runtime.

• Put project-level commands in .claude/commands/ (tracked by git, shared with your team).
• Put personal commands that apply across all projects in ~/.claude/commands/ (your home directory).
• Arguments are a single string: /review src/auth.ts passes src/auth.ts as $ARGUMENTS.
• Commands can be as long and structured as you need: checklists, step-by-step instructions, output format rules.

Manage extensions

Claude Code exposes three built-in managers that let you inspect and control its extension points without touching config files by hand. Type /agents to list every sub-agent available in the current project, /mcp to see which MCP servers (Model Context Protocol servers, external tools that Claude Code can call) are connected and their status, and /hooks to view the shell commands that fire automatically before or after key events such as a commit or a stop.

Each manager is a live panel, not a static file dump. From /mcp you can see whether a server is running, restart it, or disconnect it on the spot. From /hooks you can review every registered hook (the event name, the command, and whether it runs in the foreground or background) so you know exactly what automation is attached to your session.

The /agents view matters most when you are in a project that defines custom sub-agents (agents scoped to that repo via .claude/agents/). It shows both project-level and global agents, so you can spot naming conflicts or stale entries before they cause unexpected behavior.

• /agents: list all sub-agents (global and project-scoped).
• /mcp: inspect, restart, or disconnect MCP servers live.
• /hooks: audit every event hook wired to the current session.
• All three managers reflect the merged state of global ~/.claude/settings.json and project .claude/settings.json.

Headless mode and piping

By default, Claude Code opens an interactive session where you type prompts and read replies. Headless mode skips that entirely: you pass your prompt directly on the command line with the -p flag (short for --print), Claude answers once to stdout (standard output, meaning the terminal text stream), and the process exits. No menus, no waiting for input.

This makes Claude Code a proper Unix-style tool you can wire into shell pipelines (chains of commands where one program's output feeds the next) and automation scripts. The result prints as plain text, so anything that reads text can consume it: a log file, another command, a CI step (a stage in a continuous integration system that runs checks on your code automatically).

Common uses for headless mode:

• Summarise a file: cat report.txt | claude -p "Summarise this in three bullet points"
• Generate a commit message from a diff: git diff | claude -p "Write a concise commit message"
• Batch-process many files in a loop script
• Pipe Claude output into another tool: claude -p "List 5 test cases for a login form" | tee test-ideas.txt

Add --model to pick a specific model, and --output-format json (or stream-json) when a downstream script needs structured data instead of prose. Keep prompts short and precise: headless mode has no back-and-forth to clarify ambiguity.

Parallel sessions with worktrees

A Git worktree is a second (or third, or fourth) checkout of the same repository, each living in its own folder and tracking its own branch. You can run a separate Claude Code session inside each worktree simultaneously, so different tasks advance in parallel without any session blocking another.

To create a worktree, run git worktree add <path> <branch> from your main repo. The path is a new folder; the branch can be new or existing. Open that folder in a new terminal and launch claude there. Claude Code reads the working directory automatically, so each session sees only its own branch.

Practical conventions that keep three to five parallel sessions manageable:

• Name the folder after the task, not the branch: ../myapp-feat-auth instead of ../wt1. You will thank yourself when juggling five terminals.
• Use a shell alias to jump quickly: alias wt-auth="cd ~/myapp-feat-auth && claude".
• One branch per worktree: never check out the same branch in two worktrees at the same time (Git blocks this by design).
• Clean up when done: git worktree remove <path> then delete the folder, to keep git worktree list readable.

The Claude Code CLI flag --resume lets you reattach to a previous conversation by session ID. Combine it with worktrees: one worktree keeps a long-running refactor session, another runs a quick bug-fix session you resume on demand.

Model selection and fast mode

Claude Code runs on one of three models (the underlying AI engine): Opus (claude-opus-4-8), Sonnet (claude-sonnet-4-6), or Haiku (claude-haiku-4-5). Each trades capability for speed and cost.

Switch models at any time with the /model slash command. Type it alone to see the picker, or pass a model id directly:

• /model claude-opus-4-8 for the most capable reasoning (architecture, hard bugs, long context).
• /model claude-sonnet-4-6 for the everyday sweet spot: strong quality at lower latency.
• /model claude-haiku-4-5 for fast, cheap tasks: renaming files, short summaries, simple edits.

The /fast command is a session-level toggle. It tells Claude Code to prefer speed over depth for the rest of the conversation, useful when you are iterating quickly and want snappy responses rather than extended reasoning. Type /fast again to turn it off.

Update, July 2026: the lineup moved. Claude Sonnet 5 (claude-sonnet-5) shipped on June 30, 2026 and is now the default model in Claude Code, and Fable 5 (claude-fable-5), the new tier above Opus, is available on paid plans. Fast mode matured into the /fast toggle on Opus 4.8: the dedicated lesson later in this module covers its pricing and its traps.

/fast mode: paying for speed

Fast mode is a research preview in Claude Code that trades money for speed. Type /fast in a session and, if you were on another model, Claude Code switches you to Opus and shows a lightning icon in the interface. From that point on, the same Opus model runs up to 2.5x faster in output tokens per second. It is important to understand what this is not: fast mode is not a different, lighter model. It runs the exact same Opus weights. What changes is an API configuration flag that asks Anthropic's infrastructure to prioritize your requests for lower latency, and you pay a premium for that priority.

The premium is exactly double the standard rate. As of July 2026, standard Opus 4.8 pricing is $5 per million input tokens (MTok, the unit used for token pricing) and $25 per MTok output. Fast mode on Opus 4.8 charges $10 per MTok input and $50 per MTok output. So a task that would cost $1 in tokens at standard speed costs $2 at fast speed. You are not paying for a smarter answer, you are paying for the same answer to arrive faster.

Fast mode has a minimum Claude Code version requirement: v2.1.36 or later. Since v2.1.154, Opus 4.8 is the default model used whenever fast mode is toggled on, which is why switching models happens automatically when you type /fast. Fast mode support is not permanent for every model tier. Fast mode for Opus 4.7 was deprecated on June 25, 2026, and Anthropic plans to remove it entirely on July 24, 2026; after that date, requesting fast mode on Opus 4.7 will return an error instead of silently degrading. Opus 4.6's fast mode was already removed earlier, on June 29, 2026, and it behaves differently: instead of erroring, requests for fast mode on Opus 4.6 silently fall back to standard speed and standard billing. You can detect this silent fallback by checking the usage.speed field in API responses; if you expected fast mode and the field does not say fast, you were billed at standard rates even though you thought you had opted into the premium.

The single most expensive mistake to avoid with fast mode is enabling it in the middle of a long conversation. When you toggle /fast mid-session, Claude Code does not just apply the fast, expensive rate to new messages going forward. It re-bills your entire existing context at the uncached fast-mode input rate. Normally, prompt caching lets repeated context be rebilled at a steep discount on subsequent turns. Switching speed invalidates that cache, so a session with 100,000 tokens of accumulated context that switches to fast mode pays full fast-mode input price on all 100,000 tokens again, not just on the next reply. The practical rule: decide whether you want fast mode before you start a session, or don't use it at all in that session. Toggling it partway through can turn a cheap, long-running conversation into an expensive one in a single step.

Fast mode has its own separate rate limit pool, distinct from the standard Opus rate limits. If you exhaust the fast-mode limit, requests automatically fall back to standard speed rather than failing outright, so a burst of fast-mode usage will not break your session, it will just quietly get slower and cheaper again once the limit is hit. For administrators managing a team, two settings.json controls exist: setting "fastMode": true enables it, fastModePerSessionOptIn can force each user to opt in per session rather than having it on by default, and setting the environment variable CLAUDE_CODE_DISABLE_FAST_MODE=1 disables fast mode entirely at the machine or team level. On a Claude subscription plan (not pay-as-you-go API billing), fast mode usage draws exclusively from your usage credits pool and never touches your plan's included message limits, so it is a separate budget line to watch.

Fast mode is not available everywhere. It does not work in the VS Code extension, and it is not available when running Claude through Amazon Bedrock, Google Cloud Vertex AI, or Microsoft Foundry; it is a Claude Code and direct API feature only. Use it for latency-sensitive interactive work, such as pair-programming sessions where you are watching the output stream and waiting on Claude's response before your next action. Avoid it for long batch runs, overnight refactors, or any workload where total cost matters more than shaving seconds off each response, since doubling the per-token price compounds quickly over a high-volume job.

• /fast is a request-configuration toggle on the same Opus weights, not a separate cheaper or dumber model.
• Fast mode costs double: $10/$50 per MTok on Opus 4.8 versus $5/$25 standard, for up to 2.5x faster output.
• Enabling it mid-conversation re-bills your whole existing context at the expensive rate; decide at session start, not partway through.
• Check usage.speed in API responses to catch silent fallback to standard speed and billing, especially on retired-fast-mode models like Opus 4.6.

Code review at three depths

Claude Code ships a built-in family of review commands under /code-review (as of July 2026). At its simplest, /code-review looks at your current diff (the set of lines you have changed but not yet committed or merged) and reports two kinds of findings: correctness bugs and cleanup opportunities. You do not need to describe what you changed. The command reads the diff itself and reasons about it.

Every run happens at an effort level, a dial that trades review depth against noise. At low or medium effort, the review returns fewer findings, but each one is high-confidence: things Claude is fairly sure are real problems. At high effort and above, the review widens its coverage, meaning it looks at more of the surrounding code and more possible failure modes, and it may surface findings it is less certain about. That tradeoff is intentional: low effort is meant for a fast sanity check while you are still iterating, high effort is meant for the moment before you actually open a pull request (a PR, the request to merge your branch into the main codebase).

Two flags change what happens to the findings once they exist. --comment posts each finding as an inline comment on the pull request, attached to the exact line it concerns, so a human reviewer sees Claude's notes alongside their own read of the diff. --fix skips the discussion step and applies the findings directly to your working tree (the files on disk in your local checkout). Used together or separately, these flags let you choose between a review that informs a human and a review that edits code on your behalf.

For anything higher-stakes, there is /code-review ultra. This launches a multi-agent review that runs in the cloud rather than locally: several agent instances examine the branch independently, and their findings are then adversarially verified, meaning one agent actively tries to disprove or poke holes in what another agent claimed before it gets reported to you. This catches the false positives that a single pass tends to produce. Note the naming history: this mode used to be called ultrareview as a standalone command; that alias is now deprecated (still recognized as of July 2026, but scheduled to go away, so switch your habits and any scripts to /code-review ultra). You can also target a specific pull request instead of your current branch: /code-review ultra 482 reviews PR number 482 directly.

Ultra review is not free past a point. As of July 2026, Pro and Max plan subscribers get three free ultra runs, after which each run costs roughly $5 to $20 in usage credits depending on the size of the diff being reviewed. For teams that want this in continuous integration (CI, the automated pipeline that runs on every push), there is a separate claude ultrareview subcommand meant to be called from CI scripts rather than interactively.

One hard requirement threads through all of this: you need a git repository (a folder tracked by git's version control system). The no-argument form of /code-review ultra bundles up your local branch and sends it for review, and it does not require a GitHub remote (a copy of the repository hosted on GitHub) to work; only the PR-number form needs the PR to actually exist on GitHub.

A sensible ladder: run plain /code-review at default effort while you are still writing code, as a cheap gut check. Bump to high effort right before opening a PR, when you want broader coverage even at the cost of a few uncertain findings. Reach for ultra on changes that are large, touch shared infrastructure, or worry you: the adversarial verification step earns back its cost when a second, or third, independent pass would catch something one pass would not. Whatever the depth, remember that a review finding is a hypothesis, not a verdict: reproduce the bug before you refactor around it.