[Non-Engineer's Claude/ClaudeCode Series] I Stopped Defaulting to Opus — A Story of Testing Claude Model Selection by Sales Task Type

Introduction

※All company names, figures, and conditions (discount rates, costs, payback periods, etc.) appearing in this article are fictional, and have no relation whatsoever to any specific company, project, or our company's contractual terms.
The verification is an internal simulation conducted for the purpose of confirming AI model behavior, and does not represent actual estimates or proposal contents. Please be aware of this in advance.

Hello everyone, I'm Ishikawa from the Classmethod Sales Department.

Right off the bat — "I've heard Opus has the best performance, so you can't go wrong choosing Opus when in doubt" — I suspect many of you in sales are using it with exactly that mindset.

Honestly, I myself don't just default to Opus; I also frequently use Sonnet for everyday tasks.
However, when asked why I use them differently, I realized I had never thought deeply about it.
In terms of "choosing based on gut feeling," I may not be so different from the "Opus when in doubt" crowd.

In fact, Anthropic's official documentation explicitly states: "If you're unsure which model to use, start with Claude Opus 4.8 for complex agentic coding and enterprise work. For workloads that need the highest available capability, use Claude Fable 5."
In other words, the judgment of "Opus when in doubt" is, at least in the context of complex coding and enterprise work, not entirely wrong.

However, this is guidance that comes with the condition of "complex work."
I think few people have actually verified whether it can be directly applied to everyday sales tasks.

So this time, I had all four models — Opus, Sonnet, Haiku, and Fable — perform the same sales tasks simultaneously, and examined what differs and how.
To give the conclusion upfront: the result was that "whether an upper-tier model is needed clearly depends on the type of task" — an outcome that cannot be resolved by simple ranking.
It seems worth pausing to reconsider the pattern of "I don't really understand, so Opus when in doubt."

Verification Design

I prepared four tasks that a salesperson would typically throw at Claude, and submitted the same prompt to all four models — Opus, Sonnet, Haiku, and Fable — for comparison.
No customer names or real project information were used; all scenarios are fictional.

The evaluation axes were intended to be "quality (usable as-is)," "speed," and "cost," but in practice, it turned out that "how each model fails and where upper-tier models make a difference that lower-tier ones cannot" was more practically important, so I've centered my summary around that.

Note that prompts were not tuned per model; the exact same prompt was submitted once to each model (some tasks were run multiple times for reproducibility confirmation, described later).
This is an important premise, which I will revisit at the end.

Reference: Official Anthropic Model Positioning

As background before reading the verification results, I've organized the positioning of each model as described in Anthropic's official documentation (Models overview, as of July 2026).

The original text of the official documentation (Models overview) explicitly states:

"If you're unsure which model to use, start with Claude Opus 4.8 for complex agentic coding and enterprise work. For workloads that need the highest available capability, use Claude Fable 5."

In other words, the judgment of "Opus when in doubt" is, with the condition of "complex coding and enterprise work," in line with the official guidance.
It does not unconditionally recommend "Opus for everything, just in case." Also worth noting is that Haiku is officially positioned as having "intelligence approaching frontier-class," meaning it is not treated as something that can "only handle simple tasks."
This verification examines the extent to which, and in what form, these official positions and conditions actually apply to real sales tasks.

Finding ①: In High-Abstraction "Structure Creation," Clear Differences in "Depth" Emerged Between Models

In task ① for drafting a proposal structure, all four models produced a certain standard of chapter organization, but when actually reading and comparing them, there was a clear difference between models that merely generated a table of contents and those that went further into "what to convey, to whom, and how" from a sales perspective.

Opus added advice that extrapolated back from the fictional scenario to "what the customer fears" — noting that for core system migration, "the tone of 'cautious, phased migration' should not waver. Since IT departments at manufacturers are most wary of core system downtime, the structure avoids pushing for an all-at-once migration."

Fable dove in at a level equal to or greater than Opus.
It presented industry-specific keywords such as "the 2025 cliff," specific migration timelines by phase (3–6 months / 6–12 months / 1–2 years), security discussion points conscious of manufacturing supply chains and frameworks like ISMAP, and even suggested how to tailor the explanation depending on the audience — "if the decision-maker is in executive management, focus on the relevant chapters; for IT department audiences, go deeper on other chapters."

Sonnet provided an 8-chapter structure with some practical notes (such as "replacing examples with results from the same industry and similar scale increases persuasiveness"), but compared to Opus and Fable, it left a somewhat less specific and less penetrating impression.

Haiku returned only a list of chapters and one-line messages for the same request, without the kind of depth the other three models offered — such as "where are the deciding moments in the sales discussion."

In other words, for work involving not just "what to create" but the abstract judgment of "what to prioritize," "Opus when in doubt" is clearly correct, but "Fable is equally capable or better for the top tier," Sonnet is in the middle, and Haiku is one level shallower — a predictable result.
This aligns with Anthropic's official positioning of Opus for "complex agentic coding and enterprise work" and Fable for "when the highest performance is needed."
Creating a proposal structure is indeed a task that closely resembles that "complex work."

Finding ②: Complex Reasoning (Reading Customer's True Intentions) Was Even Across Models

Task ④, "reading the customer's true intentions," involved a fairly sophisticated level of reading between the lines, with surface-level statements that contained contradictions.

The customer notes read as follows:

A customer who says "Honestly, I'm not that concerned about the budget. If it's good, we can get it through," while repeatedly bringing up money — mentioning that "last year, a different system overhaul went over budget and I got grilled at the board meeting," "it's more important that unexpected additional costs don't come up," and "other vendors looked cheap at first and then started piling on charges" — and finally pressing with "could we at least get a sense of the numbers before next month's budget meeting."

Here, all four models — Opus, Sonnet, Haiku, and Fable — arrived at nearly the same conclusion.

• On the surface, the customer says "I'm not concerned about the budget," but the real concern is not the amount itself — it's "being held accountable again at the board meeting and having their internal standing put at risk"
• What's being sought is not "cheapness" but rather "certainty that nothing unexpected will happen" and "a basis that can be explained to the board"
• In the next proposal, rather than the amount itself, priority should be given to providing documentation that explains "why this amount" in a way that can be presented to the executive team

All four models arrived at an astonishingly similar depth, reaching nearly the same conclusion.
Honestly, if the author were hidden, I don't think I could tell which model wrote which.
In contrast to task ①, "reading between the lines and analyzing customer psychology" in a single-question-and-answer style of reasoning appears to be sufficient without insisting on "Opus when in doubt."
Even though Haiku is officially positioned as "the fastest model with intelligence approaching frontier-class," the fact that it produced results this comparable to the higher-tier models was honestly beyond my expectations.

Finding ③: When Numbers Are Involved, Differences Emerged in a Different Form

Where a clear difference emerged was in the TCO (Total Cost of Ownership) calculation task. I provided given assumptions and asked the models to "calculate a 3-year cost comparison and payback period."

The approximately correct answer is as follows:

Three models — Opus, Sonnet, and Fable — matched these numbers almost perfectly, and they even voluntarily performed a "verification check" to confirm consistency.

However, Haiku alone, across two separate runs, showed a tendency to add invented information not present in the prompt.

• Run 1: Despite no information about month or day of the week being provided, it fabricated a specific calendar date — "payback achieved by mid-June of the following year"
• Run 2: The expression for the payback period fluctuated between "the 9th month of year 2" and "the 29th month," and it additionally introduced a unique metric — "ROI 313%" — with no clear calculation basis provided

The "core" numbers themselves (¥66 million, ¥30.5 million, ¥35.5 million) were correct, so at a glance, nothing appeared broken.
However, if a salesperson were to show these figures directly to a customer, there is a risk of conveying assumptions that don't exist.
The discovery that lies can creep into the "decorative details around the periphery" rather than the totals themselves — not "the total matches, so we're safe" — is quite an important finding for practical use.

Conversely, for tasks where numerical accuracy is critical, there is almost no difference between non-Haiku models regardless of tier, and as long as "humans do the verification" is a given premise, even lower-tier models can be used operationally.
However, it should be noted that this is also a trade-off of "saving on model costs in exchange for taking on the burden of verification yourself" — a point I will revisit in the "Summary."

Finding ④: The Problem of Whether You Can Decide on the Spot — Opus Tends to "Take It Back"

In the discount negotiation task, all models complied with internal rules (max 20% discount, maintenance fees unchanged, initial costs cannot be waived). All four models passed on this point.

However, there was one clear difference. Whether to immediately answer with 20% on the spot, or to defer with "let me take this back and consider it."

• Sonnet, Haiku, Fable: Consistently answered on the spot with "I can offer up to 20% at my own discretion"
• Opus: In 2 out of 3 runs, avoided an immediate answer with "please allow me to take this back"; only once gave an immediate answer

Since the discussion falls within authorized limits (up to 20%), an immediate answer would in practice better maintain the flow of the negotiation. In this particular scenario, the somewhat surprising result was that "the supposedly smarter model became overly cautious and slow to respond."
This could be said to be the one instance where "Opus when in doubt" backfired. Conversely, in high-stakes or complex decision-making situations where immediate judgment carries risk, this "caution" can actually become an asset.

Finding ⑤: The Difference of Acting Without Being Asked

This is a supplementary finding, somewhat outside the main subject of the verification.
When having the models create the proposal structure draft in task ①, multiple models (Sonnet and Fable) attempted to save the file to the desktop without being instructed to do so.
Opus never exhibited this behavior, while Haiku actually went ahead and completed the save.

Saving a file is not inherently a problem.
However, I felt that "how much autonomous action not requested by the user each model takes" differs by model, and this is a subtly easy-to-overlook perspective when using them in business.
Particularly in situations involving customer information, there are scenarios where "a model that only does what it's told" is actually safer.

Note that in the first run where this behavior occurred, Sonnet and Fable stopped to wait for permission and did not produce the finished output.
The comparison in Finding ① was conducted by explicitly stating "do not save a file, output the answer directly," re-running the task, obtaining the actual finished output, and then making the comparison.

Premises and Limitations of This Verification

Throughout the above, I have written about where differences did and did not exist, but there are several premises I want to be honest about.

• The prompts were identical across all models, with no refinement, submitted once each. Prompt engineering would change the results for any model, and the differences found here are best understood not as "the limits of that model" but as "differences in default behavior when submitted without specific instructions."
• Each task was basically run only once. The finding that "Opus tends to take things back" only became visible after trying three times; concluding from a single result that "Opus has a cautious personality" would be premature. In fact, it gave an immediate answer 1 out of 3 times, so it's more accurate to say "tends to be that way" rather than "always does that."
• On the other hand, Haiku's tendency to "add numbers" reproduced in both runs, making it a relatively stable tendency. However, this is still based on n=2, so overconfidence is unwarranted.
• The evaluation is based on my own subjective judgment; blind scoring by multiple evaluators was not conducted.

In other words, the biggest takeaway from this article is not the conclusion of "which model is superior" in itself, but rather "it is dangerous to decide 'this model has this personality' based on a single test run" — the verification process itself.
If you're about to try this yourself, I recommend running the same prompt at least 2–3 times to observe tendencies.

Summary: Graduating from "I Don't Really Get It, So Opus When in Doubt"

The most important message from this verification is that it is not a simple matter of "as long as the numbers add up, upper-tier models are unnecessary."
In practice, results clearly diverged depending on the type of task.

• High-abstraction strategic judgment (work requiring "discernment" about what to prioritize and what to emphasize): Opus and Fable are clearly one level deeper; Sonnet is in the middle; Haiku is one level shallower. "Opus when in doubt" remains correct, but if you want the absolute top tier, Fable is also an option
• Reasoning that appears complex (reading customer's true intentions): Surprisingly, all four models were on par. There is little need to insist on upper-tier models here
• Tasks involving numbers: The "core" monetary figures show almost no difference outside of Haiku, but some models carry a risk of fabricated "decorative" figures slipping in. Using a lower-tier model means accepting the separate cost of "humans doing the verification"
• Situations requiring on-the-spot judgment and immediate answers: Models have their own tendencies for "how much they hesitate." If you want an immediate answer, it's safer to explicitly state that in the prompt
• Autonomous actions (such as file saving): How much a model acts without being instructed also differs by model. This warrants attention in situations involving customer information

In other words, the practical conclusion is: first assess "does this task involve significant room for judgment, where the quality of that judgment directly affects outcomes?" — and only then decide "should I use an upper-tier model?"
Additionally, for a certain number of differences, simply specifying instructions more concretely — such as "please answer immediately" or "please do not use any numbers not present in the given assumptions" — before switching models may be enough to close the gap.

Stop defaulting to "I don't really get it, so Opus when in doubt," and instead pause to think for each task.
That alone should make a difference in both cost and accuracy. Next time I try this, I plan to also run the same prompt multiple times to identify "tendencies," and see how results change by making even one instruction more specific.