Claude Code

Pricing

Commercial

Platforms

Terminal, macOS, Linux

Website

https://docs.anthropic.com/en/docs/claude-code

Free access note

Anthropic has offered Claude access programs for eligible open-source maintainers.

Caveat

This is not a general free tier; treat it as an application-based maintainer program.

Verdict for 2026

Claude Code is not best understood as a “Cursor without a UI.” It is closer to a senior command-line assistant that can read a repository, form a plan, edit files, run commands, and leave you with a reviewable diff. That makes it powerful, but also less forgiving than an editor autocomplete product.

My take: Claude Code is most valuable when you already have engineering discipline. If your team has clear tests, strong review habits, small issues, and written project conventions, it can turn rough implementation tasks into useful first drafts quickly. If your team lacks those guardrails, it can generate convincing changes that are expensive to validate.

What It Actually Does

Anthropic describes Claude Code as an agentic coding tool that lives in the terminal. In practice, that means the tool is designed around natural-language tasks rather than line-by-line completion. The official docs highlight workflows such as building features from descriptions, debugging errors, understanding unfamiliar codebases, automating repetitive development chores, and using Claude as a Unix-style utility.

That last point matters. Claude Code fits developers who already think in shell commands, Git diffs, logs, scripts, and CI output. It is less about “make my editor smarter” and more about “give this repository a capable coding worker with constraints.”

Recent Official Updates Worth Tracking

Anthropic’s Claude Code changelog is moving quickly, so I would treat this page as a living evaluation rather than a one-time review. The useful 2.1.142 through 2.1.145 changes are not just about model capability; they are about operating Claude Code safely when agents, plugins, skills, hooks, and background sessions become normal. The May 28, 2026 Claude Opus 4.8 launch pushed that direction further, and the June 9, 2026 Claude Fable 5 release changes the top of the model stack again.

The most useful recent changes are around visibility and governance:

• Claude Fable 5 in Claude Code, with a pause caveat: Anthropic announced Fable 5 on June 9, 2026 as its most capable widely released model and the strongest Claude Code model for tasks larger than a single sitting. The intended Claude Code path was /model fable on v2.1.170 or later after running claude update. But the current adoption note matters: Anthropic paused Claude Fable 5 access on June 12, 2026 after discovering classifier calibration issues. My take: prepare the evaluation harness, but do not treat Fable 5 as an active default until Anthropic restores access.
• Fable-specific operating constraints: when access is restored, Fable 5 should be treated as a deliberate escalation model for long autonomous sessions, not the default for every edit. The official Fable page also described practical boundaries: flagged cybersecurity or biology requests can fall back to Claude Opus 4.8, it is not available under zero data retention, and use requires 30-day data retention for safety monitoring.
• 1M context for serious repo work: Claude Code’s model configuration docs say the Fable 5 path supports a 1 million token context window for long sessions with large codebases. This matters for multi-package migrations and long debugging sessions, but it does not remove the need for /context, /compact, and narrow task boundaries.
• Claude Code 2.1.145 agent observability: claude agents --json makes agent state easier to inspect from scripts, OTEL spans now include agent_id and parent_agent_id, and status-line JSON can include GitHub repo and PR context. That is useful when Claude Code work needs to be audited rather than remembered from a terminal scrollback.
• Claude Opus 4.8 and Dynamic Workflows: Anthropic says Opus 4.8 is its coding-specialized frontier model and that Claude Code can now run tens to hundreds of specialized subagents in parallel for long-running work such as large migrations, dependency updates, security remediation, flaky-test cleanup, and issue triage. My read: this is not a normal model bump. It moves Claude Code from “single agent with tools” toward “agent team orchestration.”
• Effort controls now matter more: Anthropic says Opus 4.8 defaults to high effort, while Claude Code users can reach higher effort settings such as xhigh, extra, and max. Fast mode can be much faster for many workloads, but Anthropic explicitly positions it as a speed path rather than the cheapest mode. Teams should decide effort by task risk, not by vibes.
• Plugin discovery before install: the /plugin experience now surfaces commands, agents, skills, hooks, MCP servers, and LSP servers before installation. This matters because plugin adoption should be a dependency and permission decision, not a blind productivity click.
• Background session recovery: recent entries improve /resume, background subagent duration, model preservation, worktree handling, and session configuration. My practical read: background Claude Code is becoming more usable, but every background job still needs a named branch or worktree, a verification command, and a review owner.
• Context-cost and dependency visibility: Claude Code 2.1.143 added more visibility into plugin dependencies and projected context cost. Serious usage often fails less from “bad code” and more from hidden context bloat, expensive prompts, and unclear token burn.
• Managed settings and web security: Anthropic’s enterprise managed settings and web security preview point toward controlled organization deployment. The right takeaway is not “run it everywhere”; it is “define policy before giving an agent more surfaces.”

