Claude Model Tier Selection Framework

Capability Boundaries and Cost Calculation

Claude currently has four main model tiers: Haiku, Sonnet, Opus, and Fable. The core question for tier selection is not "which model is strongest" but "does the current task's complexity actually require the reasoning depth of a higher tier?" There are two directions for getting it wrong: using flagship models on simple tasks and wasting cost, or using lightweight models on complex tasks and producing insufficient output quality.

In enterprise AI systems, model tier selection is closely tied to multi-model routing architecture — routing logic design directly determines the cost-quality balance across the system. For detailed API cost calculation, see the 2026 API pricing comparison across major providers.

Capability Positioning by Tier

Haiku (lightweight tier): Fastest response, lowest cost. Suitable for structurally clear tasks with programmatically verifiable output: text classification, entity extraction, format conversion, keyword identification, simple summarisation. Not suitable for: tasks requiring multi-step logical reasoning, boundary judgements, or long document analysis — assigning these to Haiku typically trades quality for the cost saving.

Sonnet (balanced tier): The best cost-capability balance point, suitable for most daily professional tasks: drafting, research synthesis, code generation, multi-step analysis, initial document review. For most enterprise users, Sonnet is the sensible default; flagship models should be reserved for scenarios where Sonnet's capability genuinely falls short.

Opus (high-capability tier): Long context understanding (up to 1M tokens), complex multi-step reasoning, ambiguous tasks requiring nuanced judgement. Suitable for: complex legal document review, technical architecture evaluation, research tasks requiring integration of large amounts of information with specific judgement calls. Cost per million tokens is approximately 5x Haiku; should only be invoked when task complexity genuinely requires it.

Fable (frontier reasoning tier): Integrates deep reasoning capability for the most demanding tasks: frontier coding problems, complex research report synthesis, analyses requiring long-chain logic with no room for error. Highest cost; reserved for scenarios where Opus output remains insufficient.

Cost Estimates (HKD)

At an exchange rate of approximately 7.8:

For a typical conversation (1,000 input tokens, 500 output tokens): Haiku costs approximately HK$0.03, Opus approximately HK$0.12. The per-conversation difference is negligible, but at the scale of tens to hundreds of thousands of requests per month, tier selection directly determines the order of magnitude of monthly total cost.

Tier Selection Decision Framework

Task output is programmatically verifiable (yes/no answer, fixed-format extraction) → Haiku first.

Task requires drafting, analysis, or explanation with human review of output → Sonnet is usually sufficient.

Task involves long documents (over 100,000 words), complex multi-constraint judgements, or Sonnet output quality is clearly inadequate → consider Opus.

Task is a boundary problem where all Opus outputs remain unsatisfactory → evaluate Fable.

Multi-Model Mixing Is the Superior Architecture

In the same system, different functions should be routed to different model tiers rather than using a single model uniformly. Auxiliary tasks such as user query classification and background information extraction go to Haiku; core conversation goes to Sonnet or Opus. This tiered architecture achieves the optimal cost-quality balance, outperforming the alternative of downgrading the main conversation to a lightweight model to offset auxiliary task costs.

Summary

Model tier selection is one of the core cost management decisions in AI applications. Practical guidance: use Sonnet as the default; downgrade to Haiku when tasks are structurally simple with verifiable output; upgrade to Opus/Fable when Sonnet output quality genuinely fails to meet requirements. Regularly review model allocation across different functions and adjust routing rules as the task complexity distribution changes.