Feature Gates Show The Product Pressure
The switched-off corners of Claude Code reach for one kind of work. It outlives the prompt, runs far away, remembers, plans, and shares. Every corner builds from parts the earlier ideas already named. That reuse is the clue worth reading.
Read a half-built corner for the parts it reuses. Those parts name the load the design must hold up.
Feature gate
A thing can be off in two ways, and the two are not the same.
One: the toy never went into the box. Nothing you do brings it out. Two: the toy sits in the box with its batteries out. It is right there, dark, and a switch wakes it.
Software hides both kinds. Some features are cut before the program ships. Others ship and sit switched off, waiting. The names of those sleeping switches read like a plan for what comes next.
A half-built feature can be a test, a switch left off, or a piece waiting on unfinished work. I stopped guessing dates and started reading the parts each corner reuses. The matrix below runs eight corners against eight shared parts. Watch the same columns light up, corner after corner.
record
cript
ission
transport
01The switch happens before the build
The build-time switch runs before the program is built, and it decides which code goes in. Off means the shipped program does not carry that code at all. Try it.
The runtime flag works while the program runs. It turns a shipped feature on or off, one person at a time, with no new build. So a feature can sit in the program and stay dark for you.
Read the sleeping switch names as clues to the work ahead. They run: background sessions, remote control, voice, a planner, cross-session messaging, a coordinator, a companion. That list is where the product pressure shows.
02Persistence: work outlives the terminal
The clearest clue is background sessions. Claude Code runs a session away from your window and tracks it as a live task. That task carries its own record and transcript, keeps its permissions, and holds its context. You list it, watch it, or stop it after the window is gone.
03Remote control: permission becomes a distributed event
The same idea reaches across devices. A session runs from a browser or a phone, and it signs in. It reconnects when the link drops and keeps a bookmark, so a crash resumes instead of restarting. It checks the far screen for new work and carries enough state to skip the replay.
The far screen explains the permission race from earlier in this guide. Once a session takes work from another screen, four parts must travel. Those parts are the ask, the message order, the transcript, and the power to cancel. A click in one window cannot cross that gap.
04Memory, planning, coordination: the same parts again
Three more corners build from parts you met earlier.
- Memory. Notes between turns and a slower pass across sessions use the same parts. The subagent runs on the short leash from the memory idea, behind the lock from the context idea. It reads the transcript and the context, and it edits the notes file alone.
- Planning. A long planning session can run on its own, on a stronger model, in a mode that writes nothing. It carries its own record, transcript, and plan-mode permission, and it travels over the same transport. Then it hands the plan back, or carries it out from far away.
- Coordination. One lead runs many subagents. It reuses records, subagent names, tool sets, mailboxes, permissions, and walled-off context, then pulls the work back together. This corner tests every part in the guide at once.
Even the playful corner fits. The terminal companion comes from your account through a fixed rule. One identity goes in, the same companion comes out, saved and switched like any other feature. Identity runs through even the toy.
05The pattern across the corners
Put the corners side by side and they point at work that outlives one prompt and one window. Tasks and records came from the state machine. Permissions belong to the runtime that answers the ask, context to the budget that guards the window. Tool sets came from the tool system, and subagents from the scheduler idea. Transport arrived with the far screen, and identity with the companion. All eight answer that one problem, and a better prompt does not touch it.
The caution
I do not know which of these corners ship. Some are half-built, some are switched off, and some serve only the people who build it. Code in the build is not a feature in your hands. A switch is not a release date. The defensible claim is narrow: many half-built paths, and one shared set of parts. Anything past that is rumor, and this guide does not sell rumor.
Decision
Treat a half-built corner as a clue about the design. Pick one corner. List the parts it reuses, and point to where each part showed up earlier in this guide. A complete list means you are reading it right. A ship date in your answer means you left the clues behind. The last idea pulls all of it into one shape.