Controlling Claude Code with Slash Commands

Every time you open Claude Code, you have access to a set of built-in commands that control the tool's behaviour, manage your conversation context, configure settings, and orchestrate sub-agents. These are called slash commands — typed with a leading / character — and they are the primary way to interact with Claude Code's features directly, without writing natural language instructions.

Understanding slash commands is essential not just for day-to-day productivity, but for practicing context engineering — the discipline of deciding what information the model has access to at each step. Commands like /clear and /compact give you direct control over the shape and content of the context window. Commands like /config let you tune the tool's behaviour at the user, project, and local level.

This article walks through the most important slash commands available in Claude Code, what each one does, when to use it, and how it fits into the broader workflow of agentic coding.

Discovering Available Commands

The Command Palette

To see all available slash commands, simply type / in the Claude Code chat. Claude Code will display a list of all commands, along with a short description of what each one does. This is the fastest way to discover what is available without consulting external documentation.

The available commands are grouped into categories — context management, configuration, session control, and agent management. You do not need to memorize them all; the in-chat list is always one keystroke away.

Managing Context: /clear and /compact

Why Long Conversations Become a Problem

Every message you send to Claude Code, every file it reads, every tool call it makes, and every response it generates adds tokens to the context window. The context window is finite. LLMs have a maximum number of tokens they can process at once, and Claude Code is no exception.

As a conversation grows, several problems emerge:

1. Performance degradation — longer contexts take longer to process, making responses slower
2. Higher cost — if you use an API key rather than a subscription, every token in the context costs money
3. Context rot — the model may start to "forget" or misweight important early information as noise accumulates later in the conversation
4. Confusion and hallucination — a model asked to remember too many things starts to confuse them, producing inconsistent or incorrect results

Context rot is a subtle problem. The model does not raise an error when its context is overloaded — it quietly starts producing worse results. This is why actively managing context is a core practice in agentic coding, not an optional cleanup step.

/clear — Starting with a Blank Slate

The /clear command erases the entire conversation history and resets the context to a fresh state. Think of it as closing the chat and opening a new one. Everything that was in the context window — all messages, tool call results, file reads, and prior instructions — is discarded.

Use /clear when:

1. You have finished one task and are starting a completely different one
2. The conversation has drifted and you want to give Claude a fresh understanding of a problem
3. You suspect the accumulated context is causing incorrect or inconsistent responses
4. You want to begin a pairing session on a new feature without baggage from previous work

The trade-off is complete: /clear gives you maximum freshness but zero continuity. Any nuance Claude learned about your preferences or the codebase during the conversation is lost. Your CLAUDE.md file and persistent memory files will still be loaded at the start of the new session, so project-level context is not lost — only the ephemeral conversation history is.

/compact — Intelligent Summarization

The /compact command takes a different approach. Instead of deleting the conversation, it summarizes it. Claude reads through the current context window, identifies the important facts — what task is in progress, what decisions were made, what the code looks like — and compresses the history into a condensed summary. That summary replaces the full conversation history, freeing up token space while preserving the key information.

Think of /compact as taking meeting notes at the end of a long discussion. You do not keep every word that was said, but you preserve the conclusions, decisions, and next steps.

Use /compact when:

1. The conversation has grown long but you want to continue the same task without starting over
2. You are approaching the context limit and Claude warns you about it
3. You want to reduce cost without losing continuity
4. You notice responses are getting slower and you want to reduce processing time

You can also provide a custom summary instruction to guide what Claude preserves:

This is context engineering in its most explicit form: you are directly controlling what the model knows and does not know as it continues its work.

Auto-Compact: Letting Claude Decide

Claude Code also supports auto-compact, a setting that automatically triggers /compact when the context window approaches its token limit. When auto-compact is enabled, you do not need to remember to run /compact manually — Claude handles it for you.

You can toggle auto-compact in the /config settings panel (discussed below). For most interactive coding sessions, enabling auto-compact is a sensible default. It prevents sudden performance degradation and keeps costs predictable. The only downside is that the automatic summary may not always preserve exactly the context you would have chosen — if precision matters, manual /compact with a custom focus instruction gives you more control.

Managing Sub-Agents: /agents

What Are Sub-Agents?

Claude Code supports multi-agent workflows, where specialized AI agents are created for specific tasks rather than asking a single agent to handle everything. A sub-agent is essentially a separate Claude instance, running with its own context window, its own set of tools, and instructions tailored to its role.

Common examples of sub-agents include:

1. A code reviewer that reads pull request diffs and provides feedback
2. A test writer that takes a service class and generates unit tests for it
3. A documentation agent that reads source code and writes API documentation
4. An architect agent that evaluates design proposals against architecture decisions

