How to Use Claude Opus 5: A Failure-Tested Guide

Claude Opus 5 launched today. I already had a test suite waiting for it: the failures Fable 5 and Opus 4.8 left behind. The practical way to use Opus 5 is not to admire its launch benchmarks. Give it your failed cases, define proof outside the model, and measure whether the new capability changes the result.

My archive contains 561 Claude Code session files. In the first measured comparison, 21 were Fable-dominant sessions and 42 were Opus 4.8-dominant sessions. That history gave me something more useful than a generic prompt collection: cases where the harness declared success before the artifact existed, widened scope, trusted a tool echo, or retried an external failure without characterizing it.

I do not mean a public leaderboard benchmark. This regression set came from expensive mistakes.

This page owns the practical how-to and deployment question. If you want a model-to-model capability comparison, read my separate Fable 5 vs Opus 4.8 analysis. Keeping those jobs separate matters: one page helps you choose a model, while this one helps you operate Opus 5 without repeating old failures. If you need the broader tooling foundation first, begin with the complete Claude Code guide.

What changed in Claude Opus 5?

Claude Opus 5 is Anthropic’s new high-capability model for difficult coding and agentic work. At launch, Anthropic priced it at $5 per million input tokens and $25 per million output tokens, matching Opus 4.8. Anthropic positions Fable 5 above it for the hardest long-running tasks, so Opus 5 is not a universal replacement.

The launch claims are useful context, not proof for your workload:

Question	Launch answer	What you still need to test
Is it available?	Yes, in Claude products and the API as claude-opus-5	Whether your account and SDK expose it
Is it cheaper than Fable 5?	Anthropic says roughly half the price	Your cost per accepted task
Is it better than Opus 4.8?	Anthropic reports more than twice the Frontier-Bench performance	Your own failure and regression set
Is it safer?	Anthropic reports its lowest misaligned-behavior score to date	Your permissions, boundaries, and audit trail
Is fast mode useful?	About 2.5 times faster at twice the base price	Whether latency changes the business outcome

How should you use Claude Opus 5?

Use Claude Opus 5 with a complete brief, an explicit acceptance condition, a representative failure set, and independent verification. Anthropic’s own prompting guidance says Opus 5 works well with existing 4.8 prompts, but it can over-verify, over-explain, or widen scope when the operator leaves those boundaries vague.

1. Freeze the failures before changing the prompt

Do not tune the test after seeing the new model’s answer. Select 10 to 30 cases that represent work you actually care about, then freeze:

• the input and starting files
• the allowed tools and permissions
• the acceptance command
• the time and token budget
• the required evidence artifact

Include easy passes, ordinary work, and failures. A suite made entirely of catastrophic edge cases tells you how the model fails, but not whether it is worth using every day.

2. Put the acceptance condition in the original brief

Opus 5 performs best when it receives the complete specification up front. State what can change, what cannot change, and what proves completion. For a code task, that can be:

Change only src/checkout and its tests.
Preserve the public API and database schema.
The task is complete when:
1. the new regression test fails before the fix,
2. the targeted suite passes after the fix,
3. pnpm check passes, and
4. artifacts/checkout-result.json records both command results.
Report unresolved failures instead of describing them as fixed.

That last sentence matters. The more capable the model becomes, the less useful its own completion message becomes as proof.

3. Sweep effort instead of buying the maximum by habit

Run the same representative cases at the effort settings your environment supports. Start lower, then increase effort only when it changes accepted-task rate or reduces rework enough to cover the added token cost.

Track:

accepted_task_rate = accepted_runs / total_runs
cost_per_accepted_task = total_model_cost / accepted_runs
rework_rate = runs_requiring_human_repair / total_runs

Choose the least expensive setting that crosses your reliability threshold. A longer reasoning trace does not make the bill worthwhile by itself.

4. Let Opus 5 self-check, then verify it independently

Anthropic says Opus 5 already self-verifies aggressively. Repeating “double check everything” can waste tokens or make the model loop. Ask for the task and the evidence once. Then let a separate deterministic command decide whether it passed.

Good evaluators include:

• unit, integration, and browser tests
• JSON Schema validation
• type checking and linting
• a database query over the resulting rows
• a screenshot or generated file with an exact path
• a forced execution of the scheduled job

An LLM judge can add diagnostic notes, but it should not be the only gate for a claim that can be tested mechanically. My evidence-based AI code verification guide goes deeper on this boundary.

5. Constrain scope, delegation, and reporting

Tell Opus 5 when to stop exploring. Name the directories it can edit, cap subagent delegation, and ask for concise progress updates only at meaningful state changes. Anthropic explicitly recommends calibrating verbosity and limiting delegation when a task does not need a broad agent tree.

A useful boundary block is:

Do not change files outside the listed paths.
Use at most two subagents, only for independent evidence gathering.
Do not add adjacent improvements.
Update me after reproduction, implementation, and verification.
If the acceptance command cannot run, stop and report the blocker.

Which failures should you replay first?

Replay failures that exposed a gap between the model’s story and the system’s state. My historical harness data showed that Fable 5 tested after edits more often than Opus 4.8 in the first cohort, but a later July audit showed the gap had narrowed. That is exactly why durable guardrails matter more than a model reputation.

