Token Cost & Latency

An LLM API bills you per token and answers in two phases — and both the bill and the wait scale with how many tokens move through the model. The slider above shows it: more input or output pushes cost up; a bigger prompt pushes the first token further out.

Where you meet it

Your monthly API invoice — split into input tokens and output tokens.
A chat UI that feels slow to start, then streams smoothly.
Choosing a model: a bigger one is smarter but costs more per token and runs slower.
Long conversations that get pricier with every turn as the history grows.

What it does

The provider counts the tokens in your request and the tokens the model generates, then charges each at a published rate per million tokens. Input and output are billed separately — output is usually several times more expensive. Latency is a separate concern: you wait once for the model to read the prompt, then watch the answer arrive token by token.

Output is the expensive, slow half — and a growing chat history makes you pay for the whole conversation on every single turn.

How it works

A token is a chunk of text — roughly 4 characters or 0.75 words of English, though it varies by tokenizer and language. Cost is a straight weighted sum:

cost = (input_tokens  / 1e6) * price_in
     + (output_tokens / 1e6) * price_out
# price_out is typically 4-6x price_in

Latency has two parts, matching how inference runs:

Prefill processes the whole prompt at once to produce the first token. This is TTFT (time-to-first-token), and it scales with input length — a longer prompt means a longer wait before anything appears.
Decode then generates the rest one token at a time, at the model's tokens-per-second. This scales with output length.

total_time = TTFT + output_tokens / tokens_per_second
#            prefill   decode

So a huge prompt with a short answer is dominated by prefill; a short prompt with a long answer is dominated by decode.

Watch out

Long context costs twice. A growing chat history or a big document inflates input tokens and stretches TTFT — every turn re-sends the accumulated history.
Cap the output. Output is the pricey, slow half. A max_tokens limit and a "be concise" instruction control both bill and decode time.
Cache the stable prefix. Prompt caching re-reads a repeated system prompt or document at a fraction of the input price (a cache hit is ~0.1x base input on the Claude API) and improves TTFT for long prefixes.
Streaming helps perceived latency, not total time. The user sees text sooner, but end-to-end time is the same. For non-urgent bulk work, a Batch API trades latency for a discount.

Go deeper

Eine LLM-API rechnet pro Token ab und antwortet in zwei Phasen — und sowohl die Rechnung als auch die Wartezeit skalieren mit der Anzahl der Tokens, die durchs Modell laufen. Der Slider oben zeigt es: mehr Input oder Output treibt die Kosten; ein größerer Prompt schiebt das erste Token nach hinten.

Wo es vorkommt

Deine monatliche API-Rechnung — getrennt nach Input- und Output-Tokens.
Ein Chat-UI, das träge startet und dann flüssig streamt.
Die Modellwahl: ein größeres ist schlauer, kostet aber mehr pro Token und läuft langsamer.
Lange Gespräche, die mit jedem Turn teurer werden, weil die History wächst.

Was es tut

Der Anbieter zählt die Tokens in deiner Anfrage und die vom Modell erzeugten Tokens und berechnet beide zu einem veröffentlichten Preis pro Million Tokens. Input und Output werden getrennt abgerechnet — Output ist meist um ein Mehrfaches teurer. Latenz ist eine eigene Frage: du wartest einmal, bis das Modell den Prompt gelesen hat, und siehst dann die Antwort Token für Token eintreffen.

Output ist die teure, langsame Hälfte — und eine wachsende Chat-History lässt dich in jedem Turn das ganze Gespräch erneut bezahlen.

Wie es funktioniert

Ein Token ist ein Textstück — grob 4 Zeichen oder 0,75 englische Wörter, abhängig von Tokenizer und Sprache. Die Kosten sind eine einfache gewichtete Summe:

cost = (input_tokens  / 1e6) * price_in
     + (output_tokens / 1e6) * price_out
# price_out ist typisch das 4- bis 6-Fache von price_in

Die Latenz hat zwei Teile, passend dazu, wie die Inferenz abläuft:

Prefill verarbeitet den ganzen Prompt auf einmal, um das erste Token zu erzeugen. Das ist TTFT (Time-to-First-Token) und skaliert mit der Input-Länge — ein längerer Prompt heißt längere Wartezeit, bevor überhaupt etwas erscheint.
Decode erzeugt dann den Rest Token für Token, mit den Tokens pro Sekunde des Modells. Das skaliert mit der Output-Länge.

total_time = TTFT + output_tokens / tokens_per_second
#            Prefill   Decode

Ein riesiger Prompt mit kurzer Antwort wird also vom Prefill dominiert; ein kurzer Prompt mit langer Antwort vom Decode.

Worauf achten

Langer Kontext kostet doppelt. Eine wachsende Chat-History oder ein großes Dokument bläht die Input-Tokens auf und verlängert TTFT — jeder Turn schickt die gesammelte History erneut mit.
Output begrenzen. Output ist die teure, langsame Hälfte. Ein max_tokens-Limit und eine "fasse dich kurz"-Anweisung steuern Rechnung und Decode-Zeit zugleich.
Den stabilen Prefix cachen. Prompt-Caching liest einen wiederkehrenden System-Prompt oder ein Dokument zu einem Bruchteil des Input-Preises erneut (ein Cache-Hit kostet auf der Claude-API ~0,1× Basis-Input) und verbessert TTFT bei langen Prefixen.
Streaming verbessert die gefühlte Latenz, nicht die Gesamtzeit. Der Nutzer sieht Text früher, aber die End-to-End-Zeit bleibt gleich. Für nicht-dringende Massen-Jobs tauscht eine Batch-API Latenz gegen einen Rabatt.