Control and Modes: The 'Mixing Console' in Your Hands During a Session
📚 Series Navigation: The previous article 34 CLI Reference: Commands and All Flags helped you check all the switches you can flip "before starting Claude". This article switches to after the "session has started"—during the back-and-forth process between you and Claude, you actually hold an entire "console" in your hands: how to press a key to switch its working mode, how to make it produce a plan first without rushing to act, how to spend money for faster responses, and how to use Vim gestures to edit your input. Article 20 covered the reins of permissions, while this article covers the full set of joysticks in your hands.
Brothers, after all this way, we know how to type commands, write CLAUDE.md, and configure permissions. It should be pretty smooth by now.
But looking back, more than half of the time wasted in the first month wasn't because we "didn't know how to use it," but because we "didn't know how to control it"—the session is clearly running, but we only know how to do one thing: type, press Enter, and wait. When its output goes off track, we foolishly wait for it to finish; when it starts modifying files right away, we fail to stop it; for tasks where it should have produced a plan first, we just let it go in and mess things up.
To put it bluntly, Claude Code's interactive interface is far more than just "an input box + Enter". Hidden underneath is an entire set of "in-session control methods": a key to switch its working mode, a key to pull it back from going off track, a command to make it plan before acting, and a switch to buy speed with money. Some of these showed their faces as shortcuts in Article 14, and Article 20 thoroughly explained the permission branch, but "how to manipulate it in a session" has never been laid out in a centralized way.
Let's put it this way: The previous articles taught "how to make Claude work," while this article teaches "how to manipulate it in real-time during work"—like sitting in front of a mixing console, you shouldn't just know how to press play, but be able to touch every fader.
After reading this article, you will get:
- A panoramic view of "in-session control methods"—which key controls interruption, which key switches modes, which key changes models, clear at a glance.
- The full picture of the
Shift+Tabpermission mode cycle: howauto/bypassPermissions/dontAskenter the cycle outside the default three gears, and who comes before whom (following up on Article 20, without repeating permission rules). - Plan Mode is not just "a permission mode", but a workflow of "produce a plan first, act after you review"—when to use it, and what those options mean during approval.
- What exactly you are buying with fast mode, whether it's worth it, and how it differs from "effort level".
- How to turn on Vim editing mode, a few of the most practical gestures, and a hands-on exercise you can follow.
01 Build a General Framework First: The Switches You Can Flip in a Session Fall into Three Categories
Before you start memorizing shortcuts, first categorize the "in-session control methods" in your head. They are not a bunch of scattered keys, but manage three different things. Once the categories are clear, it will be easier to remember them later.
Analogy: Sitting in front of a mixing console. The densely packed faders and knobs on that big console in a recording studio look intimidating, but they really just fall into three categories: one category controls "the volume of this channel" (faders), one controls "whether to record the whole section or stop, and where to go back to re-record" (transport keys), and one controls "how to adjust the tone" (EQ knobs). You don't need to memorize all of them, but you need to know "where to reach your hand if you want to do this thing." Claude Code's session controls are the same; the three categories of switches each manage their own area.
Applied to Claude Code, these three categories are:
- Managing "its autonomy"—namely, permission modes:
Shift+Tabcycles throughdefault/acceptEdits/planwith one click, deciding whether it asks you before acting (Article 20 is the main focus here). - Managing "its running process"—interruption and redirection:
Escto hit the brakes,Esc Escto reverse and rewind,Ctrl+Cto interrupt or clear input,Ctrl+Bto throw tasks to the background. - Managing "how it responds"—models and speed:
Option+Pto change models,Option+Tto toggle extended thinking,/fastto toggle fast mode.
Putting them in a table side-by-side makes it clear what each manages:
| What you want to do | Reach out and press | Which category it belongs to |
|---|---|---|
| Let it ask less / more before acting | Shift+Tab to cycle modes | Manages autonomy |
| It went off track, call a halt to say it again | Esc | Manages process |
| Rewind the entire conversation to a previous point | Esc Esc (when the input box is empty) | Manages process |
| Interrupt the current operation / clear the input box | Ctrl+C | Manages process |
| Throw long commands to the background and continue with other things | Ctrl+B | Manages process |
| Temporarily switch to another model to answer | Option+P (Win/Linux is Alt+P) | Manages response |
| Let it think longer / don't think too long | Option+T | Manages response |
| Spend money to buy a faster Opus | /fast or Option+O (macOS) / Alt+O (Win/Linux) | Manages response |
⚠️ macOS users read this first: For those shortcuts starting with
Option+in the table (Option+P,Option+T,Option+O), on Mac, you usually need to configure the terminal's Option key as the Meta key first for them to take effect—in iTerm2, under "Settings → Profiles → Keys", set the left/right Option to "Esc+"; in Apple Terminal, under "Settings → Profiles → Keyboard", check "Use Option as Meta key". The official documentation notes an exception: starting from v2.1.132,Option+T(toggle extended thinking) on Mac can be used without configuration.
You don't need to memorize this table, but you must have the awareness of "which category this belongs to"—if you want to "let it ask less," don't press Esc; if you want to "call a halt," don't press Shift+Tab. Once you differentiate them, you won't grab blindly.
💡 One-sentence summary: The control methods in a session fall into three categories—managing autonomy (
Shift+Tab), managing process (Esc/Ctrl+C/Ctrl+B), managing response (Option+P//fast); it doesn't matter if you can't remember the specific keys, just remember "where to reach your hand to do this."
02 Managing Process: Esc is the Brake, Esc Esc is the Reverse
Among the three categories, the one you should practice the most is "managing process", because it saves the day the most frequently. Let's pick out the most commonly used ones and explain one by one "when to press it, and what happens when you press it".
Esc: It went off track, hit the brakes
Esc does one thing: stops what Claude is currently doing—whether it is generating an answer or halfway through calling a tool. When pressed, it stops immediately, and then hands the cursor back to you, waiting for you to speak again.
The key is this reassuring official statement:
Stops the current response or tool call mid-way so you can redirect. Claude keeps the work completed so far.
That is to say, Esc is not "undo", it is "pause + return the steering wheel". The parts it has already finished (like files already read, half a function already written) are kept; you just interrupt its next move, change direction, and let it continue.
The most common scenario for Esc: you ask it to change a small feature, but it misunderstands and starts grinding away making major changes to five or six files. If you foolishly wait for it to finish before correcting it, you waste minutes of its output for nothing; the smart way is—as soon as you see the direction is wrong, immediately press Esc, and then add a sentence "Stop, I just want to change that one function in login.js, don't touch anything else," and it turns around right there. Under heavy use, you conservatively have to press this single key dozens of times a day.
Esc Esc: Rewind the conversation to a previous point
Double-tapping Esc has two behaviors, depending on whether there is text in your input box:
- There is text in the input box: Double
Escclears it, and saves this draft into history, so you can still recall it by pressing↑later. - The input box is empty: Double
Escopens the rewind menu—letting you restore from a previous node in the conversation, or summarize the code and conversation.
The second one is "reversing": rewinding the entire conversation back to some previous state. This falls under the scope of checkpoints, which is specifically covered in Article 37. Here you just need to remember one action: when the input box is empty, double-clicking Esc can lift the menu for "returning to the previous save point". This is often used when reworking—feeling that "the last few rounds led things into a ditch," double Esc to rewind to a clean point before the ditch, and speak again.
Ctrl+C and Ctrl+D: Stop pressing them blindly as exit keys
These two are the easiest for beginners to mix up. Let's nail them down one by one:
Ctrl+C: If an operation is running, interrupt it; if no operation is running, the first press clears the input box, pressing it again exits Claude Code.Ctrl+D: Directly exits the Claude Code session (EOF signal).
There is an easy pit to fall into here: you want to clear text halfway typed in the input box, so you casually Ctrl+C, get no response, and do it again—resulting in directly exiting the session. The reason is that the second Ctrl+C on an empty input box is an exit. So to clear the input box, you would rather use Ctrl+U (delete from cursor to the start of the line) or simply Esc Esc, and don't easily double-tap Ctrl+C.
Ctrl+B: Throw long commands to the background, don't just wait
This rescue is also fierce. When Claude runs a command that takes a long time (installing dependencies, running builds, starting a dev server), you don't have to just wait—press Ctrl+B to throw it to the background. Claude immediately frees its hands to respond to your new instructions, that command continues running in the background, outputs are written to a file, and it reads them back when needed.
Brothers using tmux, take note: tmux's own prefix key is also
Ctrl+B, so in tmux you have to press it twice to throw a task to the background. This point is very easy to get trapped by; remember it well.
| Key | One-sentence function | Most easily misremembered point |
|---|---|---|
Esc | Call a halt + redirect, completed parts are kept | Not an undo, it's a pause handing back the steering wheel |
Esc Esc | Opens rewind menu when input box is empty | Clears draft when there's text, behaviors differ |
Ctrl+C | Interrupt operation / clear input / press again to exit | The second press on an empty box exits |
Ctrl+D | Directly exit session | Exits with one press, don't use as an interrupt key |
Ctrl+B | Throw long commands to the background | Press twice in tmux |
💡 One-sentence summary:
Escis the brake (pull back if off track),Esc Escis reverse (rewind to previous point), don't double-tapCtrl+Cblindly (second tap on an empty box exits), and useCtrl+Bto throw long commands to the background—once these four become muscle memory, you will never wait dryly or exit by mistake in a session again.
03 Managing Autonomy: The Complete Version of Shift+Tab Cycling Modes
The spectrum of permission modes from "strict to loose" was thoroughly explained in Article 20—default asks step-by-step, acceptEdits modifies code without asking, plan only looks and doesn't act, auto is backed by a classifier, bypassPermissions runs completely naked, and dontAsk only recognizes pre-approvals. This section won't re-explain what each of them is (if you forgot, flip back to Article 20), but only fills in one thing that wasn't detailed in that article: how exactly does this Shift+Tab cycle turn?
Let's establish the baseline first: pressing Shift+Tab casually in a session cycles through three modes:
default → acceptEdits → plan → (press again to return to default)Which gear it is currently in, look at the status bar. For example, if you switch to acceptEdits, the status bar will light up ⏵⏵ accept edits on. This is the default cycle, and there are only these three gears.
Then where did auto, bypassPermissions, and dontAsk go? They are not in the default cycle, and must meet conditions or carry parameters to be "inserted". The official documentation writes the rules very granularly. Let me translate it into human words for you:
auto(Auto Mode): When your account meets all requirements for auto mode, it will appear in the cycle. The first time you cycle to it, an "opt-in" prompt will pop up; it only officially joins the rank if you click agree; if you select "No, do not ask again", it gets kicked out of the cycle.bypassPermissions(Skip all checks): It only appears if you start with--permission-mode bypassPermissions,--dangerously-skip-permissions, or--allow-dangerously-skip-permissions. Note that the--allow-variant only adds it to the cycle but doesn't activate it immediately.dontAsk(Only recognizes pre-approval): Never enters the cycle, can only be specified when starting with--permission-mode dontAsk.
A finer point, the official documentation specifies the insertion position, so you won't find the order wrong halfway through pressing:
Enabled optional modes are inserted after
plan, withbypassPermissionsprioritized, andautolast. If you have both enabled, you will cycle throughbypassPermissionson the way toauto.
Translating this sentence into your actual experience when pressing keys: Assuming you have both enabled, a full Shift+Tab turn looks like this—
default → acceptEdits → plan → bypassPermissions → auto → (return to default)auto is always placed last, and bypassPermissions is in front of it. By remembering this order, you will know how many more times to press to get to the gear you want, without blindly cycling.
The recommended practical habit is consistent with what was said in Article 20—most of the time, just manually switch within the default three gears using Shift+Tab: when taking on an unfamiliar project, switch to plan to let it read through and produce a plan; when you trust the direction, switch to acceptEdits to let it change; after the changes are done, if you want to be stricter, switch back to default. bypassPermissions should only be turned on with startup parameters in an isolated container; don't hang it in the daily cycle—this red line was drawn in Article 20, so it won't be repeated.
💡 One-sentence summary:
Shift+Tabdefaults to cycling only withindefault/acceptEdits/plan;auto/bypassPermissionsmust meet conditions or have startup parameters to join the rank, and the order is "afterplan,bypassPermissionsin front,autoat the bottom"—remember this ranking, and you'll know what to expect after a few presses.
04 Plan Mode: Not Just a Mode, but a "Plan First, Act Later" Workflow
The previous section briefly passed over plan as one gear in the cycle, but it deserves its own section—because the true value of Plan Mode lies not in "it's a read-only mode", but in the complete workflow behind it of "produce a plan first, act after you review". This is the most frequently used control method and one that is highly recommended for beginners to make a habit of as early as possible.
Analogy: A director shouting "Let's run through the scene first". Before officially shooting, the director often asks the actors to rehearse the scene once—going through the blocking, lines, and pacing—but without rolling the camera or consuming film. Once everything looks good, they shout "Action, real take". Plan Mode is this "run-through" phase: Claude runs through the whole thing in its head, reading files, researching, and writing a plan of "how I intend to change it", but doesn't actually touch a single word of your source code; only after you review it and nod does it "real take" start changing.
The official documentation clearly defines its behavior:
Plan mode tells Claude to research and propose changes without making them. Claude reads files, runs shell commands to explore, and writes a plan, but does not edit your source code.
How to enter, how to exit
There are two ways to enter Plan Mode:
Shift+Tabcycle toplan—manages the entire session until you switch away.- Add
/planbefore a single prompt—makes only this single prompt follow the plan mode; suitable for "I just want to see the plan for this one thing first".
/plan Help me change user login from session to JWT; don't touch anything yet, tell me how you plan to change itWant to exit midway without approving the plan? Just press Shift+Tab again to cycle away.
The plan is out, what are those options when approving?
This is the step in Plan Mode that feels the most like a "workflow", and it's also where beginners are most likely to get confused. When Claude has written the plan, it will stop and ask you "What to do next", and the options given are roughly these:
- Approve and start in auto mode—you completely trust the direction, let it automatically do it all the way.
- Approve and accept edits—switches to
acceptEdits, modifies code without asking, but will still stop for dangerous commands. - Approve and manually review each edit—returns to
defaultfor step-by-step confirmation. - Continue planning and give feedback—the plan isn't good enough, you give suggestions to make it revise the plan.
Do you understand? This act of approving the plan is equivalent to "simultaneously selecting which permission mode to use next". It exits Plan Mode, directly switches the session to the gear you selected, and then starts acting. This is why it is said that Plan Mode is not an isolated gear, but the hub that strings together the entire process of "explore → produce plan → select autonomy → act".
There are two other details provided officially that are quite practical:
Ctrl+Gdirectly edit the plan: The plan is written, but you want to personally change a couple of strokes (like "delete this step, swap the order"), pressCtrl+Gto open it in your default text editor, modify it, and then let Claude follow it.- Approving will automatically name the session: Unless you have already named it with
--nameor/rename, when approving the plan it will automatically name this session based on the plan content, making it easier to find with/resumelater.
A typical use case
To put it bluntly, when taking on any unfamiliar project, the first thing to do is to switch to Plan Mode, let it read through, and produce a plan. For example, taking over old code left by someone else, tens of thousands of lines, understanding nothing. Directly Shift+Tab to plan, throw in a sentence "Read through this project, tell me the overall structure and where you suggest starting changes." It reads around, lists a structure + reform suggestions, and only after reading it can you confidently let it in. If you just go up and acceptEdits letting it blindly change, it's highly likely to be a disaster. It is strongly suggested you form this habit as early as possible.
💡 One-sentence summary: Plan Mode is "run through first, shoot later"—it only researches, only produces a plan, doesn't touch source code; the act of approving the plan will incidentally select the next permission mode (auto / acceptEdits / manual review), and
Ctrl+Geven lets you personally modify the plan. When taking on an unfamiliar project, always/planfirst, it's much safer.
05 Fast Mode (fast mode): What You Spend Money Buying is Speed, Not Quality
⚠️ Research Preview Feature, Subject to Change: Fast mode is currently a research preview version; features, pricing, and availability may be adjusted at any time; and it requires Claude Code v2.1.36 or higher.
Having talked about "how to control direction", let's talk about another switch "controlling speed"—fast mode. First, let's correct the most easily misunderstood point:
Fast mode doesn't switch to a stronger model, it switches the "running method" of the same Opus. The official documentation is very direct:
Fast mode is not a different model. It uses Claude Opus but with a different API configuration prioritized for speed over cost efficiency. You get the same quality and capabilities, just faster responses.
Exactly how much faster, and how much more expensive? Official numbers given: Up to 2.5x faster, at the cost of being more expensive per token. It is only supported on Opus 4.8 / 4.7 / 4.6, Sonnet and Haiku cannot use it (⚠️ Opus 4.6's fast mode is deprecated; it is recommended to use 4.7 or 4.8).
How to turn on
Just one command:
/fastType /fast and press Tab to toggle on or off. After turning it on:
- If you were using another model at the time, it will automatically switch to Opus.
- You will see the prompt
Fast mode ON, and a small↯icon will pop up next to the prompt box. - Anytime you
/fastagain, you can check if it is currently on or off.
There is a counter-intuitive point to remember: After turning off fast mode, you still stay on Opus, the model won't automatically switch back to the one you originally had. If you want to switch back to another model, you have to /model yourself.
Is it worth it: Depends on whether you lack speed or money right now
When exactly should you turn it on? The official judgment and actual physical feeling are consistent—it depends on which is more critical for this task, "latency" or "cost":
| Scenario | Turn on fast mode? | Why |
|---|---|---|
| Real-time debugging, rapid iteration, rushing a deadline | ✅ On | You are waiting for it, one second slower is agonizing, speed first |
| Long-term autonomous tasks, batch processing, CI/CD | ❌ Off | No one is watching, slower doesn't matter, saving money first |
| Cost-sensitive work | ❌ Off | More expensive per token, adds up to a painful amount |
There is also a crucial detail for saving money, repeatedly emphasized officially, and very easy to step on:
For optimal cost efficiency, enable fast mode at the beginning of a session rather than toggling it mid-conversation.
Why? Because the first time you turn on fast mode, you have to pay a complete fast mode input fee for "the entire conversation context". The longer the conversation drags on before turning it on, the more expensive that moment is. So if you're going to turn it on, turn it on at the beginning; don't wait until you've chatted for half a day and the context is a huge chunk before remembering to turn it on. It's easy to pay tuition fees for this—turning on fast midway through a long conversation will result in a noticeably higher bill for that moment than expected.
Don't confuse it with "effort level"
Finally, let's clarify a common confusion: fast mode ≠ adjusting effort level. Both affect speed, but their approaches are completely different:
| Setting | What it does | Side effects |
|---|---|---|
| Fast mode | Same model quality, lower latency | More expensive |
| Lower effort level | Make it think less, output faster | Quality may drop on complex tasks |
In a word: Fast mode does not sacrifice quality, it only costs more money; lowering the effort level means less thinking, which may sacrifice quality. The two can even be stacked together—on simple tasks, "fast mode + low effort level" maximizes speed.
⚠️ Extra note for subscribers: For Pro/Max/Team/Enterprise subscribers, fast mode only uses "usage credits" and is not included in subscription rate limits; it is billed separately at the fast mode rate starting from the very first token. In other words, you have to pay out of pocket for it; it's not given away free with your subscription. Be aware of this before turning it on.
💡 One-sentence summary: Fast mode buys the speed of the same Opus (up to 2.5x), at the cost of being more expensive;
/fastswitch, if you open it, open it at the start of the session (opening it midway is more expensive); turn it on if rushing, turn it off for long tasks, and don't confuse it with "adjusting effort level".
06 Vim Editing Mode: Equipping Your Input Box with Veteran Gestures
The final control method serves "how you edit the text you type"—Vim mode. If you have never used Vim at all, you can just glance over this section and skip it; it doesn't affect your use of Claude Code. But if you are a Vim veteran, turning it on will make the input experience much handier.
Claude Code's input box is a normal text box by default (type randomly, arrow keys to move). When Vim mode is turned on, it gets Vim's "two states":
- INSERT mode: Just like a normal input box, typing is just typing.
- NORMAL mode: Keys are no longer characters, but "commands"—
h/j/k/lto move the cursor,ddto delete a line,wto jump to the next word,0to jump to the beginning of a line,$to jump to the end of a line... The whole set from Vim is brought over.
How to turn on
Through the /config menu, find "Editor mode" and switch to vim. After turning it on:
- Press
Escto enter NORMAL mode (keys are commands now). - Press
i/a/oetc. to return to INSERT mode and start typing.
Here are a few of the most commonly used ones in the input box, just to give brothers who have never touched it a feel:
| Press in NORMAL mode | Does what |
|---|---|
dd | Delete the entire line (e.g., if you want to rewrite this prompt) |
cw | Change the current word |
0 / $ | Jump to start / end of line |
u | Undo the change you just made |
i / a | Start inserting/typing before / after the cursor |
There is a detail that Vim veterans will like: In NORMAL mode, if the cursor is already at the very top or bottom of the input and can't move up/down anymore, pressing j/k or arrow keys at this time will go flip through command history. It's like "moving" and "flipping history" are seamlessly connected.
To tell the truth, this mode is purely "icing on the cake". Heavy Vim users turning it on to edit long prompts does feel great; but for many beginners, there's absolutely no need to touch it—a normal text box paired with the few shortcuts from section 02 (Ctrl+U delete to line start, Ctrl+W delete word) is already enough. So: If you are a Vim party member, turn it on; if not, don't bother, it's not a required course.
💡 One-sentence summary: Vim mode equips the input box with NORMAL/INSERT dual states and the full set of Vim gestures, turned on via
/config→ Editor mode; Vim veterans will find it handy, pure beginners can completely skip it, it doesn't affect any functionality.
07 Hands-on: Run Through This Set of Control Methods Once
Just reading without practicing won't help you remember. Below I've designed a 5-minute exercise that doesn't rely on any complex project for you, to string together the core control methods of this article and press them once. Every step gives "what to expect to see", so you can follow along and verify against it.
Casually find an empty directory, start claude, and then:
Step 1: Practice Shift+Tab switching modes, stare at the status bar
After starting, press Shift+Tab consecutively a few times, eyes staring at the status bar.
Expectation: The status bar text changes cyclically among the three gears—when switched to
acceptEdits, it displays something like⏵⏵ accept edits on; when switched toplan, it displays a plan mode prompt; turn a full circle and return to default (the mode prompt line on the status bar disappears or shows default). Confirm you can recognize which gear you are currently in just by the status bar.
Step 2: Enter Plan Mode, let it produce a plan (but don't really act)
Shift+Tab switch to plan, then enter a request that will trigger it wanting to "act":
Create a hello.txt in the current directory, and write a line "hi from claude" inside itExpectation: It won't really create the file, but gives you a description of "how I intend to do this", and at the end stops and asks how you want to proceed (approve and accept edits / manual review / continue planning...). Confirm that there is no
hello.txtin the directory right now—this is Plan Mode's "only run through, no real take".
Step 3: Approve the plan, observe it switching modes
Among the options it gives, select "Approve and accept edits" (or the manual review item).
Expectation: It exits Plan Mode, the status bar switches to the gear you selected (if you selected accept edits, it shows
accept edits on), and then it really creates thehello.txt. Confirm that the file is now in the directory, and the mode has changed fromplanto the one you selected when approving—see for yourself that "approving a plan = incidentally selecting permission mode".
Step 4: Practice Esc to call a halt
Assign it a slightly longer task again (like "read every file in this directory one by one and summarize"), and right as it starts running, press Esc once.
Expectation: It stops right there, hands control back to you, and the cursor returns to the input box. The parts it has already finished (like files already read) are kept. You can immediately follow up with a new command to redirect it. Confirm that
Escis "pause and return" and not "error crash".
Step 5 (Optional): Check the fast mode switch
Type /fast and press Tab, look at the prompt.
Expectation: If your account supports it, you will see
Fast mode ONand the↯icon next to the prompt box;/fastagain to turn it off. If your account/plan doesn't support it or you haven't opened usage credits, you will see a prompt like "fast mode unavailable" — this step is "experience it if you can, it's normal if you can't", don't force it.
After running these five steps, you have personally touched all the core control methods of this article. Beginners especially need to walk through steps two and three—the physical feeling of "it doesn't act in Plan Mode, acts only after approval and switches mode", experiencing it yourself once is better than reading the docs ten times.
💡 One-sentence summary: Follow these five steps to string together and press once
Shift+Tabswitching modes, Plan Mode producing plans and approvals,Esccalling a halt, and/fastswitches, self-verifying each step against "what to expect to see"; especially steps two and three, personally experience "plan mode only runs through, approval is real take and incidentally switches mode".
08 Summary
This article has laid out and explained "the console in your hands after the session has already started." Article 20 gave you the reins of permissions, and this article gives you the full set of joysticks.
Stringing the core points together for review:
| What you want to do | Control method | One-sentence key point |
|---|---|---|
| Let it ask less / more before acting | Shift+Tab cycle modes | Default three gears, auto/bypass join if conditions met, auto at bottom |
| It went off track, call a halt to redirect | Esc | Pause and return steering wheel, completed parts kept |
| Rewind to previous point in conversation | Esc Esc (when empty box) | Open rewind menu, details in Article 37 |
| Interrupt / clear input / exit | Ctrl+C / Ctrl+D | Empty box second Ctrl+C exits, don't double-tap blindly |
| Throw long commands to background | Ctrl+B | Press twice in tmux |
| Plan first then act | Plan Mode (/plan) | Only run through not real take, approval incidentally selects permission mode |
| Spend money for faster Opus | /fast | Same quality, more expensive, turn on at session start if at all |
| Vim gestures edit input | /config → Editor mode | Icing on the cake for Vim party, beginners can skip |
You should now be able to: Manipulate Claude with ease in a running session—Shift+Tab switch to the appropriate autonomy gear, Esc pull it back when it goes off track, use Plan Mode to let unfamiliar projects "produce a plan first and act after you review", /fast to get speed when needed, and Vim party members can use familiar gestures to edit prompts. To put it bluntly, you have upgraded from "only knowing how to type Enter and wait dryly" to "holding the joysticks the whole time, able to control at any moment."
Having reached this point in the entire fifth group "System Configuration and Optimization", configuration files, output styles, hooks, CLI flags, and controls & modes have all been laid out. You already have a systematic grasp of "how to configure and how to control" Claude Code.
Next article 36 "Slash Commands", brings the gaze back to that most inconspicuous little symbol that you use every day—/. In this article, you have already typed /plan, /fast, /config several slash commands, but how many of them are there, and can you forge a / command of your own? Think about it: if those fixed processes you manually type every day could be compressed into one / to call out with one click, how much trouble would that save—we'll find out in the next article.