Claude Code can become considerably more useful without installing another plugin. The key is not simply asking it to write more code. It is knowing how to monitor usage, preserve reliable project instructions, reset a cluttered conversation and ask a side question without redirecting the main task. Remote Control, design tools and deeper research extend that workflow further.
In his video “7 funzionalità di Claude Code che (forse) non conosci”, published on September 30, 2026, Raffaele Gaito highlights seven features worth exploring. This article develops those themes into an independent practical guide, with examples and checks against Anthropic’s documentation. “Secrets” here means underused features, not hidden tricks for bypassing permissions or subscription limits.
Availability matters. Claude Code changes quickly, and commands can depend on the installed version, subscription, runtime and organization settings. The explanations below were checked against documentation available at publication. If a command is missing, establish whether your environment supports it before trying to reproduce somebody else’s interface.
The original video and the distinctions that matter
The common theme is workflow organization. These features do not all make the model smarter: several help you manage information and understand what the agent is doing. That distinction also matters when comparing the ecosystem with the agent tools covered in our OpenAI DevDay breakdown. The model, the available tools and the execution environment are separate layers.
1. /usage: find out where the budget goes
Do not wait for a limit notification before checking consumption. The /usage command, or the usage area provided by your interface, helps you understand whether the current workflow is sustainable. What you see depends on how you access the service: a subscription and metered API usage are not interchangeable accounting systems.
Anthropic’s cost documentation describes plan limits and recent attribution to activities such as skills and subagents. Local estimates are not authoritative API invoices. Likewise, activity attribution based on local sessions does not automatically cover everything you did in the Claude app or on another device. Interpret the scope of a measurement before drawing conclusions from it.
A practical example: a review that keeps expanding
You ask for a correction in one module, then add a security review, a refactor, documentation and three competing implementations. That is no longer a small patch. Reading files, reasoning, producing responses and delegating work can all increase consumption. Comparing usage before and after helps distinguish a necessary check from an accidental expansion of the assignment.
A better sequence is to define a narrow objective: inspect the two relevant files, propose the change, implement it and run targeted tests. When unrelated problems appear, request a separate issue list instead of launching a repository-wide investigation automatically. This is a budgeting decision, not an argument for weaker engineering.
Context and quota are different. Context is the information available to a conversation. Quota is the usage allowed by a plan, while API accounting concerns billable activity. A short conversation can have performed an expensive investigation. Clearing a conversation does not recharge your allowance. A side question is not a promise of free computation either.
2. /memory: preserve useful rules, not a pile of stale instructions
Memory addresses a familiar frustration: repeatedly explaining the same project conventions. It helps to distinguish explicit instructions in CLAUDE.md from automatic memory notes collected during work. The /memory interface lets you inspect and manage the material, using the options supported by your environment.
The official memory guide explains the file-based mechanism. This is not personal retraining of the model. Saving a preference does not update model weights, and there is no guarantee that every conversation detail will be recorded. The usefulness of memory depends on whether its contents remain accurate and relevant.
What deserves a permanent instruction?
Strong instructions describe observable behavior: use the repository’s documented test command, follow the existing component library, avoid writing credentials to logs and distinguish a proposal from deployment. “Always do your best” does not help choose between actions. “Check the current schema before editing a migration” does.
Suppose you are building a financial application and every screen must use the same conventions for dates and amounts. Record the convention explicitly. Do not rely on a remark made in an old chat. A temporary test endpoint is different: keeping it permanently may turn a short-lived workaround into an apparent source of truth.
Review memory periodically for obsolete commands, contradictory rules and preferences that no longer apply. Exclude passwords, access tokens, private keys and personal information. Local storage is not automatically an appropriate secret store. Editing or deleting a memory entry also does not undo changes already made or remove copies stored elsewhere.
When the assistant repeatedly follows the wrong rule, ask which file contains it. Correcting the source is usually more useful than arguing with the latest answer. A short, maintained set of instructions is easier to audit than an ever-growing catalogue of exceptions.
3. /clear versus /compact: start fresh or preserve continuity
A conversation becomes less useful when unrelated goals accumulate. You began with a bug, then discussed marketing, reconsidered the framework and requested newsletter copy. Every subsequent step now requires deciding which earlier instructions still apply. Sometimes the cleanest solution is a new conversation rather than another clarification.
/clear starts a new conversation with empty context. /compact summarizes the existing conversation so you can continue the same assignment with less context overhead. Anthropic’s Claude Code command cheatsheet distinguishes these purposes. Use the former for a different objective and the latter when the current work genuinely continues.
Write a handoff before clearing unfinished work
A useful handoff records what changed, which checks passed, what remains unresolved and what to do next. Store it in an appropriate project file. You do not need an entire chat transcript: you need a concise operational description that the next session can compare with the actual repository.
Consider an API migration. The new client exists, but retries and error handling still need review. An actionable note identifies the relevant files and tests. “Almost finished” does not. This discipline also applies to changes of the kind discussed in our model API migration guide, where a fresh conversation must not lose the compatibility requirements.
/clear does not delete project files, automatically remove project memory or reset plan limits. Conversation management is not a computer reset or an undo operation. Reverting code requires a separate, controlled action. Returning to an earlier conversation likewise uses the resume mechanism rather than assuming its information survived in the new context.
Before choosing either command, identify what you are trying to solve. A crowded context suggests compaction or a fresh start. A wrong permanent rule requires editing its source. A usage limit requires a plan or budget decision. Applying the wrong remedy only disguises the original problem.
4. /btw: ask a side question without redirecting the main task
/btw is useful when work is underway and you want a clarification without making it the main assignment. While the agent prepares tests, you might ask what makes an operation idempotent. The side channel can explain that concept without inserting the detour into the main conversation history.
The crucial limitation in the interactive-mode documentation is that side questions have no tools. They can reason from information already present, but cannot open another file, run a shell command, browse the web or change a configuration. Asking for a new inspection is therefore different from asking for an explanation.
Good side questions and a bad one
/btw Why did the code we already examined use exponential backoff?/btw What does idempotency mean in this workflow?/btw What is the main risk of the approach we discussed?- Not suitable: “Open the credentials file and change this setting.” It requires tools and concerns sensitive material.
This separation reduces interruptions; it does not make the answer omniscient. If the main session has not yet obtained a fact, the side answer may not have it either. Ask the assistant to distinguish a general explanation from something actually observed in the project. Fluent wording is not evidence of a completed inspection.
Use the side channel to understand options, then send decisions that affect implementation into the main conversation. Otherwise, you may believe you approved a change that the working agent never received. A clarification and an instruction are different, and the workflow benefits from keeping that boundary explicit.
There is also a scope question. A brief conceptual answer belongs here; a broad comparison requiring fresh sources does not. Choosing the channel according to the evidence needed avoids both unnecessary interruptions and misleading claims of verification.
5. Remote Control: follow a local session from your phone
Remote Control lets you continue a local session from another device. You can check progress, provide a clarification or respond to an approval request without sitting at the original computer. The code and tools still execute in the local session’s environment, rather than magically moving to a cloud machine.
The Remote Control documentation distinguishes it from cloud sessions. The host computer must remain available and the process must keep running. Supported subscriptions and the appropriate sign-in are required; supplying an API key alone does not enable this feature. Organization policies can also affect availability.
The video tip: enable it for new sessions
Besides starting a connection with /remote-control, settings offer Enable Remote Control for all sessions where supported. This avoids repeating manual activation for each new session. It is convenient if you routinely monitor work from a phone; enabling one session at a time is easier to manage when you only occasionally need remote access.
Automatic connection does not mean public sharing of your sessions. You still need to secure the account and devices involved. Do not casually share access, and do not treat a smaller screen as a reason to approve a command without understanding it. A destructive operation remains destructive when approved remotely.
A sensible division is to use the phone for monitoring and tightly scoped decisions, while reviewing significant diffs on a desktop. Before leaving, define what the agent may do independently and what requires a pause. Remote convenience does not replace permission boundaries, testing or careful review of a deployment.
Also consider mundane failures: a sleeping computer or a terminated process changes what can continue. If progress stops, check the local host before assuming the model has become stuck. The remote interface is a window onto the local work, not an independent execution guarantee.
6. /design: turn requirements into a visual proposal
Claude Design can connect an existing project context with a visual exploration: screens, flows, compositions and prototypes that you can inspect. Its value is not simply making something attractive. It is reducing the gap between a product’s actual requirements and a visual proposal that would otherwise start from a vague description.
The /design entry in the official command reference specifies requirements involving the Claude Code version, artifacts and the Design template. Do not assume every account or execution provider supports it. Review the resulting canvas in the browser and test whether the proposed interface actually matches the intended workflow.
A stronger brief than “make a nice dashboard”
Ask for a screen that compares three recurring expenses, with readable amounts, a monthly filter, an empty state and an explicit distinction between confirmed and estimated figures. Specify the audience, the content hierarchy and the components already available. Those are evaluation criteria; a generic aesthetic adjective is not.
Then inspect contrast, hierarchy, mobile behavior, long labels and error states. A convincing mockup does not prove that production code is accessible or that the pictured interactions exist. Engineering handoff should include behavior and constraints, not only an attractive screenshot.
Design is also different from image generation. A product screen involves components and interactions; an editorial illustration is an asset. Our guide to image-generation tools covers the latter distinction. Choose the tool according to the deliverable rather than whichever output looks most dramatic.
For an existing product, preserving its visual language can matter more than inventing a new one. Provide established patterns and ask what needs changing before replacing the whole interface. A narrower design exercise is easier to validate against real user needs.
7. /deep-research: structured research, not automatic truth
Deep research is appropriate when a question requires several sources and meaningful comparison. Asking for a definition is different. A suitable assignment might compare three services’ current pricing, restrictions, data handling and regional availability, separating documented features from future announcements.
The workflow documentation describes /deep-research as a background research workflow using parallel investigation and producing a sourced report. Web search must be available. Monitoring depends on the interface, with /workflows providing a CLI view of the research activity.
Write a request that can be audited
Set a precise scope: “Compare these three products using current primary documentation. Separate available capabilities from announcements, include dates and links, and identify anything you cannot verify.” Add exclusions when relevant: no reconstructed prices from old reviews and no assumptions about enterprise terms without a source.
Review the report rather than treating citations as a seal of approval. Open the decisive links and check whether they support the actual claim. A failed fetch does not prove that a service is unavailable. An unverified fact should remain unverified, not become a negative answer merely to complete a table.
Model selection still requires testing on your own work. Our model comparison guide explains why benchmarks and advertised capabilities only become useful when connected to the task. Research can narrow the options; it cannot replace a representative evaluation.
For consequential decisions, record uncertainties alongside conclusions. A report that clearly distinguishes fact, inference and missing evidence is more valuable than one that confidently fills every cell. You can then direct a follow-up investigation at the gaps that actually affect the decision.
A complete Claude Code workflow using the seven features
Consider a small site whose account-recovery screen needs improvement. Do not launch every feature at once. Define the objective first: make recovery clearer without changing authorization rules. Read the project’s instructions and check that memory contains no outdated procedure for the authentication service.
Use research only when external information is genuinely missing, such as a provider’s current requirements. If the problem is entirely in local code, a broad web investigation adds noise. Ask for a design after identifying the content and states, not before understanding the process users must complete.
During implementation, ask side questions to understand terminology, but send requirement changes through the main conversation. Check usage when the assignment expands. Monitor remotely if useful, but give security-sensitive diffs a complete review rather than approving them from a notification.
At completion, request relevant tests and an operational summary. Save only durable conventions to memory. Start a fresh conversation for a genuinely different task; preserve a handoff when continuing the same change. The gain comes from explicit boundaries, not from using the largest number of commands.
Common questions and avoidable mistakes
Why is a command missing?
Check the version, plan, authentication method, environment and organization settings. The interface in a video may differ from yours. Do not install an unknown plugin just to recreate a command that might already be built in or unsupported for your account.
Does memory make the assistant reliable by itself?
No. It can preserve useful context or preserve a mistake. Keep critical rules explicit and current, and ask where an instruction came from when behavior is wrong. Correcting the source gives the next session a better starting point than another isolated complaint.
Should credentials go into memory to save time?
No. Use a protected credential mechanism and grant only necessary access. Memory files, prompts and research reports should not become copies of secrets. A pointer to protected configuration is fundamentally different from including the credential itself.
Is a report with more sources always better?
No. Three relevant primary sources can outperform twenty pages repeating one another. The important relationship is between the question, the evidence and the conclusion. Preserve uncertainty where it matters instead of hiding it behind a longer bibliography.
Where to start
If you currently use only the chat, start with three habits: inspect the consumption of a real task, maintain concise permanent instructions and separate new objectives from old conversations. Add side questions, remote access, design and research when they solve a specific problem.
The useful “secret” is a controlled process. Know what the system remembers, which tools it can use, where work runs and which answers need verification. These seven features become powerful when you remain responsible for those decisions.