What Is Claude Code? An Operator's Deep Dive (2026)

I switched from Cursor to Claude Code over a year ago and have been operating it daily on production codebases since. The vendor docs explain what it is. They do not explain what a bypassPermissions grant actually costs you when an agentic loop misreads the task, or how a coarse Bash allowlist quietly widens across a session. Everything below is hands-on operator experience, not a benchmark harness, and the dated claims reflect what I could verify against public docs on the page date.

TL;DR

Claude Code fits operators who live in a terminal, want an agent that operates on a real filesystem with explicit per-tool permission gates, and can maintain CLAUDE.md plus a small library of skills, hooks, and subagents in plain markdown and JSON. Pick Cursor if IDE-embedded ghost-text and GUI diff review matter more than a programmable harness. Pick Aider if multi-provider routing across Anthropic, OpenAI, and others is a hard requirement. Skip Claude Code if offline operation is required or a non-Anthropic model is mandatory. On pricing as of 2026-05-06: Anthropic offers consumer subscription tiers (Pro and Max) that bundle Claude Code usage under session and weekly caps, plus pay-as-you-go API billing through the Anthropic Console. Tier names, dollar amounts, and cap windows shift often enough that I won't pin them here, verify the current plan page against your expected workload before committing.

The mental model

Claude Code started as a CLI and has since grown into a family of surfaces. As of 2026-05-06, Anthropic ships the terminal CLI alongside several non-CLI surfaces (editor extensions and additional entry points), with availability and feature scope varying by plan and account type. This page is about the CLI surface specifically, because that is what I have operated in sustained production use and what the rest of the page's permission, hook, and headless-CI material maps to cleanly. Other surfaces share the model and much of the harness vocabulary, but their permission UX, telemetry, and extension story differ enough that I would rather under-claim than mislead.

Within the CLI surface: the binary sits in $PATH, you run claude in a project directory, and it operates on the files in that directory using a fixed set of tools. Directionally, the CLI exposes filesystem read and write, shell execution, file search and pattern matching, web fetch, and a delegation primitive for subagent dispatch. The exact tool inventory and naming has shifted across releases, so check the installed CLI's docs at https://docs.claude.com/en/docs/claude-code rather than treating any specific list as stable.

The mental model that makes everything else click: Claude Code is a harness around the Claude API that owns the parts of the system most people think of as "the agent." Filesystem access lives in the harness, not the model. The permission policy that gates writes and shell commands is local. Memory files (CLAUDE.md at project, parent, and user scope) are loaded by the harness on every turn. Hooks fire in your shell, with your environment, before and after tool calls. Model routing (which Claude variant answers, whether long-context applies) is decided by the harness based on plan and config. The model picks the next tool call and writes the next token; everything between that and your disk is harness behavior you can inspect and override.

Three concepts to internalize:

1. CLAUDE.md is the project's persistent instructions. It is loaded into every session for that directory. This is where conventions, constraints, and "never do X" rules live. It is the single most important file in any Claude Code-driven repo.
2. Permission modes are how the harness gates write and shell access, ranging from a default that prompts on each potentially destructive action, through intermediate modes that auto-accept some classes of edits, up to a fully autonomous mode that bypasses prompts. The exact mode names (acceptEdits, plan, bypassPermissions, and others) are [unverified] against a current docs anchor on this page; verify the names and semantics in the installed CLI's docs before scripting against them.
3. Plugins, skills, subagents, and hooks are the extensibility points. They are all plain markdown and JSON. There is no SDK to learn beyond knowing where to put a file.

The landscape

Claude Code sits in the agentic-coding-tool category alongside several products that differ on the axes operators actually feel:

