Context Window, Tokens und Rechnung: gemessen

Das teuerste Missverständnis in diesem Geschäft ist, dass ein Modell sich an ein Gespräch erinnert.

Tut es nicht, und der Mechanismus aus Kapitel 13 sagt genau warum. Der Zustand eines transformers während der Generierung ist die KV cache: die Keys und Values, die für jeden token in der Sequenz berechnet wurden. Dieser Cache lebt für die Dauer einer Anfrage. Wenn die Anfrage endet, kann der Prozess, der ihn gehalten hat, jemand anderen bedienen, und der Cache ist weg. Auf der anderen Seite gibt es keinen nutzerspezifischen Speicher und keine Session.

Die nächste Anfrage muss also alles mitbringen, was das Modell wissen soll, und das Modell baut diesen Zustand neu auf, indem es einen forward pass über den gesamten prompt ausführt, bevor es auch nur einen neuen token ausgibt. Kapitel 15 nannte den prompt „den gesamten Zustand“. Das ist der physische Grund: Der prompt ist der vollständige Zustand, weil sonst nichts den Call überlebt.

Das context window ist die maximale Länge dieses prompts plus seiner Antwort. Es ist eine Obergrenze dafür, wie viel Zustand du neu aufbauen kannst, kein Behälter, der zwischen Anfragen irgendetwas hält. Es „das Gedächtnis des Modells“ zu nennen, dreht die Kausalität um — du füllst kein Gedächtnis, du bezahlst dafür, eines wiederherzustellen.

Daher kommt die Zweiundzwanzig. Turn $n$ trägt alle $n-1$ vorherigen Turns mit, also ist der gesamte Input über ein Gespräch mit $n$ Turns die Summe einer wachsenden Reihe, und die ist quadratisch:

wobei $s$ der system prompt ist und $h_i$ die History in Turn $i$. Passt man den gemessenen kumulativen Input über die vierzig Turns an $an^2 + bn$ an, ergibt sich $60.22\,n^2 + 432.25\,n$; das sagt 113.645 Tokens bei Turn 40 voraus, gegenüber 112.617 gemessenen. Der quadratische Term dominiert, und der lineare Term ist das, was der Nutzer tatsächlich getippt hat.

Die Konsequenz ist der Satz, den du aus diesem Kapitel mitnehmen solltest: Deine Rechnung wächst mit dem Quadrat des Gesprächs, nicht mit der letzten Frage. Dieselben vierzig Fragen ganz ohne History kosten $0.066036. Mit History kosten sie $0.274386. Die History hat die Rechnung mit 4,2 multipliziert, und sie wird weiter multiplizieren, weil der Multiplikator die Gesprächslänge ist.

Das Window ist endlich aus zwei Gründen, die in dieselbe Richtung ziehen. Der erste ist der aus Kapitel 9: attention vergleicht jeden token mit jedem anderen token, also wächst die Arbeit dieser Schicht mit dem Quadrat der Sequenzlänge. Der zweite ist Speicher: Die KV cache wächst linear mit der Sequenzlänge, und Kapitel 13 hat diese Rechnung gemacht — bei langen Sequenzen ist sie größer als die weights.

Beide Limits wurden angegriffen, und keines wurde beseitigt. FlashAttention¹ organisiert die Berechnung neu, sodass viel weniger in High-Bandwidth-Memory gelesen und geschrieben wird; dadurch werden lange Sequenzen praktisch, ohne die asymptotischen Kosten zu ändern. Position Interpolation² und YaRN³ erweitern das nutzbare Window eines trainierten Modells, indem sie die positional encodings aus Kapitel 9 neu skalieren, statt neu zu trainieren. Zusammen erklären sie, warum Windows in fünf Jahren von 2K auf 1M gewachsen sind.

Was sie nicht getan haben: lange Kontexte kostenlos machen. Sie haben die Decke höher und die Steigung sanfter gemacht. Die Steigung ist noch da, und genau sie messen die Preisstufen später in diesem Kapitel.

Fast jeder Kostenrechner im Internet modelliert einen API-Call als input tokens mal Input-Preis plus output tokens mal Output-Preis. Das war 2023 richtig. Heute ist es auf eine Weise falsch, die Rechnungen in beide Richtungen um den Faktor zwei oder mehr verfehlt.

