How to Audit Prompts and Harnesses Before Switching to Claude Opus 5

The provided material introduces Claude Opus 5 as a model designed for everyday enterprise and agent tasks, arguing that existing prompts and harnesses must be redesigned for the new generation of Claude. However, the release dates, pricing, performance, and partner statements concerning Claude Opus 5, Fable 5, and Sonnet 5 mentioned in the material have not been independently verified based solely on the information provided in this article. In particular, whether Fable is an official Anthropic model name should first be checked against the official model list.

Accordingly, rather than repeating this release information as established fact, this document distinguishes between items that must be confirmed through official documentation and verification procedures that can be applied to an actual model migration.

Release Information to Verify First

Before deploying a new model through the API, Claude app, or Claude Code, compare the following items against Anthropic’s official documentation and the model selection screen of the service you use.

If a model name or price is absent from official documentation, it must not be used for API configuration or budget calculations. If you use a cloud provider or reseller service, its model IDs, pricing, and availability dates may also differ from those of the direct Anthropic API.

Decision Criteria That Must Change During Model Migration

1. Measure Efficiency per Task Rather Than Peak Performance

Processing every request with the most expensive model can quickly increase costs when an agent repeatedly invokes multiple tools and subagents. Models should be selected by considering the following metrics together, rather than by name or tier.

• Success rate: Percentage of tasks that meet requirements without human correction
• Total cost: Cost including retries, tool calls, and subagent calls, not just the initial request
• Completion time: Time including waiting and human review and correction
• Cost of failure: Impact caused by failures such as security defects, incorrect deployments, or omitted analysis
• Consistency: Degree to which results vary when the same type of task is repeated

Cost per task should not be judged solely by token pricing. Conceptually, it can be calculated as follows.

Total cost per task = primary model cost + subagent cost + tool cost + retry cost + human review cost

2. Separate Public Benchmarks From Internal Evaluations

Public benchmarks are a starting point for comparing models’ general characteristics, but they do not guarantee success with a specific codebase, document format, or set of business rules. Organizations should create internal evaluation sets from anonymized real-world tasks.

A good evaluation set includes the following cases.

• Representative tasks that should be completed successfully
• Edge cases that models frequently get wrong
• Tasks with ambiguous requirements that require follow-up questions
• Tasks that require tool calls or verification against external sources
• High-risk tasks that require execution to stop or human approval
• Tasks that require state to be saved and recovered during long-running execution

For valid comparisons, the same inputs, tools, time limits, and success criteria must be applied to each model. It is safer to record success rates and cost distributions across multiple repetitions than to rely on one or two impressive results.

3. Evaluate the Model and Harness as a Single System

A harness means the execution environment surrounding a model. It includes the system prompt, project instructions, retrieval, memory, tools, Skills, subagents, permission management, and validation and retry logic.

The same model can produce different results depending on the harness. For example, if the model writes and runs tests itself while the harness also enforces the same validation, the work may be duplicated. Conversely, it is risky to leave stages requiring deterministic controls, such as deployment approval or security checks, to the model’s autonomous judgment.

The core principle is to distinguish between reasoning the model performs well and controls the system must guarantee.

Six Things to Review in Prompts and Harnesses

1. Experimentally Remove Redundant Validation and Rechecking Instructions

The right answer is not to delete every sentence such as You must check your work again after completion. First, trace whether the validation the new model performs spontaneously overlaps with the harness’s validation stages.

• If the model’s self-review merely repeats itself without improving quality, shorten the prompt.
• Keep checks that can be automated, such as tests, schema validation, and static analysis, in the harness.
• Do not replace approval for high-risk tasks such as payments, deployments, or data deletion with the model’s self-validation.

2. Define Conditions and Upper Limits for subagent Calls

subagents are useful for parallel research or separating specialized domains, but delegating even small tasks increases cost and latency. Policies such as the following can be specified.

• Use subagents only for tasks that can be divided independently.
• Limit how many may run concurrently within a single request.
• Give each subagent a clear deliverable and termination condition.
• Prevent multiple agents from redundantly searching the same material.
• Require human approval when the estimated cost or time exceeds a threshold.