• Cursor (IDE fork of VS Code) and Windsurf: editor surface is the IDE itself with inline ghost-text and GUI diff review; provider routing spans Anthropic, OpenAI, and others; no hook or subagent surface comparable to Claude Code's; permission model is GUI-driven accept/reject on diffs rather than per-tool gates; agent config lives in proprietary settings panels and rules files rather than plain markdown a second harness can read.
• Aider: terminal surface like Claude Code; provider routing is broader (multi-provider via a router layer); no skills, subagents, hooks, or MCP extensibility layer; permission model is a tighter search-replace patch loop with per-edit confirmation rather than the tool-grant matrix Claude Code exposes; conventions file is plain text and ports conceptually, but there is no equivalent surface for the harness extensions Claude Code carries.
• GitHub Copilot Workspace and OpenAI Codex CLI: vendor-tied to GitHub/Microsoft and OpenAI respectively, each with its own permission UX and extensibility story; routing is locked to the vendor's models.
• Cline (formerly Claude Dev) and Roo Code: VS Code extensions that approximate Claude Code's loop inside the editor, with their own permission prompts and config surfaces; the artifacts do not interchange with Claude Code's CLAUDE.md, skills, or hooks without a rewrite.

The landscape splits along two axes: where the agent runs (terminal vs IDE) and what models it talks to (single-vendor vs multi-vendor). Claude Code is terminal-first and Anthropic-only. That is a feature for some teams and a non-starter for others.

What actually matters operationally

Vendor pages talk about benchmarks and "agentic capabilities." Operators care about a different list:

Permission boundaries. The default mode prompts on every write and shell command. That is annoying for the first hour and load-bearing for the next year. The --dangerously-skip-permissions flag (and the equivalent bypassPermissions mode) skips the prompts. I've watched a bypassPermissions agent successfully rm -rf node_modules to "clean up" before a build. Use it in containers and worktrees, not on your main checkout.

Context cost. Which model the harness picks by default and whether you get the long-context tier at all depend on your account type, plan, provider route (direct API, Bedrock, Vertex, consumer Pro/Max), and the Claude Code version installed. Check the current docs for your route before assuming a context budget. Whatever the ceiling, long sessions accumulate file reads, tool outputs, and prior turns. The harness compresses context automatically when it approaches the limit, but compression is lossy: the summarization step paraphrases prior turns and can quietly drop constraints stated early in the session, while bulky tool outputs (verbose test logs, long file reads, web fetches) keep getting pulled back in on subsequent turns. The directional pattern I see: a session that started with surgical intent drifts as the hours pile up, and the drift tracks compression events more than wall-clock time. Best practice: use /clear between unrelated tasks rather than letting one session carry context across half a day of unrelated refactors.

Cost predictability. API mode bills per token at Anthropic's published rates. Autonomous sessions become materially more expensive as context grows and tool outputs (long file reads, verbose test logs, web fetches) get pulled back into the next turn, so a session that felt cheap in the first ten minutes can compound quickly across an afternoon of refactors. The Pro and Max consumer plans bundle Claude Code usage with weekly caps that effectively flatten cost, but they throttle when the cap is hit. Plan structure shifts often enough that the metered-versus-capped split is the durable shape; the specific tiers and limits in between are not. Verify the current plan page against your expected workload before committing.

Tool surface. Bash is the highest-risk built-in tool because it can reach outside the model's file-edit surface in ways the other tools (Read, Write, Edit, Glob, Grep) cannot. Once granted, the agent can run any shell command the user account can run unless the invocation is sandboxed (container, worktree, restricted user) or constrained by explicit deny rules and command-pattern allowlists in settings.json. Hooks add a second layer of validation, but the default posture is "ask before each command," and scripting around the prompts is equivalent to granting full shell access.

Debuggability. Agentic loops fail in unintuitive ways, and the local scrollback alone is not enough to reconstruct a 40-tool-call session. Claude Code can export OpenTelemetry signals when CLAUDE_CODE_ENABLE_TELEMETRY=1 is set with an OTel endpoint configured, and OTel is useful here, but the surface has more knobs than "turn on traces." Metrics, events/logs, and traces are separate signals with separate cost profiles. Content attributes (prompts, tool inputs, tool outputs) are gated behind their own opt-in flags, and once enabled they will carry whatever the agent saw, including secrets pasted into prompts and credentials echoed by shell commands, unless a redaction layer sits in the export path. Backend choice matters too: high-cardinality attributes like per-session IDs and per-file paths will inflate Tempo or Datadog bills if the exporter is not configured with a sensible interval and attribute filter. Treat the recommendation as directional: turn telemetry on, but make deliberate choices about which signals export, what content rides along, and which backend absorbs the cardinality. The methodology I use in my own setup is metrics plus event logs by default, traces enabled only for sessions I am actively debugging, content attributes off in shared environments, and a redaction step in the collector before anything leaves the machine.

