Claude Code and the VS Code Extension

Claude Code is Anthropic's official coding agent: a CLI tool and a VS Code extension that are two faces of the same underlying system. Understanding the distinction between the two modes matters because they serve different purposes and create very different working experiences, even though they share the same models and the same core capabilities.

The CLI mode is the original and most powerful form of Claude Code. You invoke it by typing claude in your terminal, and it opens an interactive session where Claude has full access to your file system, can run any shell command your user account can run, and can operate entirely without the VS Code UI. In CLI mode, Claude Code can create files, install packages, run test suites, commit to git, deploy to cloud providers, and chain together arbitrarily long sequences of steps. It is a terminal-native agent that can be pointed at any project, including projects on remote servers via SSH. This is the mode described throughout the CLAUDE.md documentation and the mode that supports autonomous, multi-hour task execution.

The VS Code extension integrates Claude Code's capabilities into the editor panel. You get a chat interface in the sidebar, inline diff previews, and the ability to reference open files or selected code directly in your prompts. The extension is more approachable for developers who work primarily within the VS Code UI and prefer to see AI-assisted changes in context rather than in the terminal. It uses the same models as the CLI, Claude Sonnet by default and Claude Opus 4.6 for more complex tasks, and it supports the same CLAUDE.md project context system. One important limitation: the VS Code extension does not support MCP servers in the same way the CLI does; MCP configuration must be managed via the CLI.

Pricing in early 2026 runs on two tracks. API-based pricing charges per token: Claude Sonnet at $3 per million input tokens and $15 per million output tokens, Claude Opus 4.6 at $15 per million input tokens and $75 per million output tokens. For heavy usage, a Claude Max subscription at $100 per month provides the highest usage limits with Opus 4.6 and is the practical choice for developers who use Claude Code as their primary coding environment. Claude Pro at $20 per month provides Sonnet access with lower usage caps, suitable for moderate daily use. The key differentiator between Claude Code and every other agentic IDE is the reasoning quality of the underlying model: Opus 4.6 has noticeably better judgment on complex architectural questions, ambiguous requirements, and multi-constraint problems than the models available in Cursor or Windsurf.

Every agentic IDE faces the same foundational problem: the AI has no persistent memory of your project between sessions. Each time you start a new conversation, it starts fresh. Without context, Claude Code has to spend tokens inferring what your project is, what conventions you follow, what commands build and test it, and what constraints matter. The CLAUDE.md system is the solution to this problem: a plain text file you maintain at the root of your project that Claude Code reads automatically at the start of every session.

A well-written CLAUDE.md dramatically improves the quality and consistency of Claude Code's output. It should contain the information that a new senior engineer would need to be productive in your codebase on their first day. That includes: the project's purpose in one or two sentences, the tech stack (language, framework, key libraries and their versions), the directory structure with brief annotations of what lives where, the commands to install dependencies, run the dev server, run tests, and build for production, any coding conventions you enforce (naming patterns, file organization, how you handle errors), and any constraints that are non-negotiable (do not use class components, always use typed errors, all API routes must include authentication middleware).

The CLAUDE.md system supports nesting. If your monorepo has a frontend directory and a backend directory, each with different conventions, you can place a CLAUDE.md in each subdirectory. Claude Code reads the root CLAUDE.md first, then the subdirectory CLAUDE.md when working in that subdirectory. This lets you maintain shared project context at the root level and package-specific context at the package level without duplicating information.

Keep CLAUDE.md updated as your project evolves. When you add a new major dependency, update the tech stack section. When you establish a new convention, add it. When you move to a new deployment target, update the build instructions. The discipline of maintaining CLAUDE.md is the same discipline as maintaining any team documentation: a small time investment per change that pays back every time the AI (or a human) needs to understand the project. Treat it as a living document, not a one-time setup task.

Model Context Protocol (MCP) is an open standard that lets Claude Code connect to external tools and data sources beyond your local file system. Without MCP, Claude Code can read and write files, run shell commands, and use whatever CLIs are available in your terminal. With MCP servers, Claude Code can control a browser, query a database directly, read Slack messages, interact with GitHub issues, send API requests to external services, and much more, all from within the same conversation.

The practical way to think about MCP is as a plugin system for Claude Code's tool set. Each MCP server exposes a set of capabilities that Claude can invoke. The Playwright MCP server gives Claude a browser it can navigate, click, type into forms, take screenshots of, and extract data from. You can ask Claude Code to "log into the staging environment, run the user registration flow, and screenshot the confirmation page" and it will execute that sequence using real browser interactions. The database MCP servers (there are community-maintained versions for PostgreSQL, SQLite, and others) let Claude query your actual data to understand the schema and write migrations that match reality. The Slack MCP server lets Claude read channel history and send messages, useful for agents that need to report progress or fetch requirements from a conversation.

