The cheapest model for a specific task

A model's name tells you nothing about its price. glm-5.3-flash isn't necessarily cheaper than claude-sonnet-5 for your specific task — it depends on how many tokens go in and out, and on the current catalog price, which can change. Here's how to check that with facts instead of guessing.

Check the price in the catalog, not from memory

Current price and limits for every model, in one call, no key needed:

curl https://api.zukko.pro/v1/models/info

That's the only source worth trusting: catalog prices change, an article or someone's chat message doesn't update itself. Before you wire a "cheap" model into a production pipeline, check here, not old notes.

Count tokens before sending, not after

/v1/messages/count_tokens counts tokens for free, without hitting the model:

curl https://api.zukko.pro/v1/messages/count_tokens \
  -H "Authorization: Bearer fetch_your_key" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-sonnet-5",
    "messages": [{"role": "user", "content": "Classify this ticket: ..."}]
  }'

A short classification into a handful of categories doesn't need the flagship model — run the same prompt template through a few candidates, count input tokens once, then compare by actual spend rather than the feeling that "this one is probably pricier."

Measure real request cost, not assumed cost

Every regular (non-streaming) response carries an X-Zukko-Cost-Micros header — the exact cost of that specific request in micro-dollars (1,000,000 = $1); responses with stream: true don't have it. Log it on every call, and within a day or two you'll have an honest table of "model → task → average cost" instead of a guess.

For history over a period, /v1/usage returns a list of charges across the whole account (all keys together) with cursor pagination:

curl "https://api.zukko.pro/v1/usage?limit=100" \
  -H "Authorization: Bearer fetch_your_key"

Walk the cursor and group manually by model — that shows which model is actually eating your budget on a given kind of task.

Caching removes some cost entirely

If the same request from the same user repeats — a templated support question, say — turn on the cache with the X-Zukko-Cache: true header (temperature: 0 also enables the cache, but only on models that accept that parameter; Claude models — claude-sonnet-5, claude-opus-5-5 — may reject a temperature other than 1 with a 400, so don't pass it to them). A repeat request with a fully identical body comes back instantly and free, with X-Zukko-Cache: hit in the response; "almost identical" requests don't hit the cache, and cache hits aren't written to /v1/usage. For chat, the cache lives up to 7 days. On tasks with repeating inputs, this often beats chasing a cheaper model.

Don't confuse "cheaper" with "worse"

The difference between an expensive and a cheap model is mostly per-token price rather than base capability, but two things are worth checking: Claude and GPT have a 1,000,000-token context and vision, while glm-5.3 and glm-5.3-flash have 128K and no vision. If the task is text-only and fits in 128K — jobs like "pull a date out of this text" or "check whether this customer message is a complaint or a question" — go ahead and try the "flash"-style names in the lineup — glm-5.3-flash ($0.04 per 1M input and output tokens), for instance — and compare against your own data.

Cap test spend with the key itself

Before running a comparison across ten models, set a daily limit on the test API key in the dashboard, on the key's own page. That way an experiment in "which model is cheaper" doesn't turn into a surprise bill: even if one candidate turns out unexpectedly hungry, the limit stops the spend before you notice the problem yourself.

Idempotency for repeated runs

If you're comparing models with a script that occasionally crashes and restarts, add an Idempotency-Key header with a unique value per real request (not per retry). A repeat with the same key within 24 hours returns the same answer without charging again — useful when your test runner isn't idempotent on its own.

Splitting the task into stages instead of one model for everything

Often the cheaper approach isn't finding one model for the whole pipeline, but splitting it into stages: a cheap model does the first pass or filtering (say, screening out most of the tickets that clearly aren't complaints), and the expensive model only looks at what passed that filter. The total cost of processing a thousand items this way is usually lower than running everything through the flagship, and safer than running everything through the cheapest model with no filtering at all.

Block expensive models on the key explicitly

If a service is only supposed to touch cheap models, don't rely on the code never accidentally calling something else — set an allowed-model list right on the key in the dashboard. Then calling a model outside that list returns 403 model_not_allowed_for_key before the request ever reaches billing, instead of quietly charging for an expensive identifier that got hardcoded into a debug branch by accident.

The actual sequence

Check price at /v1/models/info, count tokens with /v1/messages/count_tokens, measure actual spend via X-Zukko-Cost-Micros and /v1/usage, turn on caching where input repeats, and cap the test key with a limit. That takes about twenty minutes and gives you a precise answer for your specific task, instead of the generic advice to "pick a cheaper model."