Sub-agents are powerful because of context isolation: each agent works in its own context, preventing the noise and confusion of mixing different types of work in a single long conversation. They are also parallelizable — an orchestrator agent can launch multiple sub-agents simultaneously to process different parts of a codebase at the same time.

The /agents Command

The /agents command opens the agent management interface, where you can view, create, and manage sub-agents available in your session. This is where you define the specialized assistants that will participate in your multi-agent workflows.

Custom sub-agents are defined using Markdown configuration files stored in the .claude/agents/ directory of your project. Each agent file specifies the agent's name, its system prompt (instructions defining its role and behaviour), and the tools it is allowed to use. Here is an example agent definition:

Once defined, this agent can be invoked by name from the main Claude Code session or from an orchestrator agent. Multi-agent workflows and the full set of sub-agent capabilities are covered in detail in a later chapter.

Configuring Claude Code: /config

The Configuration Panel

The /config command opens the configuration panel — an interactive settings interface built directly into the Claude Code chat. Here you can view and toggle the settings that control how Claude Code behaves throughout your sessions.

Settings available in the configuration panel include:

1. Auto-compact — automatically compact the context when approaching token limits
2. To-do lists — enable or disable Claude's use of structured task tracking during multi-step work
3. Checkpointing — periodically save the session state to recover from interruptions
4. Additional model behaviour and tool configuration options

The complete and up-to-date list of available settings is documented in the official Claude Code settings documentation.

The Configuration Hierarchy

What makes Claude Code's configuration system particularly powerful is that settings are applied in a layered, hierarchical order. There are three scopes:

1. User-wide settings — stored in ~/.claude/settings.json (your home directory). These apply globally to every Claude Code session across all projects on the machine. Use this scope for personal preferences that should always be active, like your preferred response style or your default permission mode.
2. Project-specific settings — stored in .claude/settings.json within a project's root directory. These apply only when Claude Code is running inside that project. Because this file lives inside the project directory, it can be committed to version control and shared with your team, making sure every team member gets the same Claude behaviour when working on that codebase.
3. Local settings — stored in .claude/settings.local.json. These let individual developers apply personal overrides on top of the shared project settings, without affecting what the team sees. This file should be added to .gitignore so it is never shared.

When the same setting is defined at multiple levels, the more specific scope wins. Local settings override project settings; project settings override user-wide settings. This order allows you to maintain sensible global defaults, apply project-level guidelines that the whole team agrees on, and still keep individual preferences without creating conflicts.

Here is an example of a project-level settings file for a team that wants auto-compact enabled and to-do lists active by default:

And a local override file where an individual developer disables to-do lists for their own sessions:

This structure scales well: as a project grows and the team develops shared conventions for how Claude should behave, those conventions live in a versioned file alongside the code itself, not in someone's personal configuration that no one else can see.

Monitoring Costs: /cost

When Cost Monitoring Matters

The /cost command displays a breakdown of the token usage and estimated cost for the current session. This is most relevant when you are using Claude Code with an Anthropic API key, where you are billed directly per token consumed.

The cost report typically shows:

1. Total input tokens consumed in the session
2. Total output tokens generated
3. Cache read and write tokens (when prompt caching is active)
4. Estimated cost in USD based on the current model pricing

If you are using a Claude Pro or Max subscription, cost tracking is less critical because usage is included in the subscription. However, /cost remains useful for understanding your token consumption patterns — especially if you are building automated pipelines or long-running agentic workflows where token usage can accumulate unexpectedly.

Cost and Context Management Working Together

The /cost command pairs naturally with /compact. If you notice that your session's cost is growing faster than expected, it is a signal that the context has become larger than necessary. Running /compact after checking /cost is a straightforward way to trim unnecessary tokens and keep the session efficient.

Developing a habit of occasionally glancing at /cost during long sessions helps you build an intuition for how different types of work consume tokens — file-heavy exploration vs. code generation vs. long conversational threads — and helps you decide when /compact or /clear is the right intervention.

Summary

Slash commands are more than keyboard shortcuts — they are the control surface for the context engineering decisions that determine how well Claude Code performs over time. The most important ones to internalize early are:

Understanding when to use /clear versus /compact is a foundational context engineering skill. Knowing how the configuration hierarchy works — user, project, local — means you can set up Claude to behave correctly by default without needing to re-configure it at the start of every session. These habits compound over time and make the difference between an AI assistant that gradually becomes less useful and one that stays sharp and accurate throughout long, complex projects.