Adding an MCP server to Claude Code uses the CLI. The command structure is: claude mcp add <name> -- <command> <args>. For environment variables, add -e KEY=VALUE flags before the --. For example, adding the Playwright MCP server looks like: claude mcp add playwright -- npx @playwright/mcp@latest. After adding a server, restart Claude Code for it to take effect. MCP servers are stored in your ~/.claude.json file and are available in all Claude Code sessions for the projects you configure them in. The Playwright and GitHub MCP servers are the highest-value additions for most developers: browser control opens up end-to-end testing automation and web data extraction, and GitHub integration lets Claude navigate issues, PRs, and comments directly.

One important note: MCP servers run as local processes on your machine. They are not sandboxed by default, so a Playwright MCP server has access to your browser profiles and a database MCP server has the same access as your database user. Be thoughtful about which MCP servers you install and what permissions they are granted. Official MCP servers from Microsoft (Playwright), Anthropic, and established open-source maintainers are the safest starting point.

The most powerful use of Claude Code is handing it a substantial task and letting it execute autonomously with minimal interruption. This is different from the interactive diff-review loop of Cursor's Cmd+K: it is closer to assigning a task to a capable engineer, checking back when they have a question, and reviewing the result when they are done. Understanding how to structure these tasks and how to configure the permission model is what separates developers who get marginal value from Claude Code from those who use it to compress days of work into hours.

Effective autonomous task prompts share three properties. They are specific about the goal: not "improve the API" but "add a rate limiting middleware to all public API routes using the express-rate-limit package, configure it to allow 100 requests per 15 minutes per IP, return a 429 with a Retry-After header when the limit is exceeded, and add integration tests for the limit behavior." They describe what success looks like: "all existing tests should still pass and the new rate limit tests should cover at least the 429 case and the case where the limit has not been reached." And they name any constraints: "do not modify the existing middleware stack order and do not change any route handler logic."

Claude Code's permission model has three levels. In ask mode (the default), Claude requests permission before running each shell command: you see the command, approve or reject it, and Claude continues. This is the safest mode and the right default for new projects or unfamiliar codebases. In auto-allow mode, Claude executes commands that match patterns you have approved: you might auto-allow npm test and npm run build but still require approval for git push or rm. In yolo mode, Claude executes all commands without asking. Yolo mode is appropriate for throwaway environments, local dev containers, or situations where you have already reviewed the task plan and trust the agent's judgment. Never use yolo mode in a production environment or on a machine with credentials you care about.

The iteration pattern that works best for complex autonomous tasks is: write the task prompt, let Claude run with ask mode, approve the obvious commands, and interrupt with guidance only if Claude takes a wrong turn. After Claude finishes, review the diff as a whole rather than file by file. Run the test suite. If tests fail, you can either fix the issues yourself or hand the failures back to Claude with "here are the failing tests, fix them." This loop, task prompt, execution, test review, iteration, is how experienced Claude Code users handle non-trivial feature implementations.

The difference between developers who get 2x productivity from Claude Code and those who get 10x comes down to a handful of habits. These are not configuration tricks; they are ways of working that compound over time as you and the tool develop a shared understanding of how your projects are structured.

Write clear, specific prompts with context. The most common reason Claude Code produces mediocre output is an underspecified prompt. "Fix the bug" is not a prompt; it is a request for Claude to guess what you mean. "The user registration endpoint at /api/auth/register is returning a 500 when the email is already taken. It should return a 409 with a JSON body of {error: 'Email already in use'}. Fix the handler and add a test for this case." That prompt gives Claude everything it needs. The extra thirty seconds it takes to write a specific prompt saves several minutes of review and back-and-forth.

Use /compact to manage context. Claude Code's context window is large (200,000 tokens for Sonnet, the same for Opus 4.6), but a long session with many file reads and command outputs can fill it. When a session is getting long, type /compact in the Claude Code CLI to compress the conversation history into a summary while preserving the working state. This keeps the session usable without losing the thread of what you have been building. As a rule of thumb, use /compact after completing a major subtask before moving to the next one.

Match the model to the task. Claude Sonnet handles the vast majority of coding tasks well: adding features, writing tests, refactoring, fixing bugs in well-defined code. Opus 4.6 is worth the cost for tasks that require genuine reasoning about trade-offs: architectural decisions, debugging complex concurrency issues, designing APIs that need to be stable across multiple clients, or any task where you would spend significant time yourself thinking through the problem before writing a line of code. Routing routine tasks to Sonnet and reserving Opus for the hard problems is the most effective cost management strategy.

Keep CLAUDE.md updated. This cannot be said enough. A stale CLAUDE.md is worse than no CLAUDE.md, because Claude will confidently follow instructions that no longer apply to the current state of the project. Spend two minutes updating CLAUDE.md whenever you add a dependency, establish a new convention, or change the build setup. That two minutes of maintenance prevents minutes to hours of confused or incorrect AI output per session.

Use subagents for parallel work. Claude Code supports a Task tool that lets Opus 4.6 spawn Sonnet subagents to handle parallel workstreams. For example: while one subagent writes unit tests for a new module, another can update the API documentation, and a third can check for similar patterns in the rest of the codebase that should be updated consistently. Subagent dispatch is more advanced usage, but it is worth learning once you are comfortable with single-agent autonomous tasks. The effective token cost per unit of work drops dramatically when Sonnet handles the grunt work and Opus handles coordination.