Claude Code Opus: a developer guide to deep reasoning and review

What “Claude Code Opus” actually means

Claude Code is the agentic coding environment; Opus is a model family a runtime may make available to it. Current model availability depends on a Claude subscription, Console, cloud provider, or gateway. Use the model configuration guide and session header to identify the actual model, rather than treating “Opus” as a permanent product setting.

Opus 5 is one of Anthropic’s current high-capability models. On Anthropic’s API pricing, it is listed at $5 input and $25 output per million tokens. That rate is not a subscription allowance or another provider’s price. Context size, tool work, and the runtime’s billing model matter as much as the model name.

Set up Claude Code and select the model

Follow the official quickstart for the native installer and authentication path. A paid Claude account or Anthropic Console can provide access; cloud-provider and gateway configurations have their own setup. On Windows, Git for Windows supplies Bash when installed; Claude Code can otherwise use PowerShell. WSL is an option, not a universal requirement.

Start a session with the provider's current Opus alias:

claude --model opus

That flag applies to this launch. In the interactive /model picker, Enter switches and saves the user default, while s switches only for this session. Record the actual selection shown in the header or picker. On the Anthropic API, the alias currently resolves to Opus 5; other providers can map it differently. Opus 5 requires Claude Code v2.1.219 or later, according to the model configuration guide.

Claude Code searches permitted files and brings relevant content into context; it does not automatically understand every file or business decision. A reviewed CLAUDE.md can explain architecture and test commands. Use /init to help create project guidance, not to install the CLI, and inspect what it writes. VS Code and JetBrains integrations can expose selections and diffs, while terminal tools can run tests when authorized.

A good Opus task has a deep question and a small boundary

Consider a risky database migration: a service is moving account preferences from a JSON column to a normalized table, but one background worker may still read the old representation. Ask Opus to map the active read and write paths, identify compatibility behavior, locate the tests, and propose the smallest migration-safe plan. Do not ask it to edit, migrate data, commit, or deploy first.

Review four things before implementation:

• Which code and tests prove the worker is still active?
• How does the plan handle records written before and after the migration?
• What test distinguishes a compatibility read from a silently lost preference?
• Which data or deployment action remains an owner decision?

Then inspect the diff and run the focused migration tests. A capable explanation is not proof that production data is safe.

Permissions and provider access still decide what can happen

Opus does not override a Deny rule, missing credential, protected branch, or database authorization. CLAUDE.md helps with project context; hooks and tests can enforce checks; provider configuration decides which models exist; permissions and credentials control actions. Keep production credentials out of exploratory work unless an accountable owner has authorized the exact operation.

Record the exact model ID, provider, repository revision, prompt, mode, and test output when an investigation will influence a major engineering decision. Historical benchmark scores describe a specific model and test setup, not proof that your migration will succeed. For a simple, well-specified fix, compare the review effort and test result with a faster or cheaper model before making Opus the default for everything.

Budget for the whole investigation

The input includes repeated context and tool results, not just the initial prompt. Output and reasoning can add usage, and parallel agents add their own requests. Prompt caching can reduce eligible repeated-input charges, but it does not make the whole session free. Check the current pricing terms and your provider's billing record rather than treating an old per-session anecdote as a forecast.

Opus 5 has a native 1M-token context window on Anthropic's API; the model configuration guide explains runtime and gateway differences. A larger context window is capacity, not a reason to include every log. Keep relevant evidence, summarize completed branches of the investigation, and inspect what remains after compaction. Set an investigation budget before delegating several long-running comparisons.

Use eesel CLI to give Opus the same approved evidence

The same migration can affect support guidance. In a fictional example, an older instruction says, “If a preference appears to be missing, ask the customer to save it again.” Reviewed code and tests now show a compatibility read from the old storage during rollout. An engineer wants to know whether the support teammate still gives the old advice.

Claude Code running Opus can use eesel CLI from the developer's terminal to inspect that teammate's instructions and compare the wording with the approved code evidence. A person or script can collect the same JSON instead. The useful output is a proposed correction with evidence, not a claim that a customer's preference was checked or migrated.

With Node.js 18.17 or newer, eesel CLI returns JSON from the same teammate as the dashboard. Login authenticates. The owner selects the target before read-only observation:

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
MIGRATION_REVIEW_AGENT="REPLACE_WITH_OWNER_APPROVED_AGENT"
npx @eesel/cli status --agent "$MIGRATION_REVIEW_AGENT"
npx @eesel/cli instructions --agent "$MIGRATION_REVIEW_AGENT"
npx @eesel/cli integrations --agent "$MIGRATION_REVIEW_AGENT"
npx @eesel/cli activity --agent "$MIGRATION_REVIEW_AGENT"

Stop if whoami does not name the intended workspace. In an authorized unattended runner, EESEL_API_URL and EESEL_API_TOKEN take precedence over stored credentials; use EESEL_AGENT_ID only when the owner has pinned the target. Login changes authentication state; the following scoped commands observe it. Share only approved, redacted output with the coding session.

Ask for a short report with three parts:

• Verified facts: quote the current instruction and cite the reviewed code revision and compatibility test. Do not invent a quote if that instruction is absent.
• Unknowns: say whether production rollout status and the customer's actual record remain unchecked. A passing repository test and an eesel activity entry do not settle those questions.
• Owner decision: propose removing the unconditional “save it again” advice until the approved rollout guidance supports it. Do not publish the replacement automatically.

If the owner approves a persistent instruction change, inspect the supported edit command's help and dry-run preview before authorizing it, then read back the result. A separate response test needs permission for billed chats and a non-production teammate with consequential connected actions Disabled. In fresh conversations, supply the approved scenario and ask what a customer should do before and after migration. Inspect the replies, activity, and held approvals against that policy; do not let a fluent answer stand in for checking real data. The read-only comparison itself needs no customer-record mutation or change to action settings.

The dashboard illustrates the workspace that the CLI inspects; it is not evidence that the fictional migration review ran.

Turn an Opus investigation into clear support guidance with eesel CLI

Opus can make a difficult codebase question easier to reason about. eesel CLI can make the approved support context visible to the owner who must decide what changes next. Try eesel to evaluate that handoff in a controlled workspace.