32 Claude Code Tricks That Actually Change How You Ship
From /compact and plan mode to git worktrees and ultrathink, these Claude Code techniques reduce token waste and improve output quality at every level.
The Tricks That Separate Efficient Claude Code Users From Everyone Else
Most people use Claude Code the same way: type a request, wait for output, repeat. That works fine for simple tasks. But once you’re shipping real features — multiple files, stateful sessions, multi-agent runs — the defaults leave a lot on the table.
These 32 Claude Code tricks cover context management, prompting, parallel development, hidden commands, and workflow patterns. Some are obvious once you know them. Others come from source code analysis and power-user experimentation. All of them change how you work day to day.
Context and Token Management
Getting context management right is the single biggest lever on output quality. A bloated context produces worse code. A collapsed context loses work. Here’s how to stay in the productive middle.
1. Run /compact Before You Need It
Most users run /compact when Claude starts degrading — which is too late. The better habit is running it proactively, when you’ve completed a logical chunk of work but still have more to do.
/compact replaces the full conversation history with a structured summary, freeing up context window space. Running it at natural breakpoints (after finishing a feature, before starting a new module) keeps quality consistent. The full guide to /compact and context management walks through exactly when and how to trigger it.
2. Recognize Context Rot Before It Costs You
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
Context rot is what happens when Claude’s working memory gets too crowded with stale information. The symptoms: repetitive suggestions, regressing on earlier decisions, solutions that don’t account for constraints you already established.
The fix isn’t always /compact. Sometimes you need a fresh session. The signal to watch for is when Claude starts contradicting itself or ignoring things you told it two messages ago.
3. Use ultrathink for Hard Problems
Typing ultrathink in your prompt (no slash, just the word) pushes Claude to use extended reasoning on difficult problems. It’s significantly slower and uses more tokens, but for architectural decisions, complex debugging, or algorithm design, the output quality difference is real.
Reserve it for problems where a mediocre answer costs you an hour of debugging. Don’t use it for boilerplate.
4. Set Your Effort Level Explicitly
Claude Code has four effort levels: low, medium, high, and max. By default it picks one — but the default isn’t always right for your task. Explicitly stating the effort level in your prompt (“use low effort for this formatting fix”) saves tokens on small tasks and pushes quality higher on complex ones.
Understanding when to use each Claude Code effort level prevents the common failure of burning max compute on trivial requests.
5. Keep Your MCP Server List Lean
Every MCP server you have enabled gets included in Claude’s context on every request. Most users accumulate servers they don’t need active all the time. Disabling unused servers is free token savings — no prompting required.
The overhead cost of MCP servers adds up faster than most people expect, especially in long sessions.
6. Monitor Context Window Usage Actively
Claude Code shows context usage in the UI. Actually watching it — instead of waiting for degradation to appear in the output — lets you intervene before quality drops. When you hit roughly 70% full, that’s the time to either /compact or wrap up the session and start fresh.
For more on the mechanics, see this breakdown of the context window limit in Claude Code.
7. Use /btw for Mid-Task Questions
The /btw command lets you ask a question or add context without consuming a full turn in the conversation. If Claude is mid-task and you need to clarify something without interrupting the flow, /btw handles that without bloating the context.
It’s a small command with a meaningful impact on token efficiency. See the full breakdown of how /btw saves tokens mid-task.
8. Start New Sessions for Unrelated Tasks
This sounds obvious but gets ignored constantly. A Claude Code session is not a persistent assistant. It’s a context window. Using the same session for a bug fix, a documentation update, and a refactor means all three tasks share context — and none of them benefits from that.
New task, new session. It’s the simplest token management habit there is.
Planning and Prompting
Better inputs produce better outputs. These tricks change how you communicate intent to Claude before it writes a line of code.
9. Ask for a Plan Before Any Code
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
Before Claude writes anything, ask it to produce a written plan: what files will change, what approach it will take, and what edge cases it’s accounting for. Review the plan, correct it if needed, then tell it to proceed.
This one step catches misunderstandings before they become bad code that you have to debug and undo.
10. Use Opus Plan Mode to Front-Load Thinking
Opus plan mode uses the more capable Opus model specifically for the planning phase, then hands off execution to a faster model. You get Opus-quality architecture decisions without paying Opus prices for every line of code generated.
This is particularly useful for complex features where getting the approach right matters more than raw generation speed.
11. Front-Load Constraints, Not Just Goals
Most prompts describe what to build. The better prompts describe what to build and what not to do, what patterns to follow, and what existing conventions to respect. Constraints given upfront produce better first drafts than constraints given as correction after the fact.
Example: instead of “add authentication,” try “add authentication using the existing JWT pattern in auth.ts, no new dependencies, following the error handling pattern already in the codebase.”
12. Use the GSD Framework for Complex Tasks
The Get Stuff Done (GSD) framework breaks complex Claude Code work into three phases: gather context, specify the approach, then do the work. Each phase gets its own clean context state. This prevents earlier exploration from polluting later execution.
If you’re working on anything with more than a few moving parts, the GSD framework for clean context phases is worth reading.
13. Use /simplify When Output Gets Overbuilt
Claude has a tendency to over-engineer. Ask for a simple data fetch and you might get a full abstraction layer with retry logic and caching. The /simplify command tells Claude to produce the simplest working version — useful for prototypes and for calling out when the current approach has too much ceremony.
The /batch command handles the opposite problem: grouping multiple similar small requests into one efficient pass. Both commands are covered in the /simplify and /batch guide.
14. Write Detailed Failure Modes Into Your Prompts
Don’t just describe the happy path. Include what should happen when things go wrong. “Return an error if the user is not authenticated, use the existing UnauthorizedError class, don’t throw raw exceptions” produces more production-ready code than describing only the success case.
15. Ask Claude to Critique Its Own Output
After Claude produces something, ask it: “What’s wrong with this? What edge cases does it miss? What would a senior engineer flag in code review?” This often surfaces real problems before you catch them yourself. It works better than asking “does this look right?” — which almost always gets a yes.
16. Use the Advisor Pattern for Architecture Decisions
The advisor pattern uses a capable model (like Opus) in advisory mode to review decisions, then hands implementation to a faster, cheaper model. You’re not asking Opus to write code — you’re asking it to validate the approach.
The Claude Code advisor strategy with Opus and Sonnet is a practical pattern for keeping quality high without paying for premium compute on every task.
claude.md: Your Permanent Instruction Layer
17. Use claude.md to Avoid Repeating Yourself
The claude.md file sits at the root of your project and gets loaded into Claude’s context automatically on every session. It’s the right place for project-specific conventions, naming rules, architecture constraints, and anything you’d otherwise type repeatedly.
A well-maintained claude.md file is the highest return-on-effort setup task in Claude Code. Write it once, benefit on every session.
18. Keep claude.md Focused and Short
More content in claude.md doesn’t mean better output. A bloated instruction file consumes context and dilutes the most important rules. Keep it to conventions that actually vary from defaults — the things Claude would get wrong without being told.
If a rule applies to every project (like “write tests”), it’s not worth putting in the file. If a rule is specific to this codebase (like “all database queries go through the repository layer”), it absolutely belongs there.
19. Version-Control Your claude.md
This seems obvious but gets skipped. Your claude.md evolves as your project’s conventions evolve. Commit changes to it alongside the code changes that motivated them. Future team members will benefit, and you’ll be able to trace why certain rules exist.
20. Use Multiple claude.md Files for Monorepos
Claude Code supports project-level and directory-level instruction files. In a monorepo, you can have a root-level claude.md with global conventions and subdirectory files with package-specific rules. This lets you give frontend-specific and backend-specific instructions without mixing them.
Parallel Development and Multi-Agent Patterns
21. Use Git Worktrees for Parallel Work
Git worktrees let you run multiple Claude Code sessions on separate branches of the same repository, simultaneously, without conflicts. Each worktree is an isolated working directory. Claude in one worktree doesn’t know or care what Claude in another is doing.
This is the standard pattern for running parallel feature development. The git worktrees with Claude Code guide covers setup and workflow.
22. Use the Operator Pattern for Multi-Terminal Work
The operator pattern puts a coordinating Claude instance in charge of spinning up and directing multiple sub-agents in separate terminals. The operator doesn’t do implementation work — it manages task assignment, monitors progress, and handles blockers.
This is useful when you have a large feature that can genuinely be parallelized across independent concerns. The Claude Code operator pattern explains the setup.
23. Use the Split-and-Merge Pattern for Large Analysis Tasks
When you need Claude to analyze a large codebase, split the analysis across multiple sub-agents working in parallel. Each agent handles a subset of the code, produces a structured summary, and a final merge step synthesizes the results.
This avoids hitting context limits on large codebases while keeping the analysis coherent. The split-and-merge pattern is particularly useful for security audits, architecture reviews, and dependency analysis.
24. Use Headless Mode for Automated Pipelines
Headless mode runs Claude Code without an interactive terminal — useful for CI/CD pipelines, cron jobs, and automated code review. You pipe in instructions, Claude runs the task, and output goes wherever you direct it.
How Remy works. You talk. Remy ships.
If you’ve ever wanted Claude to run automatically as part of your deployment pipeline, Claude Code headless mode is how you do it.
25. Use Sub-Agents for Codebase Analysis Without Rate Limit Pain
Running a single large codebase analysis session often hits rate limits or context limits. Using sub-agents — each responsible for a module or directory — distributes the load and keeps each agent’s context clean. The sub-agents approach for codebase analysis prevents the common failure mode of one massive context that collapses midway.
26. Commit Checkpoints Before Handing Off Between Agents
When one agent completes a phase and another takes over, commit the current state first. This gives the next agent a clean baseline, makes it easy to roll back if something goes wrong, and keeps the git history readable.
Hidden Commands and Features
27. think, think hard, think harder, ultrathink
These are prompt modifiers that increase Claude’s reasoning depth. “think” adds some extended reasoning. “think hard” adds more. “think harder” pushes further. “ultrathink” goes to maximum. Each step uses more tokens and time — but for genuinely hard problems, the quality difference justifies it.
28. Use Auto Mode for Safer Autonomous Runs
Auto mode gives Claude permission to take actions autonomously without asking for confirmation at each step, but it’s safer than using bypass permissions flags. It’s scoped appropriately so Claude can work autonomously without being fully unguarded.
The distinction matters for production use. Claude Code auto mode is the right choice for most unattended runs.
29. /bug for Faster Bug Reports
Typing /bug opens a structured bug report flow that captures context, the current state of the session, and what went wrong — without you having to summarize it manually. If you’re hitting a Claude Code issue and want to report it, this is faster than writing it out by hand.
30. Hidden Features From the Source Code Leak
The Claude Code source code became public, revealing several features that aren’t prominently documented. These include internal configuration options, undocumented slash commands, and agent behavior flags. The 8 hidden features from the Claude Code source code leak covers what’s there and what’s actually useful.
31. The Buddy Feature (Yes, Really)
Claude Code has a Buddy feature — essentially a Tamagotchi-style companion that reacts to your coding activity. It’s an easter egg, not a productivity feature. But it’s real, it’s charming, and if you spend enough time in the tool it’s worth knowing about. The full story on Claude Code Buddy explains how it works.
32. Run Claude Code Free With Ollama or OpenRouter
If you’re hitting cost limits or want to experiment without a subscription, Claude Code can run against local models via Ollama or through OpenRouter for cheaper model access. Output quality varies depending on the model, but for many tasks the results are good enough. The guide to running Claude Code free with Ollama and OpenRouter walks through the setup.
Workflow Patterns That Hold Up at Scale
Batch Small Tasks Together
When you have ten small, independent tasks — fix a typo, rename a variable, add a comment — group them into one prompt using /batch instead of running ten separate sessions. The overhead of session setup multiplied by ten is real. Batching similar tasks reduces that friction significantly.
Start Complex Tasks With a Research Phase
Before writing any code, give Claude a dedicated research phase: “Read these files and tell me what you understand about the current architecture. Don’t write any code yet.” The output of this phase becomes your spec for the next phase. This prevents Claude from jumping to implementation before it understands the constraints.
This is essentially the 5 workflow patterns from sequential to fully autonomous — each pattern suited to a different task complexity level.
Use Structured Output Formats for Handoffs
When one Claude session needs to hand work to another, tell it to produce output in a specific structured format: a summary of what was done, what’s left, and what state the codebase is in. This makes the handoff clean. Free-form summaries leave too much ambiguity for the next session to work from.
Keep a Task Log File
Have Claude maintain a TASK.md file during long sessions. At each step, it updates the file with what was completed, what’s in progress, and what’s next. If the session dies or you /compact, the task log gives you a clean resumption point without depending on conversation history.
Where Remy Fits in This Picture
Claude Code is a powerful tool for working within existing codebases — and these tricks make it significantly more effective. But there’s a layer above this that changes the starting point entirely.
Remy takes a different approach. Instead of working at the code level, Remy works from a spec — a structured markdown document that describes what the application does. The code is compiled output from that spec. You’re not prompting an AI to edit TypeScript line by line. You’re defining the application in a format that both humans and agents can read and reason about.
This matters for the context problems described throughout this article. When the spec is the source of truth, there’s no context rot from accumulated edits. There’s no session management overhead from trying to keep Claude oriented in a large codebase. The spec stays in sync with the code because the code is derived from it.
For teams building full-stack applications — backend, database, auth, deployment — Remy compiles all of that from the spec. It runs on the same infrastructure foundation as MindStudio, which means 200+ models, production-grade databases, and real deployment from day one.
If you’re spending significant time managing Claude Code sessions, compacting context, and maintaining instruction files, it’s worth seeing what working from a higher abstraction level looks like. You can try Remy at mindstudio.ai/remy.
Frequently Asked Questions
What is the most important Claude Code trick for long sessions?
Running /compact proactively — before quality degrades — is the highest-impact single habit. It extends usable session length without losing work. Combine it with a claude.md file for persistent context that survives compaction, and you’ve addressed the two biggest failure modes in long sessions.
What does ultrathink actually do in Claude Code?
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
Ultrathink is a prompt modifier that tells Claude to use extended reasoning on a problem. It increases computation time and token use significantly, but for hard problems — architecture decisions, complex debugging, tricky algorithm design — the output quality is meaningfully better. Don’t use it for routine tasks.
How do git worktrees help with Claude Code?
Git worktrees let you maintain multiple working directories of the same repository simultaneously, each on a different branch. With Claude Code, this means you can run separate agent sessions on separate features in parallel, with no risk of one session’s changes conflicting with another’s. It’s the foundation of parallel agentic development.
What is plan mode in Claude Code?
Plan mode separates the planning phase from the execution phase. Claude uses a capable model to develop the approach, then hands off to a faster model for implementation. This produces better architectural decisions without paying premium compute costs for every line generated. It’s particularly useful for complex features where the approach matters as much as the output.
How do I stop Claude Code from over-engineering solutions?
The /simplify command is the direct answer — it tells Claude to produce the simplest working version. Front-loading constraints in your prompt (“no new dependencies,” “follow existing patterns”) also helps. For recurring issues, add a simplicity rule to your claude.md file so it applies to every session automatically.
Can Claude Code run without a terminal or interactive session?
Yes. Headless mode runs Claude Code autonomously without a terminal, making it suitable for CI/CD pipelines, scheduled tasks, and automated workflows. You provide instructions programmatically, Claude executes the task, and output is captured programmatically. It’s how teams integrate Claude Code into their deployment and review processes.
Key Takeaways
- Context management is the biggest lever on output quality. Use
/compactproactively, watch your context window usage, and start fresh sessions for unrelated tasks. - Planning before coding consistently produces better output. Ask for a written plan, review it, then proceed. Use plan mode for complex features.
claude.mdis the highest return-on-effort setup task. Write it once, keep it focused, and benefit on every session.- Parallel development with git worktrees removes the biggest bottleneck in multi-feature development — one session blocking another.
- Effort modifiers (think, ultrathink) and slash commands (/btw, /simplify, /batch) give you fine-grained control over what Claude does and how much it costs.
- Multi-agent patterns (operator, split-and-merge, headless) handle work that’s too large or complex for a single session.
These tricks work well together. The teams shipping most effectively with Claude Code aren’t using any one trick — they’re combining context discipline, good prompting habits, a well-maintained claude.md, and parallel patterns for large tasks.
And if you’re at the point where managing all of that feels like more overhead than the tool saves, it might be time to look at working from a higher level. Remy starts from the spec, not the code — and that changes the entire shape of the problem.
