Choosing a model

Doing the cost math

You priced a single call in the tokens lesson. Here's the same idea as one line. Prices are quoted per million tokens, so you divide by a million at the end:

cost = (input tokens × input price + output tokens × output price) ÷ 1,000,000

In plain words: price what you sent, price what came back, and add the two. Then divide by a million, because each price covers a million tokens.

Here's an example with small numbers. Say you ask Opus 5.5 to tag one product review with a label, such as "positive" or "shipping problem". The review and your instructions come to about 300 tokens. The reply is about 20 tokens.

• Input: 300 × $4 = 1,200.
• Output: 20 × $20 = 400.
• Add them: 1,200 + 400 = 1,600.
• Divide by a million: 1,600 ÷ 1,000,000 = $0.0016.

The middle numbers aren't dollars yet. They turn into dollars at the last step. The answer, $0.0016, is less than a fifth of a cent. The code below does the same sum for three models. Then it multiplies by 50,000 to price a whole batch of reviews.

PRICES = {  # dollars per million tokens: (input, output)
    "claude-opus-5-5": (4.00, 20.00),
    "claude-sonnet-5-5": (2.00, 10.00),
    "claude-haiku-5-5": (0.10, 0.50),
}

def cost(model, input_tokens, output_tokens):
    price_in, price_out = PRICES[model]
    return (input_tokens * price_in + output_tokens * price_out) / 1_000_000

# Tagging one product review: ~300 tokens in, ~20 out
for model in PRICES:
    per_review = cost(model, 300, 20)
    print(f"{model:18} ${per_review:.6f} per review, ${per_review * 50_000:,.2f} for 50,000 reviews")

PRICES is a dictionary. Each model name maps to a pair: the input price, then the output price. The line price_in, price_out = PRICES[model] unpacks that pair into two names. The :.6f shows six decimal places, so tiny costs don't print as zero.

The gap is huge. The 50,000-review job costs $80 on Opus, $40 on Sonnet and $2 on Haiku. The open question is quality. You'd test it with an eval: a set of examples with answers you trust. Evals come later in this phase. If Haiku tags reviews as well as Opus, the choice is easy. If accuracy drops from 95% to 80%, it might not be.

input_tokens = 1_000_000
print(input_tokens * 4 / 1_000_000)

Closed models and open-weight models

Think of the difference between eating at a restaurant and getting the recipe. At the restaurant, you order and the food arrives. You never see the kitchen. With the recipe, you can cook at home and change it to taste. But you buy the ingredients and run the kitchen yourself.

Claude, GPT and Gemini are closed models, like the restaurant. You send requests to the provider's API, and you never see the model itself.

Open-weight models are the recipe. Their makers publish the weights, the huge set of numbers the model learned in training. Examples include Meta's Llama, Mistral's models, Alibaba's Qwen and DeepSeek's models. You can download them and run them on your own hardware. You can also rent a server to run them.

A GPU is a graphics chip. It's the kind of processor large models run on fastest. Fine-tuning means training a model a little more on your own examples.

Open-weight doesn't mean free to run. You stop paying per token. Instead, you pay for servers and the work of keeping them running.

Phase 6 covers running open models yourself. For most product work, an API model is the fastest way to get something working.

How to choose, in practice

1. Start capable. Build the first version on a strong model, such as Opus 5.5. That tells you whether the task can be done at all.
2. Measure. Collect 20 to 50 real examples, along with the outputs you'd accept. This is your eval set.
3. Step down. Run the same prompts on a cheaper model. Compare its results with the strong model's on your eval set.
4. Route. Many apps use more than one model. A cheap model handles the easy, high-volume steps. A strong model handles the hard ones.

Before you step down to a cheaper model, try lowering the strong model's effort setting. It trades some depth of reasoning for speed and cost, and the next lesson covers it. It's often a better trade than switching models.

Watch out: thinking counts as output tokens. Some models work through a problem in writing before they answer, and that working-out is called thinking. A reasoning-heavy request on a big model can produce far more output tokens than the visible answer suggests. The next lesson shows how to control that.

PRICES = {"claude-opus-5-5": (4.00, 20.00), "claude-sonnet-5-5": (2.00, 10.00), "claude-haiku-5-5": (0.10, 0.50)}

def cost(model, input_tokens, output_tokens):
    price_in, price_out = PRICES[model]
    return (input_tokens * price_in + output_tokens * price_out) / 1_000_000

requests_per_month = 1_200 * 30
for model in PRICES:
    monthly = cost(model, 3_200, 250) * requests_per_month
    print(f"{model:18} ${monthly:,.2f} per month")