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 (also available as /reset or /new) 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. By default, auto-compact kicks in at approximately 95% context capacity. You can adjust this threshold by setting the CLAUDE_AUTOCOMPACT_PCT_OVERRIDE environment variable to a different percentage. 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 — a tabbed panel with two views. The Running tab shows all sub-agents currently active in your session (foreground and background). The Library tab lists all available agent definitions and lets you create, edit, or delete them.

Built-in Sub-Agents

Claude Code ships with several built-in sub-agents that you can use immediately without any configuration:

1. Explore — a fast, read-only agent that uses a lighter model (Haiku) for rapid codebase exploration and Q&A. It cannot modify files.
2. Plan — enters a structured planning mode where Claude helps you think through a problem before writing code.
3. General-purpose — a generic sub-agent useful as a starting point for custom workflows.

Custom Sub-Agents

Custom sub-agents are defined using Markdown configuration files. Each agent file includes YAML frontmatter specifying the agent's name, description, allowed tools, model, and other options, followed by a system prompt in the body. Here is an example agent definition:

Note that the tools field uses Claude Code's internal tool names — Read, Glob, Grep, Bash, Write, Edit, Agent — not the filesystem function names you might expect. You can use tools as an allowlist (only these tools) or disallowedTools as a denylist (everything except these). Other useful frontmatter fields include model (sonnet, opus, haiku, or a full model ID), permissionMode, maxTurns, memory, and background.

Agent Scopes

Agent definitions are loaded from multiple locations, applied in the following priority order:

1. Managed settings — agents pushed by your organisation via MDM or server-managed configuration (highest priority)
2. CLI --agents flag — agents specified when launching Claude Code from the command line
3. Project agents — Markdown files in .claude/agents/ within the project directory (shared with the team)
4. User agents — Markdown files in ~/.claude/agents/ (personal, available across all projects)
5. Plugin agents — agents provided by installed Claude Code plugins (lowest priority)

Once defined, an agent can be invoked by name from the main Claude Code session, via @agent-name mention, or with the --agent CLI flag. 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 (also available as /settings) 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 five scopes, listed from lowest to highest priority:

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.
4. CLI argument settings — flags passed when launching Claude Code from the command line (e.g., --model, --permission-mode). These override all file-based settings for the current session only.
5. Managed settings — organisation-level configuration pushed via MDM (Mobile Device Management) or server-managed policies. These have the highest priority and cannot be overridden by any other scope. They ensure that security and compliance policies are always enforced regardless of user or project preferences.

When the same setting is defined at multiple levels, the more specific scope wins — with the exception of managed settings, which always take precedence. In practice, for day-to-day development the three file-based scopes (user, project, local) are what you interact with most. CLI args are useful for one-off sessions with different settings, and managed settings are relevant only in enterprise environments.

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.

Other Notable Commands

Beyond the five core commands above, Claude Code includes dozens of slash commands. Here are some you will encounter frequently:

Type / at any time to browse the complete, up-to-date list. Commands added by skills and MCP server prompts also appear in the command palette, prefixed with their source (e.g., /mcp__server-name__prompt).

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 — from user-wide defaults through project and local settings, up to CLI args and managed policies — 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.