Es gibt fünf abrechenbare token-Kategorien:

Drei dieser fünf gab es vor zwei Jahren noch nicht als eigene Zeilen, und die zwei Cache-Zeilen sind die, die Leute falsch verstehen, weil ein cache write mehr kostet als gewöhnlicher Input, nicht weniger. Du zahlst einen Aufpreis, um etwas zu speichern, damit du es später mit Rabatt zurücklesen kannst, und ob sich das lohnt, hängt vollständig davon ab, wie oft du es liest.

Der reasoning-Bucket ist der aus Kapitel 12, jetzt mit Preis, und er enthält ein Detail, das klar ausgesprochen werden sollte: In Googles Dokumentation steht, dass Pricing „based on the full thought tokens the model needs to generate, despite only the summary being output from the API“ ist.⁴ Dir werden Tokens berechnet, die nie an dich übertragen werden. Es ist der einzige Bucket, dessen Inhalt du nicht zählen, prüfen oder verifizieren kannst.

Jetzt der Teil, der daraus ein Normalisierungsproblem statt ein Multiplikationsproblem macht. Jeder Provider meldet diese Buckets unter anderen Namen, und — das ist die Falle — zwei davon verwenden dasselbe Wort für zwei verschiedene Größen.

Nimm einen Call: 4.837 Tokens aus dem Cache gelesen, 110 frisch, 142 sichtbare output tokens, 300 reasoning tokens.

// OpenAI-compatible
{ "usage": { "prompt_tokens": 4947,
             "prompt_tokens_details": { "cached_tokens": 4837 },
             "completion_tokens": 442,
             "completion_tokens_details": { "reasoning_tokens": 300 } } }

// Anthropic
{ "usage": { "input_tokens": 110,
             "cache_read_input_tokens": 4837,
             "cache_creation_input_tokens": 0,
             "output_tokens": 442 } }

// Gemini
{ "usageMetadata": { "promptTokenCount": 4947,
                     "cachedContentTokenCount": 4837,
                     "candidatesTokenCount": 142,
                     "thoughtsTokenCount": 300 } }

Sieh dir prompt_tokens: 4947 und input_tokens: 110 an. Beide Felder sind die Input-token-Zahl für denselben prompt. OpenAIs Wert enthält die gecachten Tokens; Anthropics Wert schließt sie aus — die Dokumentation nennt die Identität ausdrücklich, total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ Anthropics input_tokens bedeutet „die Tokens nach deinem letzten Cache-Breakpoint“.

Und sieh dir den Output an. OpenAI und Anthropic melden beide 442, was die 300 reasoning tokens bereits enthält. Gemini meldet 142 und legt die 300 in ein eigenes Feld. Kapitel 12 hat das als Inkompatibilität zwischen zwei Arten markiert, dieselbe Arbeit zu zählen; hier ist, was sie kostet.

Ein Normalizer hat dreißig Zeilen und ist nicht optional:

export interface Usage {
  promptTokens?: number;        // input, NOT cached
  cachedInputTokens?: number;   // read from cache
  cacheWriteTokens?: number;    // written to cache on this call
  completionTokens?: number;    // output
  reasoningTokens?: number;     // billed apart from output (Gemini only)
}

const num = (v: unknown) => (typeof v === "number" && isFinite(v) ? v : 0);

export const fromOpenAI = (raw: any): Usage => {
  const u = raw.usage ?? {}, d = u.prompt_tokens_details ?? {};
  const cached = num(d.cached_tokens), write = num(d.cache_write_tokens);
  return {
    promptTokens: Math.max(0, num(u.prompt_tokens) - cached - write), 
    cachedInputTokens: cached,
    cacheWriteTokens: write,
    completionTokens: num(u.completion_tokens),   // reasoning already inside
    reasoningTokens: 0,
  };
};

export const fromAnthropic = (raw: any): Usage => {
  const u = raw.usage ?? {};
  return {
    promptTokens: num(u.input_tokens),            // already excludes cache
    cachedInputTokens: num(u.cache_read_input_tokens),
    cacheWriteTokens: num(u.cache_creation_input_tokens),
    completionTokens: num(u.output_tokens),
    reasoningTokens: 0,
  };
};

