Claude Code ships changes every week. There is a changelog for it, and it pays to open it with the right mindset: what you learned last month may have moved. A command gets renamed, a feature lands in preview, a new model bumps the one you were using.
But even here, in the middle of the AI whirlwind, some things don't move. Or they move slowly, because they have hardened into fundamentals. That is what this is about. The parts you will still be using six months from now, kept apart from what goes stale in two weeks.
And I will own it: I am not going to hand you commands that break tomorrow. I will give you the mental model that holds, and a link to the tip for today's specifics.
I write this from practice. I am a software engineer and I use Claude Code in production, daily, for hours on end. And although I use Claude Code as the example, almost everything here has an equivalent in other AI harnesses, so the knowledge carries well beyond this one tool.
One more thing, the one that justifies the whole piece. Claude is so useful that it reaches a result fast even when you drive it wrong. It works, so you never notice you are doing it wrong. Day 1 is not about launching it, that part is easy. It is about learning the invisible plumbing: where your sessions live, how your quota resets, how context fills up and quietly drops what you told it. A little strategy and the whole thing flows better.
Getting started
CLI, Desktop, extension, or ACP: pick how you get in
They are not different products. They are not different agents. The core is the same across all of them: the same agent, the same tool loop, the same CLAUDE.md, the same hooks, the same MCP setup, the same models. What changes is the interface (how you see and review what the agent does) and how the workspace is managed (how sessions and files are laid out). This matters more than it looks on day 1: switching surfaces is not learning a new tool. Your config travels with you and your instinct for how the agent behaves travels with you. What you learn in one carries to the rest.
There are four ways in today. The CLI in the terminal, closest to the code. The desktop app (what it adds over the CLI), on macOS and Windows for now, with Chat, Cowork, and Code tabs, built for reviewing changes visually. An extension inside your editor: the VS Code one is official and ships a native panel, but it is not the only one. And, most recent, ACP (Agent Client Protocol), an open standard that Anthropic implements with its own adapter so Claude Code runs inside editors that have no official extension: Zed, Neovim, JetBrains, or Emacs talk to the agent over that protocol. The practical upshot is that you no longer depend on an extension existing for your editor of choice.
So the day-1 advice is to pick one way in and get good at it. Because Claude works even when you use it wrong, splitting your attention across several interfaces leaves you shallow in all of them without realizing: each gives you a decent result, none teaches you to get real leverage. Mastering one beats spreading yourself across four. To choose, look at where you already work: the terminal, a separate app, or the editor you already have open. That is the question. Where you feel at home.
Installing and the first run
How you install Claude Code decides whether it keeps itself current or quietly freezes. The native installer updates itself in the background; a package manager (Homebrew, apt) and npm do not. Claude Code ships new things every few weeks (skills, subagents, new commands), so installing the wrong way means falling behind without noticing: you go months without a single new feature and assume the tool just is that way.
That is why the native install is worth it. Both npm and package managers hand you a binary that does not update on its own; the native installer hands you a self-contained one that does, and that keeps your CLAUDE.md and settings compatible across versions, so the cost of staying current is basically zero. It is what Anthropic recommends. The exact steps depend on your OS (macOS, Windows, or Linux) and are not worth memorizing: you have them in the what is Claude Code guide, and the mechanics of keeping it current (auto-update, channels, what to do if you installed it with a package manager) are in the how to update tip.
The first run is simpler than it sounds. You open a terminal inside your project folder, run claude, and it asks you to authenticate with your account. From there you are in the session, in that directory. Launching the command from inside the project matters, because Claude Code works against the directory it starts in, and that is where the conversation will live (the per-directory part shows up in detail in the sessions chapter). To confirm everything is fine, claude --version tells you which version you are on, and if something behaves oddly at the start, /doctor checks the install, the version, and the config before you lose an hour poking around in the dark.
CLAUDE.md and /init: give the project context
Without a memory file, Claude Code starts every session blind. It reads the code you point it at, but it guesses about the rest: which framework you use, which architecture decisions are already made. And sometimes it guesses wrong. The classic case is proposing or installing Express in a project that already runs on Next, because nothing told it otherwise. The tool is not dim. It was missing the context you took for granted.
CLAUDE.md is that context. A file at the repository root that Claude reads when each session starts. To generate it you run /init: it scans the codebase, detects the build system, the frameworks, and the tests, and leaves you a first version you then edit. The property that makes it essential on day 1 is that CLAUDE.md loads at the start of every session and survives compaction. When the context window fills and Claude summarizes the old parts to make room, your chat instructions can thin out or vanish. The ones in CLAUDE.md do not. So it is the place for the rules you never want to repeat: the ones that must still hold at message one and message one hundred.
Longer is not better. A bloated CLAUDE.md gets half-ignored: every needless line spends context and buries the instructions that actually matter. Keep it tight (the working rule is around 200 lines) and save the room for what Claude cannot infer from the code: business decisions, team-specific conventions, the reasoning behind each rule. What is already in your package.json or your folder structure does not need to be here. How to write it, what to cut, and how to modularize it with imports is laid out step by step in the configure your CLAUDE.md tip.
Sessions
They live per directory (and how to get them back)
Almost everyone's first confusion is the same. You work a whole afternoon with Claude Code, close the terminal, come back the next day from a different folder, and the conversation is gone. Not the last one, not the history. It looks lost. Nothing is lost: conversations live tied to the directory you started them in. If you cd somewhere else in the project, or open the terminal at a different spot, Claude Code looks there and does not find what you left in the previous folder. It is there, just not where you are looking.
From there, a handful of handling basics. You can rename and color your sessions to tell them apart, and ask for a session recap when you come back after a while. Do not conflate two things that sound alike: branching with /branch makes a copy of the conversation to try another path, while rewinding with /rewind rolls the state back inside the same session. And to stop: Esc interrupts the running turn and hands you back control to redirect without starting over.
Rename and color them so you can tell them apart
/rename gives a session a name (it shows up on the prompt bar). Color sets it apart at a glance. None of this matters with one session open. It starts mattering the moment you have three or four going at once and the picker turns into a wall of look-alikes. The rename and color tip covers both.
Ask for a recap when you come back
You drop a task on Friday and pick it up Monday. The history is there, but your head is not. A session recap catches you up on what was decided and where it stopped, so you spend the first minute working instead of rereading scrollback. Small habit, real difference when you juggle several threads across days.
Branching (/branch) is not rewinding (/rewind)
Two things that sound alike and do opposite jobs. /branch (or --fork-session from the CLI) makes a copy of the conversation so you can try another direction, and the original stays put. /rewind (Esc twice on an empty prompt) rolls back the state, code or conversation or both, inside the same session. There is no copy and no second path: you undo, the state you land on replaces the current one, and whatever was ahead is gone. It is the panic button for when Claude went sideways and you would rather step back to a good checkpoint than keep patching something already bent. (There is a related but separate command, /fork, that delegates to a background subagent instead of switching you, worth knowing once branch and rewind are clear.)
Context
/context: see what's filling your window
Context is the session's working memory, and it is finite. As you work it fills, and when it nears the limit Claude compacts it: it summarizes the old parts to free room, and that is where detail gets lost (what the beginner experiences as "it suddenly got dumber"). /context shows you what is taking up space: conversation, files, tool output, loaded skills. It is the first thing to check when the agent starts feeling vague.
/compact versus /clear
Two ways to clear room, and they are not interchangeable. /compact summarizes by hand (with an optional focus); auto-compact clears old tool outputs first and then summarizes as you near the limit. /clear wipes the window completely (saved and resumable), which is what you want when you switch to an unrelated task. Rule of thumb: clear between unrelated tasks, compact when continuity matters. Whatever must not be lost goes in CLAUDE.md, which survives either way. There are also five ways to feed context beyond @.
Drift and the 1M mirage
Drift is when your early context (the instructions you gave up front) gets lost as the window reloads or compacts. Even with the 1M-token window available, more context is not better: relevance degrades well before the limit, and a large chunk of the window goes to file reading, which is exactly what forces compaction. The fix is not a bigger window, it is keeping the window honest: prune what you no longer need, and pin the non-negotiables in CLAUDE.md.
Models and quota
Pick the model for the task
You pick a model by the task. The sonnet alias is the sane default; you save the big one (opus) for the hard stuff, because picking the right model is the number-one lever on your usage. You can set your default model and reach for the picker with /model mid-session. Model names rotate over time, so take this as today's lineup, not a law.
Effort: how hard it thinks
/effort sets how much the model reasons: low, medium, high, xhigh, max (high is the default for most). More effort means more tokens. Turn it up for the genuinely hard problems and down for the trivial ones, instead of paying max reasoning for a one-line change.
/usage: your quota meter
/usage shows your session and your plan bars, broken down by skill, subagent, and MCP, with a d / w toggle for the last 24 hours or 7 days. One caveat: the dollar figure is a local estimate from this machine only, it does not include other devices or claude.ai. Treat it as a gauge, not your invoice.
Quota: several clocks at once (the part that's hard to grasp)
This is the piece I never fully understood at first either. It is not one counter, it is several clocks running at once. A 5-hour window that is rolling (it starts with your first message and renews 5 hours after that start, it is not a wall clock). Above it, two weekly limits that reset at a fixed time assigned to your account. It all comes out of one shared pool across claude.ai, the desktop app, and Claude Code, and the CLI's /usage is computed locally, so it runs behind the real server-side counter and sometimes cuts you off earlier than the terminal suggests. What drains it fastest: the model (Opus costs far more than Sonnet), long sessions, and breaking the cache. I break the whole thing down, minus the Reddit myths, in usage limits: the 5-hour window and the weekly cap. The exact numbers per plan are not published and get bumped now and then, so always check your own bars rather than trusting a figure you read somewhere.
Prompting and permissions
A good prompt: specific and verifiable
The day-1 temptation is to write the way you would to a teammate who already knows the project: "fix the login." Claude Code knows nothing about your project beyond what you give it. A good prompt is not a short, elegant order, it is a brief with enough context that the result resembles what you had in your head. Three ideas hold up everything else, and none of them will expire with the next release.
Be specific up front. Name the files you want it to work on instead of letting it guess by reading half the repo. State the constraints that matter: "do not touch the public API," "match the pattern in the other components," "no new dependencies." If there is already an example of how something is done in your code, point at it: "build the payments endpoint following the users one." Every input you give it is a decision it does not have to invent, and inventing is when it drifts. The gap between "add validation to the form" and "add validation to the form in RegisterForm.tsx using the schema in auth/schemas.ts, same as LoginForm.tsx" is the gap between reviewing its work and redoing it.
Give it something to check against. Claude does better when it can verify its own work instead of handing you something blind. That means giving it an objective bar for "this is right": a test that has to pass, the exact output you expect from a command, a screenshot of how the screen should look, an error that has to disappear. With a verifiable target, it runs, looks at the result, corrects, and tries again without you stepping in on every lap. Without one, it brings you code that looks right and you find the bug later, when it costs more to fix. If you have tests, mention them. If you do not, describe in a sentence how you will know it works.
It is a conversation, not a one-shot. The beginner mistake is to cram everything into one perfect mega-prompt and accept whatever comes out. It works better the other way around: you start with what you want, look at what it does, and refine with follow-ups. "Good, now pull that logic into a hook." "You missed the empty-list case." "Rename it, that name does not fit the rest." You are not correcting a machine that failed, you are steering a process that is iterative by nature. If a task is large or carries design decisions, plan mode lets you agree on the plan before it writes a line, where changing course is cheaper than doing it over the finished code.
The thread tying the three together: you cut down what Claude has to guess. Specific cuts the guessing about the what. Verifiable cuts the guessing about whether it is done right. And conversing removes the last guess, the one about what you actually wanted. A vague prompt also produces something, and almost always something that looks finished. That is why this is the habit that pays back the most on day 1. If you want the concrete rules Anthropic follows for this, the five are in prompts in Claude Code: the 5 rules Anthropic follows.
Stopping and redirecting a turn
When Claude Code kicks off a turn and you see it going the wrong way (editing the wrong file, misreading the task, rewriting half a module when you wanted a tweak), the first instinct is usually the bad one: kill the whole process with Ctrl+C and start over. That throws away the context and the work already done. The right way to cut a running turn is Esc: it interrupts the current response or tool call, keeps everything Claude had done up to that point, and hands you back control to type the correction. It does not reset the conversation. It does not lose the progress. It just stops and waits for your next instruction.
This is "steer, don't fire" in daily form. A turn is not a command you launch and watch from afar. It is an execution you are supervising, and supervising includes stepping in. You hit Esc, read what it did, and tell it "no, wrong file" or "stop, I want to see the plan first." Claude resumes from where you left it with the correction folded in, not from scratch. The sooner you interrupt, the less wrong work you have to undo later: cutting at ten seconds is cheap, letting it finish and then reverting five files is not.
Three shortcuts look the same and are not. Esc interrupts the turn and keeps the work. Ctrl+C is a different thing: if Claude is working, it interrupts it; but if nothing is running, the first press clears whatever you have typed and the second closes Claude Code (same as Ctrl+D). And there is /stop, which is a real command, but it ends a session running in the background (the agent view), it does not cut the turn in front of you. For everyday use, the one you reach for is Esc. These shortcuts can change behavior between versions, so if one does not respond the way you expect, check it against the official Claude Code docs, which keep the key table current. The full breakdown of each shortcut and when to use it is in stop and redirect Claude mid-task.
A useful variant of the same idea: sometimes you do not want to stop the turn, just ask something mid-work without interrupting. For that, /btw opens a side question that Claude answers with the full session in view, without reading files or running anything, without entering the thread and without slowing down what it is doing. Steering does not always mean cutting. Sometimes it means asking while it keeps moving. But when it really is off track, Esc and redirect. No reset, no starting over.
Plan mode: review before it executes
Before a big change, plan mode: Claude explores and proposes a plan without touching files, and you review and refine it before it executes. It saves expensive rework when the initial direction is wrong. You cycle into it with Shift+Tab. The plan mode tip covers when it earns its place and when it just slows you down.
Permissions without the fatigue (Shift+Tab)
Shift+Tab cycles the modes: normal, auto-accept edits, plan mode. The fatigue of approving every single edit goes away with acceptEdits plus allow rules. It is the same Shift+Tab as plan mode, so the two live on the same toggle. The permission modes tip lays out the trade-offs so you loosen the right things, not everything.
The extensibility map
What each thing is: orchestrator, subagent, skill, plugin, hook, MCP
Beginners blur six terms that are worth separating early, and the axis that splits them is what triggers each one. The orchestrator (the main agent) is the primary loop you talk to. A subagent is a separate worker the main agent spawns, with its own context. A skill is knowledge (a SKILL.md) the model pulls in when it is relevant, or by slash command (the two have merged). A hook is a command the system runs on its own, deterministically, on an event (PreToolUse, PostToolUse, Stop), typically a shell command but it can be HTTP, MCP, an LLM, or a subagent. MCP is a protocol that connects external tools and data (over stdio or HTTP). A plugin packages several of those things (skills, commands, agents, hooks, MCP) so they can be distributed through a marketplace. The one-liner to keep: a hook runs on its own, a skill is knowledge the model brings in, a subagent is a worker with its own context, MCP adds external tools, a plugin bundles several, a slash command is a saved prompt. The full side-by-side is in the 6 extension points everyone confuses, with dedicated guides for MCP, skills, hooks, and subagents.
Day-1 productivity
Status line: your state at a glance
The bottom bar is painted by a script you own, and it shows model, context, cost, and branch at a glance. Small thing, you feel it from day one. The status line tip has the script.
The slash command cheat sheet
There are roughly eighty slash commands, and the docs list them alphabetically. The slash command cheat sheet groups them by what you are trying to do, which is the order you actually think in. Keep it within reach the first week.
Bash mode with !
Type ! in front and you run shell commands without leaving Claude Code, with the output landing in the conversation. It is the fastest way to check a git status or run a build mid-task without breaking your flow. The bash mode tip has the details.
/doctor when something's off
/doctor diagnoses install and config problems (MCP, permissions, hooks) before you start hunting your error in forums. It is the first thing to run when the setup feels wrong rather than the task.
Day 2: once you're moving
Agent view
Once you have the hang of it, the next step is working in parallel. Agent view (claude agents) gives you one screen for several agents at once. It is a research preview today (v2.1.139+) and the interface may change, and each session burns quota independently, which is why it belongs in "day 2" rather than the day-1 core.
Worktrees for parallel tasks
Worktrees let you run parallel tasks on separate branches without stepping on yourself. It is day-2 material, for when the fundamentals no longer take up room in your head.
The takeaway that doesn't expire
The structure does not change: sessions live per directory, context fills and compacts, quota is several clocks, you pick the model by the task. The numbers and the names do change, and that is why the specifics live in the tips, which I keep current on their own. That is what I am betting on: this still holds six months from now.
The curve is steep at the start. Push through it, and lean on the Anthropic documentation, which is genuinely good. I write a Claude Code tip every day, in case you want to keep up without chasing the changelog on your own.