My take: the 2026 Claude Code story is shifting from “fast terminal agent” to “agent runtime with model routing, Fable-class long-horizon work, parallel subagents, governance hooks, and reviewable work products.” That is the right direction. Once a tool can run background sessions, install plugins, call MCP servers, expose skills, and report GitHub PR state, the important question becomes: can your team review what it did?

Late-June 2026 Operating Notes

The newest Claude Code signal is not only model access. It is operational hardening: remote control, agent teams, permissions, hooks, plugin inspection, and background recovery. I read this as Anthropic trying to make Claude Code usable for long-running engineering work instead of short terminal demos.

Three things now deserve explicit adoption rules. First, subagents should map to real responsibilities such as reviewer, test fixer, migration planner, dependency auditor, or frontend verifier. Second, hooks and permission modes should enforce evidence, not just block scary commands. Third, background work should have named worktrees, proof commands, and a review owner before it starts.

This also makes the Codex comparison sharper. Claude Code is better when the local shell, Git state, MCP servers, and permission prompts are the source of truth. Codex is better when ChatGPT-native surfaces, mobile steering, cloud tasks, project context, and cross-device continuity matter more. Serious teams should reuse the same task brief, acceptance criteria, and proof commands across both.

Practical Commands and Operations

Recent Claude Code updates make the tool more capable, but day-to-day quality still comes from how you operate it. The official command docs now make a useful pattern clear: set the project memory first, choose permission posture, then add subagents, hooks, MCP servers, and plugins only where they reduce ambiguity or increase evidence.

I would use this as the default operating sequence:

• First session in a repo: run /init to create a starter CLAUDE.md, then use /memory to refine architecture notes, test commands, style rules, forbidden areas, and review expectations. Do not let the first task start before the repo contract exists.
• Plan before editing: use /permissions or start with claude --permission-mode plan when exploring an unfamiliar repo. In plan mode, Claude can read and run read-only commands, but it should not mutate source files. This is the right mode for architecture discovery, migration scoping, and risky bug reports.
• Set approval rules explicitly: use /permissions to choose whether edits, shell commands, MCP tools, or specific risky actions require approval. default is safest for sensitive work, acceptEdits is useful for reviewed iteration, auto can reduce prompt fatigue on long work, and bypassPermissions belongs only in isolated containers or VMs.
• Add subagents intentionally: use /agents only when a task has separable responsibility: reviewer, test fixer, dependency auditor, migration planner, or frontend verifier. A subagent should have a narrow description, scoped tools, and a reason to exist.
• Add MCP only for real context gaps: use /mcp when Claude needs GitHub, docs, issue trackers, observability, databases, or internal APIs. Do not connect a broad MCP server just because it is available; connect it because the task needs that context.
• Inspect hooks before trusting automation: use /hooks to review tool-event hooks. Good hooks block dangerous writes, require checks after edits, or validate final claims. Bad hooks silently add side effects.
• Use /plugin as a dependency review step: before installing, inspect which commands, agents, skills, hooks, MCP servers, and LSP servers a plugin adds. Treat plugin installation like adding a development dependency with permissions.
• Recover and audit background work: use /resume for background sessions, and claude agents --json when you need script-readable agent state. Pair this with named worktrees, explicit proof commands, and a review owner.
• Use /context and /compact to manage drift: before a long session drifts, inspect loaded context and compact deliberately. Context bloat is one of the easiest ways for agent work to become expensive and unfocused.

My working rule: run Claude Code in plan or conservative permissions until the task, tests, and files are understood; move to acceptEdits or auto only when the job is narrow and reviewable; reserve bypassPermissions for disposable environments. The best teams will not win by giving Claude Code maximum freedom. They will win by making every permission escalation visible and every completion claim testable.

For Fable 5 specifically, I would add one more rule once access is restored: use /model fable only after the task is written as an outcome with acceptance criteria. Do not micromanage steps; give it the target, constraints, repo boundaries, and proof commands, then review its plan and final diff. If the task is a one-file edit, use Opus or Sonnet-class work instead. Fable’s advantage shows up when the task would otherwise span hours, multiple sessions, or several subagents.