Lock-in shape. Worth naming the dimensions directly rather than waving at "soft lock-in." Four axes matter. Model runtime: the harness only talks to Anthropic models (direct, Bedrock, Vertex), so swapping to a non-Anthropic model means swapping harnesses. Prompt-artifact portability: CLAUDE.md, slash commands, skills, subagents, and hooks are plain markdown and JSON in your repo, so the content ports to Cursor rules, Aider conventions, or another harness, but the runtime semantics (how hooks fire, how subagents are dispatched, what permission modes mean) do not, so each artifact needs a rewrite even when the intent carries over. Session state: transcripts and compressed context live in a local cache and are not portable to another agent mid-task; you cannot pause a Claude Code session and resume it elsewhere. Operational telemetry: if you wired OTel exports into your own backend, that survives a harness change; if you relied on the Console's usage view, that does not. Net: lighter than a hosted-agent platform that owns proprietary memory, workflow state, and a custom DSL, heavier than a thin CLI wrapper around a provider-agnostic model router.

Detailed teardowns

Claude Code as it ships today

Position in the mental model: a CLI that lets Claude read, edit, and run shell commands in a local checkout under permission controls.

Architecture overview: A single CLI binary that lands in $PATH via one of several distribution channels. Installation paths vary across native installers, package managers, and language-runtime registries, and update behavior depends on which channel was used, so check the current docs at https://docs.claude.com/en/docs/claude-code rather than assuming a single canonical command. On startup the harness loads project-level instructions from CLAUDE.md and merges in user-scoped instructions from a home-directory config; it also auto-discovers skills, subagents, and slash commands from project-scoped and user-scoped directories, and persists session transcripts to a local cache. The exact filenames, directory paths, and parent-directory traversal rules have shifted across releases, so verify the current conventions against the installed CLI's docs before scripting against them rather than trusting any specific path from a comparison page.

Cost / scale / ops tradeoffs: With the API key route, costs are unbounded and proportional to context. With the consumer plan route, costs are capped but throttled when the cap is hit; specific tier prices and cap windows have shifted multiple times in the past year, so check the current plan page rather than trusting any pinned dollar figure. Admin controls split across routes: individual consumer subscriptions, metered API billing through the Anthropic Console, Claude for Teams, Claude Enterprise (which layers in SSO and managed policy), and cloud-provider routes (Bedrock, Vertex) each carry their own billing surface, identity story, and policy posture. Pick the route that matches your governance model rather than retrofitting one to fit. Self-hosted observability via OTel is available; without it, auditability is limited. There is no sanctioned trail of which tools fired, what they returned, what each session cost, where latency went, or where a loop went off the rails, only the local scrollback and the Console's delayed usage view.

When it's the right call: terminal-resident operator, Anthropic is acceptable as a sub-processor for code, willing to write CLAUDE.md and curate skills, values explicit permission gates over IDE polish.

When it's the wrong call: IDE-first developer who wants inline ghost-text completion, regulated environment that forbids cloud model providers, team that needs centralized identity and policy controls that the consumer-plan tier does not offer.

Cursor

Position in the mental model: IDE-first coding assistant; the agent is a panel inside a fork of VS Code.

Architecture overview: Forked editor with proprietary indexing of your codebase, model routing across Anthropic, OpenAI, and additional providers, and an "Agent" mode that approximates Claude Code's loop inside the editor. Cursor offers paid individual and business tiers with usage-based differences between them; check the current pricing page before committing, since the plan structure has shifted multiple times in the past year.

When it's the right call: developers who live in VS Code, want inline tab-completion plus an agent in one tool, prefer GUI-driven file diff review, accept Cursor as the data path.

When it's the wrong call: terminal natives, teams that want to programmatically extend the agent's behavior with hooks and subagents, anyone who wants their agent harness to be inspectable plain-text files.

Aider

Position in the mental model: terminal-native, multi-provider coding agent with a narrower CLI workflow than Claude Code.