export const fromGemini = (raw: any): Usage => {
  const m = raw.usageMetadata ?? {}, cached = num(m.cachedContentTokenCount);
  return {
    promptTokens: Math.max(0, num(m.promptTokenCount) - cached),
    cachedInputTokens: cached,
    cacheWriteTokens: 0,
    completionTokens: num(m.candidatesTokenCount), // EXCLUDES thinking
    reasoningTokens: num(m.thoughtsTokenCount),    // billed at output rate
  };
};

Schick die drei Payloads oben durch die drei Reader, und alle drei erzeugen dasselbe Usage und damit dieselbe Zahl: $0.006491. Genau darum schreibt man diese Schicht.

Wenn du es falsch machst, kostet es beim selben Call Folgendes:

Der dritte ist der gefährliche, weil er still in Richtung guter Nachrichten scheitert. Dein Dashboard zeigt ein reasoning-Modell, das weniger als die Hälfte dessen kostet, was es tatsächlich kostet, und nirgends gibt es einen Fehler.

Sind die Buckets normalisiert, ist die Kostenfunktion kurz. Der einzige nicht offensichtliche Teil ist der Tier-Lookup, den der nächste Abschnitt erklärt:

export interface Tier { maxPromptTokens: number | null; price: number }
export interface Pricing {
  input: Tier[]; output: Tier[];
  cachedInput?: Tier[]; cacheWrite?: Tier[]; reasoning?: Tier[];
}

const tierPrice = (tiers: Tier[] | undefined, contextSize: number, fallback?: Tier[]) => {
  const table = tiers ?? fallback;
  if (!table?.length) return 0;
  const sorted = [...table].sort(
    (a, b) => (a.maxPromptTokens ?? Infinity) - (b.maxPromptTokens ?? Infinity));
  for (const t of sorted)
    if (t.maxPromptTokens === null || contextSize <= t.maxPromptTokens) return t.price;
  return sorted[sorted.length - 1].price;
};

export function computeCost(pricing: Pricing, usage: Usage): number {
  const fresh = usage.promptTokens ?? 0;
  const read  = usage.cachedInputTokens ?? 0;
  const write = usage.cacheWriteTokens ?? 0;
  const out   = usage.completionTokens ?? 0;
  const think = usage.reasoningTokens ?? 0;
  const contextSize = fresh + read + write;   // the tier depends on the WHOLE prompt
  return fresh * tierPrice(pricing.input, contextSize)
       + read  * tierPrice(pricing.cachedInput, contextSize, pricing.input)
       + write * tierPrice(pricing.cacheWrite,  contextSize, pricing.input)
       + out   * tierPrice(pricing.output, contextSize)
       + think * tierPrice(pricing.reasoning, contextSize, pricing.output);
}

Zwei Designentscheidungen dort sind es wert, verteidigt zu werden. Die Fallbacks — Cache-Preise fallen auf Input zurück, reasoning auf Output — kodieren, was eine fehlende Tabelle bedeutet: reasoning tokens auf Gemini werden mit der Output-Rate berechnet, also ist ein fehlender reasoning-Preis nicht null, sondern der Output-Preis. Und contextSize summiert alle drei Input-Buckets statt nur die frischen, weil der Tier danach gewählt wird, wie lang der prompt ist, nicht danach, wie viel davon dir zum vollen Preis berechnet wurde.

Ein prompt cache speichert den berechneten Zustand des Modells für ein Präfix deines prompts, sodass eine spätere Anfrage mit demselben Präfix die Neuberechnung überspringt. Aus dem Wort „Präfix“ folgen vier Eigenschaften, und alle vier überraschen Leute.

Der Break-even ist klein genug, um ihn im Kopf zu behalten, und OpenAIs Dokumentation rechnet es vor: Ein Präfix einmal zu schreiben und einmal wiederzuverwenden kostet 1,35× seiner normalen Input-Kosten, gegenüber 2×, wenn man es zweimal uncached verarbeitet; über zehn Requests kosten ein Write und neun Reads 2,15× gegenüber 10×. Eine Wiederverwendung bezahlt den Write. Anthropic landet an derselben Stelle: ein Read für den Fünf-Minuten-Cache, zwei für den Ein-Stunden-Cache.

