What you actually pay for

Model cost behaves like a utility meter: predictable once you know what is metered, opaque until then. Prices also move inside a quarter. As of Oct 2026 Google's pricing page lists some rates that roughly double on a stated date, and Anthropic's says a planned rise for one model will not happen. So this lesson teaches ratios and where to look, and quotes no price.

1.The unit is the token, and the meter has more than one rate

Billing is per token, quoted per million tokens, and split into at least two rates. Input is everything you send. Output is everything the model generates. Output costs more because your prompt is read in roughly one pass, while every output token is its own pass. As of Oct 2026 output is five times input on every current Anthropic model, and about five to eight times on the Google text models.

Around those two sit other line items. The names differ by provider; the shape does not.

Three things move the meter without any change to the price list.

• The tokenizer. Anthropic says its models from 4.7 on make about 30% more tokens for the same text (as of Oct 2026). Count with the provider's token-counting endpoint for your model.
• Images. Anthropic counts an image in 28-pixel patches, so a 1000 by 1000 image is about 1,300 tokens, and some models use up to about three times more for the same image (as of Oct 2026).
• The spread inside one family. The dearest and cheapest current Anthropic models differ by up to 100 times on input (as of Oct 2026). That gap is the biggest lever on the page.

A worked example. Read a request in input-equivalents, using the five-times ratio. Say it sends 2,000 input tokens and gets 500 back. The cost is 2,000 + 500 × 5 = 4,500 input-equivalents. Output is a fifth of the tokens and more than half of the cost. The figures are illustrative arithmetic on a dated ratio, not a measurement, so run it with your own counts.

2.The levers, in the order that pays

Lever one: shorter context. You pay for every input token on every turn, so this compounds as nothing else does. Trim the system prompt. Prune tool schemas, since twelve long descriptions are resent on every request. Retrieve passages instead of pasting documents. Summarise or drop old turns. It is usually the biggest and safest saving, because shorter context often improves accuracy too.

Lever two: a smaller model. Most requests in a real app are easy: classify, route, extract a field. Send those to the small model in the same family and keep the expensive one for hard cases. Prove it with a test set per route before you ship.

Lever three: prompt caching. If a long prefix repeats across requests, cache it. The prices, the rules and the traps are in Caching and batch: the two big discounts.

The seatbelt: max_tokens. Cap the output on every call. As of Oct 2026, on models where thinking runs by default (Sonnet 5.5 adapts; Sonnet 4.6 and earlier start with it off), the cap covers thinking and the answer together, so set it with room, or the answer is cut off after the model has spent its allowance reasoning. Thinking and effort, model by model shows how to size it.

Batch. If the work can wait, such as nightly enrichment, a backfill or an eval run, submit it as a batch job. As of Oct 2026 Anthropic says most batches finish within an hour, you can read results once the batch ends or at 24 hours, whichever comes first, and a request still unfinished at 24 hours expires and is not billed. You give up the instant reply and streaming, and take about half off.

When these levers do not apply. Batch is wrong for anything a user is waiting on. A router does not pay below a volume where its test set costs more than it saves. Cutting context does little when the bill is mostly output and thinking, so check the split first.

3.Where the money goes, a failure case, and how to see it

People tune the clever prompt, which is four hundred tokens. The bill is elsewhere.

• Resent conversation history. The most common surprise. Turn thirty resends turns one to twenty-nine, so cost per turn rises through the session.
• Stuffed retrieval. Someone set top_k to 20 to be safe, each chunk is 800 tokens, and every request now carries 16,000 tokens, most of them irrelevant. It costs money and hurts accuracy.
• Retries and agent loops. A call retried three times is billed four times. An agent loop with no hard step cap is an unbounded bill with a friendly interface. Rate limits and reliability covers the retry side.

A failure case: the same price, a bigger bill. Take the request from section 1 and move it to a current model on the same provider. Two things can change at once, and neither shows on the price list.

The effect can run the other way. One preprint (Aug 2026) tracked mean total tokens per request across successive models from a single provider. On one hard maths set the mean fell from about 8,100 to about 4,150. On an instruction-following set, a different pair rose from about 1,400 to about 1,850. It covers one provider and three benchmarks, so the shares are not rates for your app. The lesson is that tokens per task moves with the model, so measure it again after every swap.

A price list tells you what a token costs. Only your own log tells you how many tokens a task takes.

An invoice gives you the total after the month is over. Every provider returns a usage object on every response, so log it and cost becomes a query. Record the feature that made the call, the model, the input, cache and output tokens, why generation stopped, latency and the computed cost. Then group by feature, user and day, and alert on cost per request, not only on the monthly total.

Field names differ by provider, and the adapter should map them. The example uses Anthropic's. Note that input_tokens counts only the text after the last cache breakpoint, so total input is input_tokens plus the cache read and cache creation counts.

import time, logging
from anthropic import Anthropic

client = Anthropic()

MODEL = "claude-sonnet-5-5"  # check the models page; as of Oct 2026

# Per million tokens. Copy from the pricing page for your model on the day, and keep them in config.
RATES = {MODEL: {"in": 0.0, "out": 0.0, "cache_read": 0.0, "cache_write": 0.0}}

def ask(feature: str, prompt: str, model: str = MODEL) -> str:
    start = time.monotonic()
    resp = client.messages.create(
        model=model,
        max_tokens=4000,                   # the seatbelt: thinking and the answer share it
        messages=[{"role": "user", "content": prompt}],
    )
    u, r = resp.usage, RATES[model]
    read = u.cache_read_input_tokens or 0
    wrote = u.cache_creation_input_tokens or 0
    cost = (u.input_tokens * r["in"] + read * r["cache_read"]
            + wrote * r["cache_write"] + u.output_tokens * r["out"]) / 1_000_000
    logging.info(
        "llm feature=%s model=%s in=%d cached=%d out=%d stop=%s cost=%.5f secs=%.2f",
        feature, model, u.input_tokens, read, u.output_tokens,
        resp.stop_reason, cost, time.monotonic() - start,
    )
    return next((b.text for b in resp.content if b.type == "text"), "")

llm feature=%s1 model=%s in=%d cached=%d2 out=%d3 stop=%s4 cost=%.5f secs=%.2f

With the rates left at zero, each call prints one line whose cost reads 0.00000. Fill the rates from the pricing page and it becomes a real number. Expect out to be larger than the words in the answer whenever thinking is on, and stop=max_tokens to mean you should raise the cap. The first time you group that log by feature you will find one costing ten times what you assumed, nearly always a chat history nobody trims or a retrieval step that quietly grew.