3. Replace Detailed Prohibitions With Decision Criteria

Long lists of prohibitions may conflict with one another or fail to address new situations. In low-risk areas such as style, the model can be allowed to read the surrounding context and make a judgment.

• Prescriptive: Never write a multi-paragraph docstring.
• Judgment-based: Follow the existing code’s comment density, docstring format, naming, and idioms.

However, rules with a high cost of violation, such as those concerning personal data handling, security, or legal obligations, should remain as explicit constraints backed by programmatic checks.

4. Specify Response Length and Output Format Directly

The resources used for reasoning and the length of the answer shown to the user are not the same thing. Even if the client provides an effort option or a similar reasoning-intensity setting, specify separate output conditions when a short answer is required.

Examples include the following.

• State the conclusion first and summarize the rationale in at most three points.
• Keep the final answer within 500 characters.
• Return only a valid JSON object without explanation.
• Report only the changed files, key reasons, and remaining risks.

5. Recalibrate Reasoning Intensity Using Actual Tasks

Do not apply the reasoning-intensity or effort defaults used with a previous model to a new model unchanged. Measure the cost curve by starting with a low setting and increasing it only when quality is insufficient.

The exact option names and supported scope may vary by API version and product, so official documentation must be checked.

6. Divide Context by Role and Disclose It Progressively

Putting every instruction into a single system prompt or CLAUDE.md may cause irrelevant information to be included with every request. The following layered structure is practical.

1. System and product instructions: Rules that are always required, such as roles, safety boundaries, and output contracts
2. Lightweight project instructions: Build commands, directory structure, and common workflows
3. Skills loaded when needed: Conditional procedures for deployment, database changes, specific frameworks, and similar tasks
4. Technical references: API schemas, code examples, design documents, and testable specifications

This can be called progressive disclosure. Allow the model to retrieve or load the material needed for the current stage, but record which material it used to ensure reproducibility and auditability.

Recommended Migration Procedure

Step 1: Lock Down the Current State

Save the existing model’s prompts, tool versions, success rate, token usage, latency, and failure cases. Without a baseline, it is difficult to determine whether the new model has actually improved.

Step 2: Verify Model Information and Permissions

Confirm the official model ID, pricing, context limit, tool support, and data retention policy. Restrict write, delete, and deployment permissions in the test environment.

Step 3: Test With the Existing Harness Unchanged

Do not change everything at once initially. Replacing only the model and comparing it with the baseline makes it possible to isolate the impact of the model change.

Step 4: Remove Redundant Instructions One at a Time

Remove one category at a time, such as validation instructions, verbose style rules, unnecessary examples, or references that are always injected. Measure quality and cost again after each change.

Step 5: Create a Routing Policy

Select models according to task difficulty, risk, expected context, and time limits. The model-specific roles proposed in the provided material should be tested as hypotheses after the official names and performance have been confirmed; they should not be adopted unchanged as operational policy.

Step 6: Deploy to Limited Traffic First

Apply the new model first to a subset of users or non-risky tasks. Observe the failure rate, retries, number of subagents, tool errors, and human correction time before expanding deployment.

Operational Checklist

• The official model name and API model ID have been confirmed.
• The actual applicable rates for input, output, cache, batch, and other usage have been confirmed.
• An internal evaluation set composed of actual work exists.
• The model’s and harness’s validation stages do not overlap.
• Criteria for subagent calls, concurrent execution limits, and budget caps are defined.
• Response length and output schema are specified.
• Quality, cost, and latency have been compared across reasoning-intensity settings.
• Deterministic checks and human approval remain in place for high-risk tasks.
• Context is separated into persistent instructions, Skills, and references.
• The previous model and settings are ready for rollback.

Conclusion

The key to migrating to a new model is not to shorten prompts unconditionally or expand autonomy without limits. The key is to verify official product information first and then redivide the roles of the model and harness through evaluations based on actual work.

The figures and names related to Claude Opus 5 in the provided material should be treated as provisional information until official evidence is confirmed. However, removing redundant validation, limiting subagents, defining clear output contracts, progressively disclosing context, and routing based on internal evaluations are migration principles that can be applied regardless of model generation.