Why input and output tokens are priced differently

Every vendor's official price list — Claude Opus 5.5 ($4/$20), GPT-5.6 Sol ($5/$30), GLM 5.3 ($1.4/$4.4 per 1M), any of them — quotes two numbers: a rate per million input tokens and a separate, almost always higher, rate per million output tokens. That gap isn't an arbitrary business decision. It comes directly from how the model works under the hood. On Zukko, the currently enabled models charge the same rate for input and output (for example, claude-opus-5-5 is $0.30/$0.30), but the vendor-side asymmetry is still worth understanding.

Where the asymmetry comes from

When a model processes input text, it does so in a single pass: the whole prompt loads into accelerator memory and gets computed in parallel, all tokens at once. This is called prefill, and it parallelizes well — a GPU can multiply matrices for thousands of tokens almost as fast as for one.

Generating a response works differently. The model is autoregressive: to produce token number 50, it needs token number 49 already in hand, and so on down the chain. Every new token requires a separate pass through all the network's layers. That's a sequential process that can't be sped up by simple parallelization — which is exactly why generating a response is slower and more compute-expensive per token than reading a prompt.

That's where the price gap comes from: model providers are pricing in real GPU time, not picking numbers arbitrarily.

What that means in practice

For chat and conversational use cases, the output price usually matters more — a reply can run long while the user's message is short. If a model tends to produce verbose answers where two sentences would do, that's what drives the bill up fastest.

For agents and RAG pipelines, it's the opposite. Every agent step — reading files, tool output, accumulated conversation history — goes entirely into input tokens, while the generation itself is usually short: a function call, a brief comment, the next step of a plan. With a context running into hundreds of thousands of tokens, input becomes the main cost driver even though its rate is lower.

Vision requests also count as input tokens: an image passed into messages gets broken into tokens alongside the text. It's not a separate line item — it's part of the same input cost, and it applies to models that accept images (Claude and GPT); glm-5.3 and glm-5.3-flash don't accept images.

Image generation runs on entirely different rules: vendors usually price it per generated image, not per token, so comparing it to text rates directly doesn't make sense. Image generation through Zukko is temporarily unavailable.

A quick example: chat versus agent

Take two differently-shaped requests to the same model.

An ordinary chat reply: 40 input tokens — a short user question — and 400 output tokens — a detailed explanation. Here output tokens outnumber input ten to one, and the higher output rate determines almost the entire price of the request.

An agent step that reads a file: 18,000 input tokens — file contents, accumulated history, a system prompt describing tools — and 60 output tokens — a function call with parameters. The ratio flips: input tokens outnumber output roughly 300 to 1, and even the higher output rate barely matters — input volume decides the price, not the rate difference.

You can check this against your own real numbers with the same count_tokens call before sending, and the X-Zukko-Cost-Micros header after the response — comparing actual figures quickly shows which side of the rate dominates your particular workload.

Where to find the current numbers

The catalog changes, and quoting specific rates in an article is a bad idea — they'd go stale. Current figures for every model are available without a key:

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

The response includes the per-million input and per-million output price for each model separately, plus its limits. The plain /v1/models gives you a list of identifiers with no detail — for actual cost math, you want /models/info.

Estimating your own cost before sending

Free token counting works for any model in the catalog:

import requests

resp = requests.post(
    "https://api.zukko.pro/v1/messages/count_tokens",
    headers={
        "Authorization": "Bearer fetch_your_key",
        "anthropic-version": "2023-06-01",
    },
    json={
        "model": "claude-opus-5-5",
        "messages": [{"role": "user", "content": long_context_string}],
    },
)
print(resp.json())

Knowing the input token count ahead of time and the rates from /v1/models/info, you can compute a lower bound on request cost before ever sending it — the only unknown is the output token count, which isn't known in advance but is typically an order of magnitude smaller than input in agent workloads.

The practical takeaway

The price asymmetry isn't a reason to avoid long responses where they're genuinely needed — it's a reason not to conflate two different risks. If you're running a chat bot with long replies, tune max_tokens and add a system prompt that asks the model to be brief. If you're running an agent with a large context, optimize what goes into the input: trim history, don't paste whole files when one fragment is what's needed. Different rates for input and output aren't just a line in a price list — they point directly at where the savings actually are.