Prior failure	Deterministic replay	Passing evidence
A tool echoed a parameter, so the agent treated it as saved state	Write a value, close the process, read it through a fresh client	Fresh read matches the expected value
The agent said a file was created, but no artifact existed	Require an exact output path and checksum	File exists, parses, and has the expected schema
A fix widened into unrelated cleanup	Diff against an allowed-path manifest	No changed path falls outside the manifest
An external API failed, so the agent retried blindly	Return a fixed 401, 429, or malformed payload	Result classifies the failure and follows the specified branch
An aggregate looked healthy while rows were wrong	Seed contradictory row-level fixtures	Both aggregate and row assertions pass
A cron job was configured but never executed	Force one real invocation with a unique run ID	Run artifact and exit status are recorded

My original comparison found a higher tests-after-edit rate for Fable 5. The newer July cohort reduced that gap substantially. Those numbers do not justify a permanent label for either model. Behavior can transfer across model generations while targeting judgment remains uneven. Your harness should preserve the lesson after the model changes.

For the system-card evidence behind the fabrication and completion-risk angle, see my analysis of Fable 5 capability and fabrication.

How do you build an Opus 5 regression worker?

Build the worker as two separate stages: the model runner produces an artifact, then a deterministic evaluator grades it. Use the same case contract for local and hosted runs so moving to Railway changes scheduling, not the definition of success.

A compact case file can look like this:

{
  "id": "missing-artifact-001",
  "model": "claude-opus-5",
  "effort": "medium",
  "fixture": "fixtures/missing-artifact",
  "prompt": "Create the requested report and prove it exists.",
  "allowed_paths": ["output/report.json"],
  "verify": ["python", "-m", "pytest", "evals/test_report.py", "-q"]
}

Your worker should:

1. copy the fixture into a clean temporary workspace
2. run the case through your existing Claude agent harness
3. save model output, token use, duration, and changed paths
4. run the verify array without a shell
5. write one immutable result record
6. exit nonzero when the acceptance command fails

Avoid putting secrets, full prompts with customer data, or model transcripts in the result artifact. Store identifiers and aggregate measurements unless you have a reason and permission to retain more.

Here is the result shape I use as the boundary:

{
  "case_id": "missing-artifact-001",
  "model": "claude-opus-5",
  "effort": "medium",
  "accepted": true,
  "verification_exit_code": 0,
  "duration_ms": 48231,
  "input_tokens": 12480,
  "output_tokens": 3190,
  "changed_paths": ["output/report.json"]
}

This design works with a Messages API tool loop, Claude Code automation, or another agent harness. The evaluator does not care which orchestration layer created the artifact.

How do you deploy an Opus 5 agent on Railway?

Deploy the regression worker to Railway only after the same command passes locally. Connect the repository, add the API key as a service variable, use the local runner as the start command, and schedule it in UTC. Railway cron jobs must exit, and a still-running execution causes the next scheduled run to be skipped.

The smallest reliable deployment path is:

1. Push the worker and frozen cases to a private GitHub repository.
2. In Railway, create a project and choose Deploy from GitHub repo.
3. Add ANTHROPIC_API_KEY as a Railway variable. Never commit it.
4. Set the start command to your tested runner, such as python -m harness.replay --suite evals/opus5.
5. Add a UTC cron schedule. 0 7 * * * runs daily at 07:00 UTC.
6. Trigger one real run and inspect its artifact before trusting the schedule.
7. Alert on a nonzero exit and on a missing expected run.

Railway documents a minimum five-minute interval for cron jobs. Daily or per-release evaluation is usually more useful than high-frequency polling because model tests consume tokens and should answer a release decision.

If this is now a recurring or shared workflow, use the

sponsored Railway link paid to review the current service and cron options.

Is Claude Opus 5 worth it?

Claude Opus 5 is worth testing when a failed coding or agent run costs more than the model upgrade. It is not automatically worth using for every request. Make the decision from accepted-task economics, not raw benchmark rank or a single impressive transcript.

Workload	Starting choice	Why
Difficult multi-file implementation	Opus 5 at a measured effort level	Strong capability with lower price than Fable 5
Highest-complexity, long-running task	Compare Opus 5 with Fable 5	Anthropic still positions Fable 5 for the hardest work
Simple edit, extraction, or classification	A smaller model	Opus 5 cost is unlikely to change the outcome
Unfamiliar production workflow	Opus 5 plus strict verification	Capability helps, but the evidence gate controls release
Repeated regression suite	Cheapest model and effort that meet the acceptance target	Cost per accepted task is the relevant metric

Do not infer trading returns, revenue, or production safety from Anthropic’s benchmarks. A model can reduce implementation failure while the product, strategy, or deployment still fails for unrelated reasons.

What should you do today?

Start by selecting ten failures you would be annoyed to pay for twice. Freeze their inputs, define a deterministic acceptance command, and run Opus 5 at two effort levels. Record accepted-task rate, cost per accepted task, rework, and artifact evidence.

If the suite will run once, keep it local. If it becomes a daily, weekly, or release-gated system, put the exact same command on hosted infrastructure:

Your result should show which failures Opus 5 retires, which ones survive, and whether an accepted result costs less than the way you work today.

For the broader operating workflow around Claude Code, continue with the complete Claude Code guide. The model will change again. A failure ledger and independent proof survive the release cycle.