Claude dynamically allocates thinking based on the problem. Use it for architecture decisions, tricky debugging, multi-step reasoning, or anything where you want Claude to think before acting. You can also set effort permanently with /effort. For less complex tasks, lower effort levels keep things fast and cheap. Match the effort to the problem. There's no point burning thinking tokens on a variable rename. 8. Leverage skills for on-demand knowledge Skills are markdown files that extend Claude's knowledge on demand. Unlike CLAUDE.md which loads every session, skills load only when relevant to the current task. This keeps your context lean. Create skills in .claude/skills/ or install plugins that bundle pre-built skills (run /plugin to browse what's available). Use skills for specialized domain knowledge (API conventions, deployment procedures, coding patterns) that Claude needs sometimes but not always. 9. Control Claude Code from your phone Run claude remote-control to start a session, then connect to it from claude.ai/code or the Claude app on iOS/Android. The session runs locally on your machine. The phone or browser is just a window into it. You can send messages, approve tool calls, and monitor progress from anywhere. If you're using the cc alias from tip #1, Claude already has full permissions and won't need approval for each action. That makes remote control even smoother: kick off a task, walk away, and check in from your phone only when Claude finishes or hits something unexpected. 10. Extend your context window to 1M tokens Both Sonnet 4.6 and Opus 4.6 support 1M token context windows. On Max, Team, and Enterprise plans, Opus is automatically upgraded to 1M context. You can also switch models mid-session with /model opus[1m] or /model sonnet[1m]. If you're concerned about quality at larger context sizes, start at 500k and work up gradually. Higher context means more room before compaction kicks in, but response quality can vary depending on the task. Use CLAUDE_CODE_AUTO_COMPACT_WINDOW to control when compaction triggers, and CLAUDE_AUTOCOMPACT_PCT_OVERRIDE to set the percentage threshold. Find the sweet spot for your workflow. 11. Use Plan Mode when you're not sure how to approach something Use Plan Mode for multi-file changes, unfamiliar code, and architectural decisions. The overhead is real (a few extra minutes upfront), but it prevents Claude from spending 20 minutes confidently solving the wrong problem entirely. Skip it for small, clear-scope tasks. If you can describe the diff in one sentence, just do it directly. You can switch into Plan Mode anytime with Shift+Tab to cycle between Normal, Auto-Accept, and Plan permission modes without leaving the conversation. 12. Run /clear between unrelated tasks A clean session with a sharp prompt beats a messy three-hour session. Different task? /clear first. I know it feels like throwing away progress, but you'll get better results starting fresh. Sessions degrade because accumulated context from earlier work drowns out your current instructions. The five seconds it takes to /clear and write a focused starting prompt saves you from 30 minutes of diminishing returns. 13. Stop interpreting bugs for Claude. Paste the raw data. Describing a bug in words is slow. You watch Claude guess, correct it, and repeat. Paste the error log, CI output, or Slack thread directly and say "fix." Claude reads logs from distributed systems and traces where things break. Your interpretation adds abstraction that often loses the detail Claude needs to pinpoint the root cause. Give Claude the raw data and get out of the way. This works for CI too. "Go fix the failing CI tests" with a paste of the CI output is one of the most reliable patterns. You can also paste a PR URL or number and ask Claude to check the failing checks and fix them. With the gh CLI from tip #6 installed, Claude handles the rest. You can also pipe output directly from the terminal: bash cat e