Noch einmal das Vierzig-Turn-Gespräch, mit Caching an und stabilem Präfix:

Achtundsechzig Prozent günstiger, und drei Zahlen in dieser Tabelle verdienen Aufmerksamkeit.

Der Cache greift erst ab Turn 6. Der prompt erreicht erst dann 1.024 Tokens, also werden die ersten fünf Turns exakt wie zuvor berechnet — und der sechste wird schlechter berechnet, mit dem 1,25\u00d7-Write-Aufpreis, weil er der Turn ist, der den Cache füllt. Der erste Read kommt in Turn 7. Die 2.887 uncached Tokens in der Tabelle sind die Rechnung: fünf Turns, nicht sechs. Caching ist ein Rabatt auf lange prompts, und ein kurzes Gespräch bekommt davon nichts.

Der Write-Aufpreis beträgt $0.002474, also 2,8 % der gecachten Rechnung. Jeder Turn schreibt sein neues Ende, vierzig Mal, und der gesamte Write-Aufpreis ist ein Rundungsfehler gegenüber dem, was die Reads gespart haben. Die Write-Gebühr lohnt es, genau verstanden zu werden, damit du aufhörst, dir Sorgen darum zu machen.

Nur 2.887 Tokens wurden zum vollen Input-Preis berechnet von 112.617. So sieht ein funktionierender Cache aus: Fast alles ist ein Read.

Hier ist der Fehler, der echtes Geld kostet, und es ist ein Ein-Zeilen-Bug.

Setz etwas, das sich bei jedem Call ändert, an den Anfang des prompts — einen Zeitstempel, eine Request-ID, den Namen des Nutzers, eine „heute ist“-Zeile, ein frisch abgerufenes Dokument — und das Präfix unterscheidet sich ab Byte eins. Nichts matcht. Jeder Call ist ein Miss. Und weil jeder Call ein neues Präfix präsentiert, schreibt jeder Call auch.

Dasselbe Gespräch, dieselben vierzig Turns, Caching aktiviert, mit einem Zeitstempel pro Call ganz oben im system prompt:

Prompt caching zu aktivieren hat das Gespräch zwanzig Prozent teurer gemacht, als es nicht zu aktivieren. Du hast den 1,25×-Write-Aufpreis auf 109.730 Tokens bezahlt und null zurückgelesen. Es gibt keinen Fehler, keine Warnung, und das Feature ist eingeschaltet.

Die Regel, und sie ist ganz prompt caching in einer Zeile: stabiler Inhalt nach vorn, variabler Inhalt nach hinten. Systemanweisungen, Tool-Definitionen und Referenzmaterial zuerst; Zeitstempel, Nutzeridentität und die aktuelle Frage zuletzt. Anthropic macht die Hierarchie explizit — der Cache folgt tools → system → messages, und eine Änderung auf irgendeiner Ebene invalidiert diese Ebene und alles danach, sodass das Bearbeiten einer einzigen Tool-Beschreibung den gesamten Cache invalidiert.⁵

Zwei Konsequenzen, über die Leute stolpern. Zu ändern, welche Tools aktiviert sind, ändert die Tool-Definitionen, also teilt ein Feature-Flag, das für manche Nutzer ein Tool hinzufügt, deinen Cache in zwei. Und bei Anthropic verändert das Umschalten von Websuche oder Zitaten den system prompt, was die System- und Message-Caches invalidiert, ohne dass du eine Zeile eigenen Text anfasst.

Die offensichtliche Reaktion auf eine quadratische Rechnung ist, nicht mehr die ganze History zu senden: die letzten zwölf Nachrichten behalten und den Rest fallen lassen. Das reduziert die Rechnung, und es ist meistens der falsche Schritt, und die Messung zeigt warum.

Auf ein Zwölf-Nachrichten-Window zu kürzen ist 57 % günstiger als alles uncached zu senden — der Vergleich, den alle ziehen, und der Grund, warum die Technik beliebt ist. Aber es ist 39 % teurer, als alles mit einem funktionierenden Cache zu senden, und Caching zusammen mit Truncation einzuschalten macht es leicht schlechter statt besser.

