Welcome to the third unit of Foundation — Getting Started with Claude Code! In the previous units, we learned what Claude Code is and how to manage basic sessions using commands like /clear, /exit, and /resume. Now we are ready to gain more control over our development environment.

This lesson introduces the essential commands that allow us to inspect and configure our Claude Code sessions. We will learn how to check our current session state, switch between different Claude models, manage what Claude can access, and understand the settings that govern our workflow. These commands give us the visibility and control we need to work effectively with Claude Code. Let's explore these powerful tools together.

When we work with Claude Code, we are not just having a conversation; we are operating within a specific environment with particular settings, permissions, and capabilities. Understanding and controlling this environment is crucial for effective development.

Think of these commands as the "dashboard" of a car: they tell us what mode we are in, what resources are available, and how to adjust our settings. Just as we would not drive without checking our mirrors and gauges, we should not develop without understanding our Claude Code environment. These commands help us work more intentionally and troubleshoot issues when things do not behave as expected.

The first and most fundamental command is /status, which provides a detailed snapshot of our current session. This command reveals the inner workings of our environment through a tabbed interface. Let's see what information it reveals:

The output is organized into tabs that you can cycle through using the Tab key. In the Status view, we see several critical pieces of information. The Session ID is a unique identifier for your current work. The cwd (current working directory) shows exactly where Claude Code will create and modify files. Finally, the Model section confirms which AI version is currently processing your requests.

This command becomes invaluable when something seems off. If Claude Code is not finding files we know exist, checking the cwd confirms we are in the right directory. If you are unsure why Claude is behaving a certain way, the Setting sources line tells you which configuration files (like Local or Shared project settings) are influencing the session. The /status command is our first line of investigation.

Claude Code does not use just one AI model; instead, it offers three different models, each with distinct characteristics. These models sit along a spectrum of capability, speed, and cost. Understanding this spectrum helps us choose the right tool for each task.

The three models are Haiku, Sonnet, and Opus. Haiku is the fastest and most economical, designed for quick tasks and rapid responses. Sonnet, the default and recommended model, balances capability and cost for general development work. Opus is available as a legacy option (version 4.1) that may still be useful for certain complex tasks, though it comes with higher costs and may eventually be phased out.

The differences go beyond just capability. Haiku processes requests quickly but may struggle with intricate architectural decisions. Sonnet represents the current recommended balance, handling sophisticated reasoning for most development scenarios. Opus 4.1, while labeled as legacy, can still be selected when you need its specific capabilities, but Sonnet 4.5 is generally the better choice for complex work. Knowing these distinctions allows us to optimize our workflow.

To see which models are available and switch between them, we use the /model command. When we enter this command without arguments, Claude Code presents an interactive selector showing all available options:

The selector displays each model with its pricing structure. The format $X/$Y per Mtok shows cost per million tokens: the first number is for input tokens (what we send to Claude), and the second is for output tokens (what Claude generates). Notice how Sonnet costs $3 for input and $15 for output, while Haiku is significantly cheaper at $1 and $5. Opus, marked as legacy, is the most expensive at and .

While the interactive selector works well, we can also switch models directly by specifying the model name as an argument. This is faster when we know exactly which model we want. Let's switch to haiku:

The confirmation message tells us the switch was successful and shows the model identifier. Now all subsequent interactions in this session will use Haiku until we switch again or start a new session.

This direct approach is particularly useful in workflows where we know we want a specific model for a particular phase of work. For example, we might use Haiku for quick edits and formatting, then switch to Sonnet or Opus when tackling more complex logic.

Understanding when to use each model is a skill that develops with experience, but we can establish some clear guidelines. The choice involves balancing three factors: speed, capability, and cost.

Use Haiku for routine tasks that do not require deep reasoning: fixing typos, formatting code, writing simple test cases, or generating boilerplate. Haiku excels at well-defined tasks where the approach is straightforward. Its speed and low cost make it ideal for iteration and quick fixes.

Use Sonnet as your default for general development work: implementing features, refactoring code, writing documentation, or debugging moderate complexity issues. Sonnet handles most development scenarios effectively, including complex challenges that you might have previously considered for Opus. As the recommended model, it represents the best balance of capability and cost.

Use Opus (legacy) sparingly and only if you have specific workflows that rely on it. Since it is marked as legacy, it may be deprecated in future versions. For most complex tasks that would traditionally call for a premium model, Sonnet 4.5 is now the recommended choice.

The pricing difference is significant: using Opus for simple tasks could cost five times more than Haiku. The legacy status of Opus also suggests that investing heavily in workflows dependent on it may not be sustainable. Matching the model to the task is both economical and effective, with Sonnet serving as the versatile workhorse for the majority of development scenarios.

Another essential command is /context, which shows how Claude Code is using its available working memory. Think of this as checking how full Claude's "workspace" is during your session. Let's see what this command reveals:

The most important line is at the top: 61k/200k tokens (30%). This tells us we are using 61,000 out of 200,000 available tokens, or about 30% of Claude's working memory. The visual bar provides an at-a-glance view of this usage.

The breakdown shows what is consuming this space. The System prompt and System tools are overhead that Claude Code requires to function. The Messages line shows our conversation history, which in this fresh session is minimal. Most importantly, we see 139k tokens of free space (69.6%), meaning we have plenty of capacity remaining.

Two additional commands round out our essential toolkit, even though we have not used them yet in this session. The /config command allows us to view and modify our Claude Code settings, such as default models, editor preferences, and session behaviors. You can also access these settings by navigating to the Config tab within the /status output.

The /permissions command manages what actions Claude Code can perform. Since Claude Code can read files, write code, and execute shell commands, permissions control which operations require our approval. We might allow Claude to read any file freely but ask for confirmation before executing destructive commands. This creates a safety layer while maintaining productivity.

Both commands follow the pattern we have seen with other slash commands: enter them without arguments to see current settings, or use them with arguments to make changes. We will explore these in more depth in future courses in this learning path.

In this unit, we have equipped ourselves with the essential commands for controlling our Claude Code environment. We learned to check our session state with /status, switch between models using /model, inspect what Claude can access with /context, and understand the roles of /config and /permissions in managing our workflow.

These commands give us visibility and control, transforming Claude Code from a black box into a transparent, configurable tool. We now understand the tradeoffs between Haiku's speed, Sonnet's balance, and Opus's capability, allowing us to choose the right model for each task. We can verify our environment state and troubleshoot issues by inspecting /status and /context.

With these fundamentals mastered, you are ready to put them into practice! The upcoming exercises will challenge you to navigate between models, check your environment, and make informed decisions about when to use each command. This hands-on experience will cement these concepts and prepare you for the real development work ahead.