Architecture overview: Python CLI with project-level configuration files and a conventions document that the agent loads each turn. It routes to multiple providers (Anthropic, OpenAI, and others) through a model-router layer, and edits files via search-replace patches the model emits. Exact config filenames, the router library, and the current provider matrix shift across releases, so verify against the Aider docs before wiring it into a workflow rather than trusting any specific path or provider name from a comparison page.

When it's the right call: you need provider flexibility across a wider routing surface than Claude Code offers, you want a tool that isn't tied to a single vendor's roadmap, you prefer a tighter CLI workflow without the skills, subagents, and hooks layer.

When it's the wrong call: you want skills, subagents, MCP servers, hooks, or any of the extensibility surface Claude Code has built up over the past 18 months.

The standards layer

There are two emerging standards that intersect with Claude Code.

MCP (Model Context Protocol) is Anthropic's open protocol for exposing tools and data sources to LLM-powered applications. Claude Code natively supports MCP servers via local configuration files at user and project scope; check the current docs at https://docs.claude.com/en/docs/claude-code for the exact paths and config keys before wiring servers in, since this surface has moved before. As of 2026-05-06, MCP is becoming a practical interop layer: a growing set of agent harnesses and IDE plugins consume MCP servers, and that direction looks durable. In practice, though, "write once, run across every MCP-compatible client" is aspirational. Server portability depends on which transports a client supports (the protocol defines several, and not every client implements all of them), how auth is wired across clients (some support bearer tokens, some support OAuth flows, some support neither), what permission model the host enforces around tool calls, and the maturity of each client's MCP implementation. I have had servers that work cleanly under Claude Code need adapter shims to run under other harnesses. Treat MCP as the right bet for cross-agent tooling, not as a guarantee that a server written for one harness drops in unchanged elsewhere.

OpenTelemetry semantic conventions for GenAI are still evolving but exist. Claude Code's telemetry export uses the gen_ai.* attribute family, which means Claude Code traces show up in Tempo, Grafana, and Datadog alongside spans from any other GenAI-instrumented app. The conventions are not stable across versions, so dashboards built today may need attribute renames in 12 months.