Der Mechanismus ist wieder das Präfix. Ein Sliding Window entfernt in jedem Turn die älteste Nachricht, sodass der prompt nicht mehr dort beginnt, wo er beim letzten Mal begann, und jeder Turn ein neues Präfix präsentiert. OpenAIs Leitfaden sagt genau das: „summarisation, compaction, or context truncation can change the prefix and reset cache reuse.“⁶ Bei Turn 40 hat der Window-prompt 813 Tokens, unter dem Minimum von 1.024 Tokens, also kann er gar nicht gecacht werden.

Und das Geld ist die billige Hälfte der Kosten. Was du fallen gelassen hast, ist die Anweisung, die der Nutzer in Turn 2 gegeben hat und die das Modell in Turn 40 brauchte. Truncation tauscht eine Rechnung, die du sehen kannst, gegen einen Fehler, den du nicht sehen kannst, und es richtig zu machen — Verdichtung, strukturierte Notizen außerhalb des Windows, History bei Bedarf abrufen — ist Thema von Kapitel 24.

Lange Kontexte sind nicht nur teurer, weil sie länger sind. Jenseits eines Schwellenwerts sind sie pro token teurer, und der Schwellenwert gilt rückwirkend für den gesamten prompt.

OpenAIs Modellseite für gpt-5.6-terra sagt es in einem Satz: „Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request.“⁷ Nicht für den Überschuss. Für das Ganze.

prompt 271,999 + 500 output  ->  $0.5500
prompt 272,000 + 500 output  ->  $0.5500
prompt 272,001 + 500 output  ->  $1.0970

Ein token, fünfundfünfzig Cent. Wenn dein Service prompts aus abgerufenen Dokumenten baut, deren Größe du nicht kontrollierst, hast du in deinem Kostenmodell eine Klippe an einer Grenze, die niemand in deinem Team aufgeschrieben hat.

Googles Pricing funktioniert genauso mit einem Schwellenwert von 200.000 Tokens: Gemini 2.5 Pro kostet $1.25 pro Million input tokens für prompts bis 200K und $2.50 darüber, wobei Output von $10.00 auf $15.00 steigt.⁸ Anthropic ist den anderen Weg gegangen — am 6. September 2026 steht in der Dokumentation, dass Claude 4.6 und später das volle Ein-Million-token-Window zum Standardpreis enthalten, sodass „a 900k-token request is billed at the same per-token rate as a 9k-token request.“⁹ Frühere Modelle behielten den Aufschlag.

Darum ist ein Preis keine Zahl. Ein Preis ist eine Tabelle von Tiers, die nach prompt-Länge indiziert ist; dafür ist Tier[] in der Kostenfunktion da, und deshalb wählt computeCost den Tier anhand des gesamten prompts statt jeden Bucket separat.

Die fünf Buckets passen auf die zwei Phasen aus Kapitel 13, und sobald du das Mapping siehst, wirken die Preisverhältnisse nicht mehr willkürlich.

Input tokens sind prefill. Der gesamte prompt läuft in einem Pass durchs Modell, parallel verarbeitet — große Matrixmultiplikationen, compute-bound. Die Kosten pro token sind niedrig, und diese Phase bestimmt die time to first token: Ein prompt mit 4.947 Tokens hat 4.947 Tokens prefill zu erledigen, bevor das erste Wort erscheint.

Output tokens sind decode. Sie werden einzeln erzeugt, jeder mit einem vollständigen forward pass, der die gesamte KV cache liest, während die GPU meist auf Speicher wartet statt zu rechnen. Diese Phase bestimmt die tokens per second, sie lässt sich innerhalb einer Antwort nicht parallelisieren, und deshalb kostet Output beim hier bepreisten Modell etwa sechsmal so viel wie Input: $12.00 gegenüber $2.00 pro Million Tokens.

