Claude Code Slash Commands Worth Knowing

Claude Code slash commands help you manage the coding session around your prompts: project instructions, tool permissions, conversation context, and session history. Knowing a small set makes it easier to work deliberately without repeatedly restarting or re-explaining your repository.

This walkthrough follows a typical task from opening a project to returning to it later. Commands can change between releases, so use the help available in your installed version as the final reference.

§ Step 1: Check the session with /help and /status

Start Claude Code in your project directory, then enter /help. It shows available commands and helps distinguish built-in commands from skills or commands supplied by your project and installed extensions.

Next, run /status to inspect session information, including the current configuration and connection details where available. This is a useful first check when authentication, routing, or model selection behaves differently from what you expected.

If you use Vana API, configure Claude Code through its Anthropic Messages-compatible connection rather than assuming an OpenAI-compatible configuration is interchangeable. Vana API provides a single endpoint at https://api.vanaapi.com that also supports OpenAI-compatible and Gemini native protocols.

§ Step 2: Establish project instructions with /init

In a repository without Claude-specific guidance, run /init. Claude Code inspects the project and prepares a CLAUDE.md file containing instructions for future work.

Review the result before keeping it. Generated instructions are a starting point, not proof that every inferred command or convention is correct. Make the file useful by checking:

• The commands for installing dependencies, running tests, and checking types.
• The directories containing application code and generated files.
• Repository conventions that are not obvious from individual source files.

§ Step 3: Maintain those instructions with /memory

Use /memory to access instruction files rather than repeatedly pasting the same guidance into conversations. Put durable project rules in project instructions and personal preferences in the appropriate user-level instructions.

Keep these files concise. “Run the focused tests before the full suite” is reusable guidance. A temporary debugging hypothesis usually belongs in the current conversation instead.

§ Step 4: Review tool access with /permissions

Before asking Claude Code to install packages, execute scripts, or modify a large part of the repository, open /permissions. Review which tool actions are allowed, denied, or require confirmation.

Prefer narrow permissions over broad approvals. Allowing a specific test command is easier to reason about than granting unrestricted shell access. Permissions reduce accidental actions, but they do not replace reviewing commands or checking the resulting changes.

§ Step 5: Inspect the model with /model

Use /model to inspect or change the active model where your configuration supports it. With a relay, the available selections and accepted identifiers depend on the provider configuration; the default picker may not reflect the provider’s entire catalog.

For example, if your Vana API configuration exposes Claude Sonnet 5.5, verify the configured identifier rather than guessing it from the display name. Create a Vana API account if you want to use its token-billed access without a monthly fee.

§ Step 6: Watch context with /context, then use /compact

Run /context when a session grows long. It helps you understand how the available context is being used, including conversation content and other loaded material.

When you need to continue the same task with less accumulated conversation, use /compact. You can add a focus instruction, such as /compact Preserve the failing test, files changed, and remaining verification steps. Compaction summarizes earlier work; it does not guarantee that every detail survives. Keep critical decisions in files or explicit notes.

§ Step 7: Separate tasks with /clear

Use /clear when moving to unrelated work. It clears the conversation context, not your repository changes. Before clearing, inspect your diff and record anything the next task needs.

§ Step 8: Return with /resume and check /cost

Use /resume to reopen a previous conversation when continuing the same investigation. Recheck the working tree because files may have changed since that session.

Finally, use /cost for the usage information your installation exposes. Treat local estimates as guidance, not your provider’s invoice. With Vana API, billing is based on actual token usage; check provider-side usage records when reconciling spend.