Claude Code and Codex: How To Pair Them

Claude Code and Codex now overlap more than they did earlier in 2026, but they should not be treated as interchangeable. Claude Code is strongest when the working boundary is a local repository, terminal commands, Git state, hooks, permissions, MCP servers, subagents, and proof commands. Codex is strongest when the work should move through ChatGPT account surfaces: Codex App, cloud tasks, connected hosts, mobile steering, Automations, active sessions, thread history, and centralized model or reasoning settings.

A practical split:

• Start local with Claude Code when the first job is diagnosis: read the repo, reproduce the failure, inspect logs, run tests, understand Git state, and write the narrow plan.
• Send parallel or background attempts to Codex when the work benefits from OpenAI-managed cloud tasks, ChatGPT mobile follow-up, multi-repository access, historical thread search, or PR-shaped review.
• Use the same acceptance criteria for both. Compare diff size, proof commands, review time, follow-up fixes, and whether each tool explains why the change is safe.
• Put governance close to the surface: Claude Code should use /permissions, /hooks, /agents, and MCP scopes; Codex should use active sessions, Codex Profiles, workspace settings, model/reasoning sync, and clear Automation boundaries.
• Use specs and skills as the shared contract. OpenSpec and the Skills Matrix make tasks less ambiguous; 9Router or OpenRouter-style routing is a separate cost and fallback layer, not a replacement for task discipline.

My recommendation: use Claude Code for shell-close execution and local proof. Use Codex for cross-surface continuity, cloud or connected-host delegation, and reviewable background work. The strongest workflow is not picking one agent forever; it is making the task brief, permissions, proof commands, and review trail portable across both.

The Bigger Shift: Agent Runtime Productization

The deeper Claude Code story is no longer just “Anthropic has a better coding model.” It is that Anthropic is productizing the runtime around agents. The pattern shows up across ready-to-run agent templates, MCP and connector tooling, Claude Code on the web, custom subagents, hooks, permissions, and background work.

My read: Claude Code is becoming a reference implementation for how serious agent work should be packaged. A useful coding agent now needs a runtime contract, not only a prompt. That contract includes what skills it can use, which systems it can connect to, which subagents can be delegated work, which hooks run before and after actions, which permissions can deny tool use, how long-running sessions report progress, and how final output becomes a reviewable PR or diff.

The runtime pieces are worth separating:

• Ready-to-run agent templates: Anthropic’s finance-focused agent work describes templates made from skills, connectors, and subagents, delivered through Claude Code plugins and related cookbooks. The coding takeaway is that useful agents are becoming installable bundles of behavior, access, and delegation policy.
• Agent connectivity and MCP tooling: the Stainless acquisition message reinforces a simple point: agents are only as useful as the systems they can safely reach. For engineering teams, MCP servers and connectors are becoming the integration layer between a coding agent and GitHub, issue trackers, documentation, databases, observability, or internal APIs.
• Cloud and web long-running sessions: Claude Code on the web lets developers start multiple isolated coding sessions in the browser, watch progress, steer work, and move toward PR creation. That turns Claude Code into something closer to a managed work queue than a local terminal helper.
• Subagents and agent teams: official subagent docs emphasize separate context windows, scoped tool access, explicit delegation, and model selection. This is the most important architecture idea for larger tasks: split responsibility before the main agent loses focus.
• Hooks, permissions, and agentic verification: hooks and Agent SDK permissions create a pre-action and post-action control layer. The valuable pattern is not “run more shell scripts”; it is policy-backed verification: deny risky tools, require approval, trigger checks, and make completion claims prove themselves.
• Background state management: subagents, hooks, background tasks, checkpoints, and session recovery make Claude Code more autonomous. That autonomy is only useful if state is legible: progress, current goal, blockers, elapsed work, stale sessions, and final wrap-up should be visible to humans.

For teams building their own agent platform, this is the main lesson: do not start from “which model is smartest?” Start from the runtime boundary. Define Skill, Tool, Channel, SubAgent, Hook, Permission, Ledger, and Review as first-class concepts. The model is replaceable; the runtime is what makes agent work governable.

Best For