Drei Konsequenzen folgen direkt. Ein cache read ersetzt prefill-Arbeit, also kauft er Latenz und Geld zugleich — derselbe Rabatt zeigt sich als niedrigere Rechnung und kürzeres Warten auf den first token. Reasoning tokens sind decode, den du nie siehst, deshalb streamt ein reasoning-Modell mehrere Sekunden lang nichts und antwortet dann schnell: Kapitel 12 warnte vor der Interface-Konsequenz, und das hier ist die Rechnungs-Konsequenz. Und einen Stream abzubrechen stoppt die Generierung nicht — Kapitel 14 baute Cancellation und ließ den Preis diesem Kapitel, und der Preis ist die volle Output-Zahl, weil die Tokens erzeugt und abgerechnet werden, ob jemand zuhört oder nicht. Dasselbe gilt für die Antwort, die niemand behält: Eine Turn-40-Antwort fünfmal neu zu generieren kostet $0.057990 für die eine, die auf dem Bildschirm bleibt.

Der Tokenizer aus Kapitel 7 war Python und blieb dort. Budgetierung passiert auf dem Server, der den Request baut, also muss sie hier passieren, und es gibt genau drei Genauigkeitsstufen.

Stufe eins: lokal zählen. js-tiktoken liefert dieselben BPE-Merge-Tabellen wie das Python-tiktoken, also eine bytegenau identische Zählung für OpenAI-Encodings, ohne Netzwerk-Call:

import { getEncoding } from "js-tiktoken";

const enc = getEncoding("o200k_base");
const PER_MESSAGE = 4;   // role and delimiters added by the chat template
const PER_REPLY = 3;     // priming for the assistant turn

export function promptTokens(messages: { role: string; content: string }[]) {
  return messages.reduce(
    (sum, m) => sum + enc.encode(m.content).length + PER_MESSAGE, PER_REPLY);
}

Die zwei Konstanten sind wichtig und der Ort, an dem lokale Zählungen driften. Dein Text ist nicht das, was tokenisiert wird — das Chat-Template aus Kapitel 11 umhüllt jede Nachricht zuerst mit Rollenmarkern, und das sind Tokens, für die du zahlst. Vier pro Nachricht und drei für das Reply-Priming sind die konventionelle Näherung für OpenAI-Chatmodelle; über die einundachtzig Nachrichten des Gesprächs oben summieren sie sich auf 324 Tokens, 6,4 % seiner Länge. Die Zählungen hier wurden gegen das Python-tiktoken aus Kapitel 7 auf allen einundachtzig Strings gegengeprüft und sind identisch.

Stufe zwei: den Provider fragen. Anthropic stellt /v1/messages/count_tokens bereit und Google count_tokens, beide akzeptieren dieselbe Request-Form wie ein echter Call und geben kostenlos eine input token-Zahl zurück. Nutze sie, wenn du lokal nicht zählen kannst — und du kannst lokal nicht für Anthropic zählen, dessen Tokenizer nicht veröffentlicht ist. Anthropics Dokumentation ist vorsichtig damit, was sie dir gibt: Der Count „is an estimate“, und er „may include tokens added automatically by Anthropic for system optimizations“, für die „you are not billed“.¹⁰

Stufe drei: usage in der Response lesen. Das ist die Wahrheit, und sie kommt an, nachdem das Geld ausgegeben wurde. Genau deshalb gibt es die ersten zwei Stufen — um zu entscheiden, ob der Request gesendet wird, nicht um ihn abzurechnen.

Vier Posten, die nicht als Posten erscheinen.

Der system prompt, bei jedem Call bezahlt. Der obige hat mit Template-Overhead 192 Tokens. Über vierzig Calls sind das 7.680 Tokens — 5,6 % der gesamten Rechnung dieses Gesprächs, für acht einmal geschriebene Zeilen. Er ist außerdem der bestmögliche Cache-Kandidat, weil er stabil ist und zuerst kommt.

Tool-Definitionen. Name, Beschreibung und JSON-Schema jedes Tools gehen bei jedem Request raus, und Provider legen Scaffolding obendrauf. Anthropic veröffentlicht die Zahl: Tools überhaupt zu aktivieren fügt auf Claude Sonnet 4.5 mit tool_choice auf auto einen versteckten system prompt von 496 Tokens hinzu, oder 588 mit any oder einem benannten Tool.⁹ Das ist vor deinen eigenen Schemas. Kapitel 18 baut den Katalog; Kapitel 24 misst, was er frisst.