What these standards do not yet solve: cross-agent session portability (you can't pause a Claude Code session and resume it in Aider), shared memory across agents, and unified billing across providers when an agent uses multiple models in one task.

Things nobody talks about

Duplicate slash-command names create confusing resolution behavior. If a user-scoped command at ~/.claude/commands/deploy.md and a project-scoped command at .claude/commands/deploy.md both exist, which one fires is not obvious from the call site, and no warning is emitted at the prompt. I lost an hour to a stale /deploy definition shadowing the one I thought I was editing. The durable advice: keep command names unique across scopes when you can, and when a slash command behaves unexpectedly, grep both ~/.claude/commands/ and <repo>/.claude/commands/ (plus any plugin command directories) before debugging the command body itself. claude --debug surfaces which file the harness loaded for a given invocation in my setup, which is the fastest way to confirm.

Broad Bash permission grants can outlive the single prompt that asked for them. This is the gotcha that bit me hardest, and the exact behavior depends on how the grant was phrased and what's in settings.json, so treat what follows as directional rather than a spec. In my own sessions, accepting a Bash grant for a coarse pattern (anything that reads as "allow this kind of command" rather than "allow this exact invocation") has let subsequent related commands run without re-prompting later in the same session. The implication operators care about: a casual "yes" to one git invocation can quietly authorize a wider surface than intended for the rest of the session, and git push --force is in the same family as git commit from a pattern-matcher's perspective. The defensive posture I now use: explicit command patterns in the permissions block of ~/.claude/settings.json, scoped as narrowly as the workflow tolerates, rather than blanket tool grants approved in the moment. Verify the current matching semantics in the docs at https://docs.claude.com/en/docs/claude-code before relying on a specific pattern syntax, since this surface has changed before.

Context compression is non-deterministic and load-bearing. When the harness compresses context, it summarizes prior turns. The summarization is done by the model itself and varies run-to-run. If an agent loop depends on remembering an exact constraint stated 30 turns ago, that constraint may be paraphrased away after compression. Pin critical constraints in CLAUDE.md, not in conversation.

Hooks run with the user's full shell environment. A PreToolUse hook is a shell command that fires before tool calls. It inherits the user's environment variables, PATH, and shell config. A malicious or buggy hook script can do anything that user account can do. Treat hooks like cron jobs, not like sandboxed plugins.

Cost reporting lags reality. The Anthropic Console can trail the session by enough that a runaway loop spends real money before the dashboard is useful. I could not verify a current --max-budget-usd CLI flag in the 2026-05-06 docs, so I would not document that as a safety control. For scripted runs, constrain tools, run in a sandbox, and put a budget-enforcing gateway or workspace spend limit in front of the API key rather than relying on Console alerts.

Implementation patterns

Pattern 1: Constrained autonomous loop in a worktree

git worktree add -b feature-x ../feature-x
cd ../feature-x
claude --permission-mode acceptEdits \
  -p "Implement the feature described in IMPLEMENTATION.md. \
      Run tests after each change. Stop if tests fail twice consecutively."

This is my default for non-trivial autonomous work. The -b form creates the branch as part of the worktree add, which is the common case; drop the -b and pass an existing branch name when resuming work on a branch that already exists. The worktree isolates the blast radius. acceptEdits reduces prompts for file writes and common filesystem operations like mkdir, touch, mv, and cp inside allowed directories, but it is not a free pass on shell access. Non-read-only Bash invocations (anything that runs a binary, hits the network, or mutates state outside the edit surface) still need explicit permission controls in settings.json, so scope those narrowly before turning the agent loose. The -p flag runs headlessly and exits when the agent decides it's done.

Pattern 2: CLAUDE.md as the project's contract

# CLAUDE.md

## Hard rules
- Never modify files in `vendor/` or `node_modules/`
- All new tests go in `tests/integration/` not `tests/unit/`
- Run `npm run typecheck` before claiming a task is done
- Use pnpm, not npm or yarn

## Architecture
- API routes live in `app/api/`, server actions in `app/actions/`
- Database access goes through `lib/db.ts`, never direct prisma calls in route handlers

## What to ask before doing
- Adding a new dependency
- Changing the database schema
- Touching anything under `infra/`

The hard-rules section gets respected because the model loads it into every turn. The "ask before" section reduces the autonomous-loop blast radius without forcing default permission mode.

Pattern 3: Headless invocation in CI

- name: Triage failing test
  env:
    ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
  run: |
    claude -p "Read the test failure in test-output.log. \
               Identify the root cause. Output a one-paragraph diagnosis \
               and the file:line of the likely bug. Do not modify any files." \
      --output-format json > diagnosis.json

Headless mode (-p) plus --output-format json makes Claude Code a script-friendly building block. This pattern works for triage, log analysis, and PR description drafting. Code-modifying agents in CI need stricter sandboxing than this pattern provides.

Conclusion

Pick Claude Code if:

• You're a terminal-resident operator with an Anthropic API key or Pro/Max plan.
• You want a programmable agent harness, not an IDE assistant.
• You're willing to maintain CLAUDE.md and curate skills.
• You can stomach soft lock-in to Anthropic's roadmap.

Pick Cursor if you want IDE polish and don't care about programmability. Pick Aider if you need provider flexibility. Skip the agentic-coding tier entirely if your work is short, surgical, and copy-paste from a chat window is faster than configuring an agent.

Where this space is headed: MCP keeps gaining traction as the interop layer, which weakens single-vendor harnesses' moats. Anthropic's response has been to invest hard in the harness itself (skills, plugins, subagents, hooks), which is the right move. The 12-month bet I'd make: the agent harness layer commoditizes around MCP, and the differentiation moves to model quality plus harness ergonomics. Claude Code is the strongest harness in market today on ergonomics, and Anthropic's current Claude lineup is competitive on model quality for coding workloads. That combination is hard to beat for terminal-native developers right now.

I could be wrong about the standardization timeline. If MCP fragments or Anthropic walls off Claude Code's interop, the calculus changes fast. Recheck this in six months.

Working examples referenced throughout this page (CLAUDE.md templates, hook scripts, headless CI patterns) will be maintained in a companion repo, linked from this page's metadata once the repo is public.