• Developers who want a coding agent inside the terminal.
• Existing repositories where context gathering and multi-file edits matter.
• Engineers who can describe tasks with acceptance criteria, tests, and constraints.
• Codebases with strong conventions, readable structure, and repeatable verification commands.
• Teams that need managed settings, plugin review, and auditable background-agent work.
• Platform teams designing an internal agent runtime with skills, connectors, subagents, hooks, approvals, progress ledgers, and PR handoff.

Not Best For

• Beginners who need constant visual guidance inside an editor.
• Teams without tests, linting, or a reliable way to validate changes.
• Highly sensitive repositories unless permissions, secrets, and access rules are configured carefully.
• People who mainly want autocomplete and inline suggestions while typing.

Where It Beats Cursor

Claude Code can feel stronger than Cursor when the task is repository-scale: trace a bug across files, refactor a small subsystem, write tests, summarize architecture, or automate boring cleanup. Because it works from the terminal, it fits naturally into existing command-line workflows and CI-style verification.

Where Cursor Still Wins

Cursor is still easier for interactive editing. If your workflow is “read code, select a block, ask for an edit, continue typing,” Cursor feels more direct. Claude Code asks you to think more like a task owner: define scope, give context, inspect the plan, review diffs, and run verification.

Claude Code vs Codex vs opencode

Claude Code and Codex compete most directly in the “delegate a software task” category. The decision should be less about brand and more about operating model: which model family performs better on your codebase, which permission model your team trusts, and which tool produces diffs that are easier to review.

opencode is the open-source counterweight. If you want inspectability, model choice, or terminal-native control, opencode deserves a serious look.

Plugins, Skills, and Superpowers

The most important Claude Code extension pattern in 2026 is not “more prompts.” It is workflow enforcement. A strong model can already write plausible code; the harder problem is making it clarify requirements, write a plan, test first, debug systematically, verify claims, and leave a maintainer-friendly trail.

That is where Superpowers is worth understanding. The CodeLove article frames the problem well: many developers still use AI coding tools as “ask for code, wait, paste, retry.” Superpowers changes the shape of the interaction into a staged development loop: design, plan, test, quality. In my view, that makes it more important than a single-task plugin because it changes how Claude Code is allowed to work.

The useful way to read a 20-skill recommendation list is not “install everything.” It is to ask which layer of the agent workflow is currently weak. A solo developer without tests needs verification and debugging skills before niche productivity skills. A team already shipping with CI may benefit more from code review, worktree isolation, and domain-specific skills.

The core Superpowers skills to understand:

• find-skills and skill-installer: useful discovery primitives. They matter because the skill ecosystem is becoming too broad to manage from memory.
• brainstorming: stops feature work before implementation and forces requirements, options, and design tradeoffs into the open.
• writing-plans: turns an approved design into a concrete implementation plan, usually saved under docs/superpowers/plans/.
• subagent-driven-development or executing-plans: executes a plan through smaller units instead of letting one long agent run mutate the whole repository.
• test-driven-development: pushes the agent toward red-green-refactor rather than writing production code first and hoping tests appear later.
• systematic-debugging: slows the agent down when something fails, so it traces root cause instead of stacking guesses.
• verification-before-completion: blocks the common failure mode where an agent says work is finished without running the proof command.
• requesting-code-review and receiving-code-review: make review a first-class step rather than an optional afterthought.
• using-git-worktrees: keeps risky or parallel agent work isolated from your main working tree.
• finishing-a-development-branch: turns “the code is written” into an explicit merge, PR, keep, or discard decision.

My take: Superpowers is best for teams that already believe process matters. It can feel heavy if you only want a quick one-file edit. But for production work, it addresses the real failure mode of coding agents: not lack of intelligence, but lack of checkpoints. The best skills make Claude Code slower at the right moments: before scope expands, before a bug fix becomes guesswork, before an agent declares success, and before a large diff lands in main.

The broader skill catalog is also useful, but I would rank it by evidence value:

• Frontend and browser skills: browser automation, visual verification, accessibility checks, and screenshot-based review are valuable when the output must be judged in a real viewport rather than by code alone.
• Content, SEO, and documentation skills: useful for static sites, docs, release notes, and comparison pages because they enforce structure and reduce thin pages.
• Database, cloud, and infrastructure skills: helpful only when they include permission discipline and dry-run behavior. These skills can save time, but they also have higher blast radius.
• Review, branch, and collaboration skills: highest leverage for teams because they turn agent output into an auditable engineering artifact.