Jede Generierung, einschließlich derer, die du verwirfst. Fünf Regenerierungen kosten fünfmal. Der Chat zeigt eine.

Gedanken, die dir nicht gezeigt werden. Billing basiert auf den vollständigen thought tokens, obwohl nur eine Zusammenfassung zurückgegeben wird, und keine deiner Abrechnungen kann diese Zahl auditieren.

Eine Warnung zum Schluss, weil sie der natürliche nächste Gedanke ist und die Antwort nicht die offensichtliche.

Ein Window mit einer Million Tokens bedeutet nicht eine Million nutzbare Tokens. Retrieval-Genauigkeit nimmt mit der Position ab: Liu et al. fanden, dass Modelle Informationen am Anfang und am Ende eines langen Inputs zuverlässig finden und in der Mitte deutlich weniger zuverlässig.¹¹ Ein größeres Window kauft die Fähigkeit, mehr zu senden, nicht die Gewissheit, gelesen zu werden.

Dieses Phänomen wird in diesem Kurs einmal gemessen — die Retrieval-Rate an neun Positionen im selben 853-token-prompt — und gehört in Kapitel 24, wo es ändert, was ein agent tut. Es wird hier zitiert, weil es ändert, was du kaufen solltest: Der günstigste token ist der, den du nicht gesendet hast.

Du kannst jetzt vorhersagen, was ein Call kosten wird, bevor du ihn machst, danach lesen, was er gekostet hat, und den Unterschied zwischen beidem erkennen. Damit ist alles am Request abgedeckt, außer dem Teil, den du noch nicht angefasst hast: die Regler.

Kapitel 17 ist Sampling — temperature, top-p, top-k, die Penalties und die Determinism, die du nicht hast. Es beginnt damit, den verbreitetsten Fehler im Feld zu zerlegen: dass temperature ein Kreativitätsregler sei. Ist sie nicht: temperature teilt die logits aus Kapitel 4 vor der softmax, und sie zu erhöhen macht das Modell nicht einfallsreicher, sondern erhöht die Wahrscheinlichkeit von Tokens, die das Modell selbst schlechter bewertet hat. Von dort aus: warum greedy decoding messbar schlechteren Text erzeugt als Sampling, warum top-k und top-p an entgegengesetzten Verteilungsformen scheitern, und das Experiment, das das Kapitel beendet: Zwanzig identische forward passes bei temperature 0 kommen bitgenau identisch zurück, wenn das Modell allein läuft, und denselben prompt in einen Batch neben Requests anderer Leute zu legen, verschiebt 97 % seiner logits.

Sie stimmen nicht alle überein. Der Grund beginnt mit dem Floating-Point-Kasten aus Kapitel 2.

Alle Preise, Schwellenwerte und Multiplikatoren in diesem Kapitel wurden am 6. September 2026 von den eigenen Seiten der Provider gelesen und mit diesem Datum angegeben, weil sie sich ändern werden. Die Methode ist wichtiger als die Zahlen: Die Buckets, die Präfixregel und die Tier-Arithmetik sind seit zwei Jahren stabil, während sich jede Zahl darin bewegt hat.

Stanford CS336 Lecture 2, Resource accounting, ist die nächstliegende akademische Behandlung dieses Materials und die richtige nächste Lektüre: Sie macht auf der Trainingsseite dieselbe Rechnung, die dieses Kapitel auf der Inferenzseite macht. Die token-Zählungen hier wurden mit js-tiktoken 1.0.21 unter Verwendung der o200k_base- und cl100k_base-Encodings erzeugt, über ein Vierzig-Turn-Gespräch von 5.090 Tokens; der Template-Overhead pro Message ist die konventionelle Vier-plus-drei-Näherung und wird überall angegeben, wo er enthalten ist. Die Cache-, Tier- und Truncation-Zahlen sind die dokumentierten Pricing-Regeln angewendet auf diese gemessenen token-Zählungen, keine Beobachtungen live ausgeführter API-Responses — es wurde kein bezahlter Call gemacht, um dieses Kapitel zu erzeugen, was auch der ehrliche Grund ist, warum die Latenzaussagen qualitativ sind und die Kostenaussagen nicht.