Other Claude Code plugins and extensions should be evaluated by the layer they improve:

• Workflow plugins: Superpowers-style systems that define how Claude Code should move from idea to verified change.
• Tool-access plugins and MCP servers: connectors for GitHub, issue trackers, docs, databases, browsers, or internal systems. These are useful only if permissions and audit boundaries are clear.
• Review and quality plugins: helpers around tests, coverage, linting, security review, dependency checks, and code review.
• Domain skills: narrow workflows for API docs, migrations, data pipelines, UI implementation, release notes, or incident debugging.
• IDE surface plugins: extensions that bring Claude Code closer to VS Code or other editor surfaces. These improve visibility but do not replace verification.

The adoption rule is simple: install plugins that reduce ambiguity or increase evidence. Avoid plugins that merely make Claude Code do more things faster without improving reviewability.

For cost control, I would evaluate 9Router separately from workflow plugins. Superpowers shapes how Claude Code works; 9Router shapes where requests go, how noisy tool output is compressed, and what happens when quota or provider errors interrupt a session. Heavy Claude Code users may need both layers.

Source Notes

• Anthropic’s Claude Code changelog documents Claude Code 2.1.142 through 2.1.145 updates, including claude agents --json, OTEL agent identifiers, GitHub repo and PR status context, plugin dependency visibility, MCP/LSP preview before plugin install, background session recovery, context-cost display, and worktree fixes.
• Anthropic’s Claude Code commands docs, CLI reference, permission modes, hooks, permissions, MCP, and subagents docs describe /init, /memory, /permissions, /agents, /mcp, /hooks, /plugin, /resume, /context, /compact, claude --permission-mode plan, and the operational tradeoffs between default, acceptEdits, plan, auto, dontAsk, and bypassPermissions.
• Anthropic’s Claude Fable 5 and Claude Mythos 5 announcement, Fable product page, and Claude Code model configuration docs describe Fable 5 as the most capable widely released model, available in Claude Code via /model fable, suited to long-running coding and knowledge work, with 1M context, fallback safeguards, version requirements, pricing, and data-retention constraints. Anthropic also notes that Claude Fable 5 access was paused on June 12, 2026 after classifier calibration issues, so this page treats Fable as a watch item until access is restored.
• OpenAI’s ChatGPT and Codex release notes describe mid-June 2026 Codex updates including rate limit reset banking, Codex availability expansion, historical Codex thread search, model and reasoning effort sync across CLI/IDE/cloud tasks, improved remote-session errors, and multi-repository tasks. Those updates are the basis for this page’s Claude Code and Codex pairing guidance.
• Anthropic’s Claude Opus 4.8 announcement describes the May 28, 2026 model launch, coding focus, enterprise rollout, and Claude Code effort modes.
• Claude’s Dynamic Workflows in Claude Code announcement describes parallel specialized subagents, long-running coding workflows, large-scale migrations, dependency updates, issue triage, and PR-oriented work.
• Anthropic’s financial-services agent material describes ready-to-run agent templates composed from skills, connectors, and subagents, delivered through Claude Code plugins and managed-agent patterns.
• Anthropic’s Stainless acquisition post emphasizes agent connectivity, SDKs, CLIs, API documentation, and MCP server tooling as a core part of useful agent systems.
• Claude’s Claude Code on the web announcement describes browser-started isolated coding sessions, progress visibility, steering, and PR-oriented cloud work.
• Anthropic’s Claude Code subagents docs describe custom subagents with separate context, scoped tools, model selection, and task delegation.
• Anthropic’s Claude Code hooks and Agent SDK permissions docs describe hooks, allow/deny rules, permission modes, and runtime callbacks for controlling agent actions.
• Anthropic’s enterprise managed settings docs describe organization-controlled Claude Code configuration.
• Anthropic’s Claude Code security preview describes web execution, security research, prompt-injection mitigations, network allowlists, and sandboxing work.

Adoption Checklist

• Add project instructions that explain architecture, coding style, test commands, and review expectations.
• Configure permissions so secrets and production config are not available to the agent.
• Make test and lint commands obvious.
• Start with small issues: documentation fixes, failing tests, focused bugs, or low-risk refactors.
• Review every diff as if it came from a fast junior teammate who may miss product context.

Quality Signal

The strongest sign that Claude Code is working is not “it wrote a lot of code.” The strongest sign is that it consistently produces small, understandable diffs that pass local verification and match existing project patterns.