Über die API

Alles, was in diesem Kurs bisher stand, spielte in einem Fenster: Sie tippen, das Modell antwortet, Sie lesen. Darunter liegt eine zweite Tür, durch die dieselben Modelle erreichbar sind. Sie hat keine Oberfläche, dafür eine Adresse.

Die Oberfläche ist selbst ein Programm

Was Sie im Browser bedienen, redet nicht mit dem Modell. Es redet mit einer Schnittstelle, die laut Übersicht des Anbieters (externe Seite, platform.claude.com) Programmen den Zugriff auf die Claude-Modelle gibt und dazu auf verwaltete Agenten, die beim Anbieter laufen. Die Anwendung macht damit genau das, was jedes andere Programm auch tun kann. Der Chat-Verlauf, die Knöpfe, der Kopieren-Schalter: alles davon gehört zur Anwendung. Das Modell dahinter sieht nur eine Anfrage über das Netz.

Für die Praxis heißt das zweierlei. Erstens ist jede Beobachtung aus dem Chat-Fenster immer eine Beobachtung über zwei Dinge, das Modell und die Anwendung darüber. Das reicht bis zu der Frage, wer überhaupt geantwortet hat: In ChatGPT lag diese Wahl zeitweise bei einer Automatik, die Geschichte steht in Kapitel 10. Über die Adresse nennen Sie das Modell selbst und bekommen genau dieses. Zweitens steht Ihnen dieselbe Tür offen, wenn Sie etwas bauen wollen, das ohne Mensch davor auskommt.

Der Schlüssel ist ein Ausweis

Um durch diese Tür zu kommen, braucht eine Anfrage einen Schlüssel. Der Begriff führt in die Irre, wenn man an ein Passwort denkt. Ein Passwort gehört einer Person und öffnet ihr Konto. Ein Schlüssel steht für eine Person oder für ein Dienstkonto der Organisation, wird maschinell benutzt und bekommt beim Anlegen einen Typ und eine Lebensdauer; beides legt man nach der Übersicht (externe Seite, platform.claude.com) für jeden Schlüssel einzeln fest.

Zur Wahl stehen Vorgaben von drei Stunden bis dreißig Tagen, eine eigene Dauer oder „nie“. Bei „nie“ übernimmt man den Ablauf selbst, und die Wahl fällt einmal: Die Seite zur Anmeldung (externe Seite, platform.claude.com) legt den Ablauf beim Anlegen fest, danach lässt er sich nicht mehr ändern.

Dazu endet ein Schlüssel mit dem, für den er steht. Verlässt eine Person die Organisation, hört ihr Schlüssel auf zu wirken. Den Zweck dieser Bauart (externe Seite, platform.claude.com) nennt der Anbieter selbst: Kein Schlüssel soll versehentlich die Person oder den Dienst überdauern, dem er gehört.

Ältere Schlüssel eines Arbeitsbereichs gibt es weiter, sie gelten als Altbestand.

Dazu lässt sich ein Schlüssel eingrenzen. Wer Entwicklung und Betrieb auseinanderhält, gibt jedem einen eigenen Arbeitsbereich, und dann lässt sich je Bereich sehen und begrenzen, was verbraucht wird. Die Dokumentation (externe Seite, platform.claude.com) empfiehlt genau das: Arbeitsbereiche in der Console, um Umgebungen zu trennen und die Ausgaben je Anwendungsfall zu steuern.

Beim Verlust zeigt sich dann doch eine Ähnlichkeit zum Passwort. Wer den Schlüssel hat, arbeitet auf Ihre Rechnung und erreicht dieselben Stellen wie Sie. Hinter derselben Adresse liegen die verwalteten Agenten vom Anfang dieser Seite, dazu hochgeladene Dateien und abgelegte Anleitungen. Die Rechnung ist der sichtbarste Teil des Schadens. Der Anbieter behandelt einen abhan­den­ge­kom­menen Schlüssel entsprechend und rät auf der Seite zur Anmeldung (externe Seite, platform.claude.com), jeden Schlüssel abzuschalten oder zu löschen, bei dem man ein Durchsickern auch nur vermutet.

Zwei Wege stehen dafür bereit, und sie unterscheiden sich in der Umkehrbarkeit: Abschalten lässt sich zurücknehmen, Löschen legt den Schlüssel endgültig ins Archiv.

Jede Anfrage steht für sich

Die zweite Eigenart ist die folgenreichere, und der Anbieter schreibt sie selbst hin (externe Seite, platform.claude.com): Die Nachrichten-Schnittstelle hält keinen Zustand, also schickt man ihr immer den vollständigen bisherigen Gesprächsverlauf.

Die Schnittstelle kennt also einzelne Aufrufe, von denen jeder alles mitbringt, was das Modell wissen soll. Eine Unterhaltung entsteht erst dadurch, dass ein Programm den Verlauf aufhebt und bei der nächsten Runde erneut mitschickt.

seitlich verschiebbar

eigene Darstellung, Stand 05.08.2026

Das Chat-Fenster täuscht darüber hinweg, weil es die Arbeit für Sie erledigt: Es hebt den Verlauf auf und schickt ihn bei jeder Runde erneut mit. Ein eigener Aufbau muss das selbst tun. Hier liegt auch die Antwort darauf, warum ein langes Gespräch teurer wird als ein kurzes: Bei doppelter Länge wird ohne Cache grob die vierfache Menge gesendet. Gerechnet ist das an einem Sprachdialog in Conversational AI, Kapitel 11. Dieselbe Mechanik erklärt auch, warum ein Tool im eigenen Programm zwei Durchläufe kostet. Ein Tool beim Anbieter kommt in der Regel mit einer Anfrage aus; beides steht in Kapitel 09.

Gemeint ist damit der Verlauf, den das Modell bei der nächsten Anfrage vor sich hat. Was ein Anbieter für seine eigenen Zwecke speichert, ist eine getrennte Frage mit einer eigenen Antwort je Funktion und je Vertrag; sie steht in Beurteilen und Einordnen, Kapitel 01.

Warum das auch angeht, wer nie programmiert

Man kann diesen Bereich für eine Sache der Entwickler halten. Drei Fälle sagen etwas anderes.

Sie kaufen ein Werkzeug ein. Jede Anwendung mit eingebauter KI spricht im Hintergrund eine solche Schnittstelle an, meistens die eines der großen Anbieter. Was dort an Bedingungen gilt, gilt damit auch für Ihre Daten. Welche Kontoart dabei zum Tragen kommt und was daraus folgt, steht in Beurteilen und Einordnen, Kapitel 01.

Sie verhandeln über Mengen. Was ein Zugang leistet, steht in Grenzen je Minute, und die hängen an einer Stufe, in die eine Organisation eingeordnet wird. Dazu kommt ein monatlicher Deckel (externe Seite, platform.claude.com), der festlegt, wie viel eine Organisation im Monat höchstens für die Nutzung der Schnittstelle ausgeben kann.

Sie beurteilen ein Angebot. Ein Anbieter, der einen festen Monatspreis nennt, zahlt dahinter meist selbst nach Verbrauch. Mit den Einheiten im Kopf lässt sich fragen, was passiert, wenn die Nutzung steigt.

Eine Anfrage an ein Sprachmodell ist ein gewöhnlicher HTTP-Aufruf. Das ist die gute Nachricht für jeden, der schon einmal eine Schnittstelle angesprochen hat, und es bedeutet, dass hier dieselben Werkzeuge greifen wie überall sonst.

Drei Header und ein Rumpf

Der Aufruf geht als POST an eine feste Adresse. Was ihn von einem beliebigen anderen unterscheidet, sind die Header, die laut Übersicht (externe Seite, platform.claude.com) jede Anfrage an die Schnittstelle mitbringt:

Ein Schlüssel, der für mehrere Arbeitsbereiche gilt, braucht dazu anthropic-workspace-id, damit die Anfrage weiß, wohin sie gehört.

Die Versionsangabe ist die interessanteste der drei, und sie verspricht weniger, als der Name nahelegt. Erhalten bleiben die vorhandenen Ein- und Ausgabefelder, damit ein laufendes Programm weiterläuft. Die Seite zu den Versionen (externe Seite, platform.claude.com) sagt das mit einem einschränkenden „im Allgemeinen“: Wer die Schnittstelle so benutzt, wie die Referenz sie beschreibt, dessen Nutzung macht Anthropic nicht kaputt.

Die Antwortform kann sich innerhalb derselben Version trotzdem ändern. Dieselbe Seite führt auf, was sich der Anbieter vorbehält: zusätzliche Ausgabewerte, geänderte Bedingungen einzelner Fehlertypen und neue Werte in Ausgabefeldern (externe Seite, platform.claude.com), die nur eine feste Auswahl kennen.

Wer sein Programm dagegen hart macht, verträgt also unbekannte Felder, statt sich auf die Zahl zu verlassen. Umgekehrt kostet die Zahl auch weniger, als viele annehmen: Die Versionsliste (externe Seite, platform.claude.com) hat seit Juni 2023 keinen Eintrag mehr bekommen, und alles, was seither dazugekommen ist, kam unter derselben Angabe.

Im Rumpf steht das Modell, eine Obergrenze für die Ausgabe und die Nachrichten, jede mit einer Rolle. Mehr braucht es für einen ersten Aufruf nicht. Die Bibliotheken der Anbieter setzen die Header selbst und wiederholen vorübergehende Fehler von sich aus, allerdings in engen Grenzen. Laut Fehlerseite (externe Seite, platform.claude.com) wiederholt die offizielle Bibliothek Verbindungsfehler, erreichte Ratengrenzen und Serverfehler der 500er-Reihe mit wachsendem Abstand, in der Grundeinstellung zweimal, und beachtet dabei den Header retry-after, wenn er mitkommt.

Der Modellname im Rumpf gilt so lange, wie der Anbieter das Modell führt. Google etwa hat gemini-3.7-flash am 08.10.2026 abgekündigt und leitet Anfragen an diesen Namen laut Änderungsliste (externe Seite, ai.google.dev) seither von selbst auf gemini-3.8-flash um. Gleich danach rät Google, den Namen im eigenen Programm umzustellen. Laut Abkündigungsliste (externe Seite, ai.google.dev) bleibt der Endpunkt dabei bestehen. Die Anwendung läuft also weiter und rechnet dabei mit einem anderen Modell, als ihr Code nennt.

Der Schlüssel gehört in den Serverraum

Eine Anfrage lässt sich technisch auch aus dem Browser abschicken. Genau das ist der häufigste Fehler beim ersten eigenen Aufbau, denn wer den Schlüssel an den Browser ausliefert, hat ihn veröffentlicht. Jeder Besucher kann ihn aus dem Quelltext lesen und auf Ihre Rechnung arbeiten.

Der übliche Aufbau schiebt deshalb einen eigenen kleinen Dienst dazwischen. Der Browser spricht mit Ihrem Dienst, Ihr Dienst spricht mit dem Anbieter, und der Schlüssel verlässt nie den Serverraum. Das kostet einen Baustein mehr und bringt zwei Dinge mit, die Sie ohnehin brauchen werden: eine Stelle, an der sich mitzählen lässt, wer wie viel verbraucht, und eine Stelle, an der sich Missbrauch abfangen lässt.

Für den Fall, in dem dieser Baustein fehlt, gibt es einen eigenen Weg. Eine ausgelieferte App kann sich beim Anbieter als echte Installation ausweisen und bekommt dafür ein kurzlebiges Zugangsmerkmal. Gedacht ist der Weg laut Seite zur Anmeldung (externe Seite, platform.claude.com) für Apps unter iOS und macOS, die an Endnutzer ausgeliefert werden und die Schnittstelle direkt aufrufen, ohne eigenen Server oder Vermittler dazwischen.

Ausgeliefert wird dabei ein Merkmal mit kurzer Haltbarkeit: Es gilt eine Stunde und nur für die Nachrichten-Schnittstelle. Der dauerhafte Schlüssel bleibt, wo er ist.

Drei Grenzen laufen nebeneinander

Was ein Zugang leistet, ist begrenzt, und die Begrenzung hat mehrere Dimensionen. Wofür sie gilt, sagt die Dokumentation (externe Seite, platform.claude.com) gleich im ersten Satz: Um Missbrauch einzudämmen und die Kapazität zu steuern, ist begrenzt, wie viel eine Organisation die Schnittstelle nutzen kann.

Gemessen wird also der Zugang über die Schnittstelle, und zwar je Organisation. Was in einer Chat-Anwendung gilt, steht dort nicht. Ein Abo bringt eigene Nutzungsgrenzen mit, die anders gemessen und anders gemeldet werden. Wer in ChatGPT oder Claude an eine Grenze stößt, bekommt einen Hinweis im Gespräch. Ein Fehlercode entsteht an der Schnittstelle.

Der Anbieter beschreibt die Begrenzung des Zugangs (externe Seite, platform.claude.com) als Höchstzahl der Anfragen, die eine Organisation in einem festgelegten Zeitraum stellen kann, und misst dabei drei Größen getrennt: Anfragen je Minute, Eingabe-Token je Minute, Ausgabe-Token je Minute.

seitlich verschiebbar

eigene Darstellung, Stand 05.08.2026

Die praktische Folge ist, dass verschiedene Anwendungen an verschiedenen Grenzen anstoßen. Ein Dienst mit vielen kurzen Anfragen läuft in die Anfragengrenze. Ein Dienst, der lange Dokumente auswertet, läuft in die Eingabegrenze, während er bei den Anfragen weit unter dem Erlaubten bleibt. Wer nur eine Zahl im Kopf hat, sucht den Fehler an der falschen Stelle.

Die Grenzen gelten je Modell und je Organisation. Zwei Modelle nebeneinander zu benutzen, zieht deshalb meistens aus zwei getrennten Töpfen. Die Ausnahmen stehen als Fußnoten unter derselben Tabelle. Sie fassen Fassungen einer Familie zu einem Topf zusammen. Für Opus steht in der Tabelle der Grenzen (externe Seite, platform.claude.com), dass eine Gesamtgrenze für den Verkehr von Opus 4.8, 4.7, 4.6 und 4.5 zusammen gilt.

Dieselbe Fußnote nimmt die neueren Fassungen ausdrücklich heraus: Opus 5.5 und Opus 5 haben je eine eigene Grenze und gehören nicht in diesen gemeinsamen Topf.

Wer während eines Wechsels von Opus 4.8 auf Opus 5.5 beide Fassungen fährt, zieht also aus zwei Töpfen. Fable 5 und Fable 5.1 teilen sich dagegen einen, ebenso Sonnet 4.5 und 4.6. Welche Kennungen zusammengefasst sind, steht in den Fußnoten und ändert sich mit jeder neuen Modellreihe.

Was bei einer Abweisung zu tun ist

Wird eine Grenze erreicht, kommt die Antwort mit dem Code 429 zurück, in der Fehlerliste (externe Seite, platform.claude.com) geführt mit der Erklärung, die Organisation habe eine Ratengrenze erreicht.

Zwei Dinge stehen dann in der Antwort, und beide sind nützlich. Ein Header retry-after nennt die Zahl der Sekunden bis zum nächsten Versuch. Und die Fehlermeldung sagt, welche der drei Grenzen erreicht wurde.

Der falsche Reflex ist, sofort erneut zu fragen. Der richtige Umgang steht in derselben Doku (externe Seite, platform.claude.com), dort für den Fall eines Serverfehlers, und gilt hier genauso: die Anfrage wiederholen, mit exponentiell wachsendem Abstand. Also warten, dann noch einmal doppelt so lange warten, und dabei die genannte Wartezeit beachten. Wer stattdessen in einer engen Schleife nachfragt, bekommt dieselbe Abweisung ein zweites Mal und erzeugt zusätzliche Last, die nichts einbringt. Dass auch ein sprunghafter Anstieg für sich genommen zur Abweisung führt, steht in Ebene 3.

Der Deckel über allem

Neben den Mengen je Minute steht eine zweite Art Grenze, die im Alltag seltener auffällt und dann umso härter trifft. Sie legt nach der Dokumentation (externe Seite, platform.claude.com) fest, wie viel eine Organisation im Monat höchstens für die Schnittstelle ausgeben kann, und wenn dieser Betrag erreicht ist, ruht der Zugang bis zum nächsten Monat. Die Beträge hängen an der Nutzungsstufe: bei der Einstiegsstufe dreistellig, auf der zweiten vierstellig, auf der dritten sechsstellig. Für einen Versuchsaufbau ist das viel, für einen Dienst mit echten Nutzern kann es der Betrag einer Woche sein. Darüber liegt eine Stufe mit individuell vereinbarten Grenzen, und für sie gilt kein Monatsdeckel (externe Seite, platform.claude.com).

Auch diese Abweisung kommt als 429, derselbe Code wie oben bei den Minutengrenzen. Der Umgang damit unterscheidet sich trotzdem: Ein Header mit der Wartezeit fehlt, und wer es dennoch mit Zurückhalten und erneutem Versuch probiert, bekommt dieselbe Abweisung, bis der Monat wechselt oder die Organisation in eine höhere Stufe kommt. Das gilt auch für die automatischen Wiederholungen der Bibliotheken. Erkennen lässt sich der Fall an einem eigenen Feld der Fehlermeldung, error_code mit dem Wert enforced_spend_limit_reached. Genau dafür ist es laut Doku (externe Seite, platform.claude.com) da: um diese Antwort von einer Ratengrenze zu unterscheiden.

Der Rat aus dem vorigen Abschnitt gilt also nur für die Minutengrenzen.

Ein eigener, niedrigerer Deckel lässt sich zusätzlich setzen, und für die einzelnen Arbeitsbereiche ebenfalls. Das ist die Stelle, an der ein Fehler im eigenen Code aufhört, teuer zu werden. Ist er erreicht, kommt die Abweisung als 400 (externe Seite, platform.claude.com), mit dem Fehlertyp für eine ungültige Anfrage, und die Meldung nennt, wann der Zugang wieder offen ist. Was die einzelne Anfrage kostet und warum die Ausgabe die teure Spalte ist, steht in Kapitel 10.

Die Zahlen aus Ebene 2 beschreiben, was erlaubt ist. Interessant wird es an der Frage, wie sie gemessen werden, denn davon hängt ab, ob ein Aufbau mit denselben Grenzen das Doppelte schafft oder die Hälfte.

Das Kontingent füllt sich fortlaufend

Die naheliegende Vorstellung ist ein Zähler, der zur vollen Minute auf null springt. Die Dokumentation (externe Seite, platform.claude.com) beschreibt es anders: Das Kontingent füllt sich laufend bis zur Höchstgrenze wieder auf, ein Zurücksetzen in festen Abständen gibt es nicht.

Das Verfahren heißt Token-Bucket und ist im Netzbetrieb seit Jahrzehnten üblich. Man stelle sich einen Eimer vor, der stetig nachläuft und eine Höchstmarke hat. Jede Anfrage schöpft daraus, und wer schneller schöpft als nachläuft, steht irgendwann vor einem leeren Eimer.

Daraus folgt ein Verhalten, das viele zunächst für einen Fehler halten. Die Doku benennt es selbst: Eine Grenze von 60 Anfragen je Minute kann als eine Anfrage je Sekunde durchgesetzt werden. Sechzig Aufrufe gleichzeitig abzuschicken, führt deshalb zu Abweisungen, obwohl die Minutenzahl eingehalten ist. Gleichmäßig verteilt reicht dasselbe Kontingent weiter.

Dieselbe Mechanik erklärt einen zweiten Fall. Auch ein zu schneller Anstieg wird gebremst, unabhängig von den Minutengrenzen. Die Doku (externe Seite, platform.claude.com) nennt dafür Grenzen der Beschleunigung: Steigt die Nutzung einer Organisation sprunghaft an, kann ebenfalls ein 429 kommen.

Der Fehlercode ist derselbe wie bei einer erreichten Minutengrenze, der Anlass ein anderer, und der Rat lautet, den Verkehr allmählich hochzufahren. Nach einem 429 lohnt deshalb zuerst der Blick auf den Verlauf der letzten Minuten, erst danach auf die einzelne Zahl.

Was zwischengespeichert ist, zählt nicht mit

Hier liegt der größte Hebel, und er wird regelmäßig übersehen, weil er unter einem Kostenthema abgelegt ist. Bei den meisten Claude-Modellen zählen laut Dokumentation (externe Seite, platform.claude.com) nur die Eingabe-Token, die nicht aus dem Cache kommen, gegen die Grenze für Eingabe-Token je Minute.

seitlich verschiebbar

eigene Darstellung, Stand 05.08.2026

Die Doku rechnet ein Beispiel vor: Bei zwei Millionen erlaubten Eingabe-Token je Minute und einer Trefferquote von 80 Prozent im Cache lassen sich zehn Millionen verarbeiten. Der Faktor fünf entsteht ohne jede Verhandlung über höhere Grenzen.

Die Einschränkung auf „die meisten“ hat dabei einen konkreten Adressaten. In derselben Tabelle steht an Claude Haiku 3.5 eine Fußnote, und für dieses Modell zählen auch die wiederverwendeten Token gegen die Minutengrenze. Bei Anthropic ist es abgeschaltet, über Google Cloud läuft es noch. Wer es dort einsetzt, plant ohne diesen Hebel.

Der Unterschied zum Preisthema ist wichtig. In Kapitel 10 geht es darum, dass zwi­schen­ge­spei­cherte Eingabe billiger abgerechnet wird. Hier geht es darum, dass sie beim Durchsatz gar nicht mitgezählt wird. Beides zusammen macht aus einer Systemanweisung, die bei jeder Anfrage identisch mitreist, den lohnendsten Kandidaten für eine feste Marke im Cache.

Die Kehrseite: Eine Marke, die bei jeder Anfrage anders gesetzt wird, verliert beides gleichzeitig. Und eine geänderte Konfiguration kann den Cache ebenfalls entwerten, etwa eine Tool-Liste, die zwischen zwei Anfragen wächst. Die Grafik oben führt sie als einen der Teile, die sonst über alle Aufrufe gleich bleiben.

Für den Sprachdialog schreibt OpenAI ausdrücklich dazu (externe Seite, developers.openai.com), dass der Cache dort ohne Zusage arbeitet. Was das für die Rechnung eines Gesprächs heißt, steht in Conversational AI, Kapitel 11.

Auf der Ausgabeseite gilt eine andere Rechnung, und sie räumt einen verbreiteten Verdacht aus. Gezählt wird dort, was tatsächlich erzeugt wurde. Die Doku (externe Seite, platform.claude.com) sagt ausdrücklich, dass der Parameter max_tokens nicht in die Grenze für Ausgabe-Token je Minute eingeht; ein höherer Wert hat also bei den Grenzen keinen Nachteil.

Eine großzügig gesetzte Obergrenze kostet also nichts, solange die Antwort kurz ausfällt.

Eine Grenze ist eine Obergrenze

Der Satz, der die Erwartung an diese Zahlen zurechtrückt, steht in der Doku (externe Seite, platform.claude.com) selbst: Alle beschriebenen Grenzen geben die höchste erlaubte Nutzung an. Zugesagt ist damit keine Mindestmenge.

Das ist mehr als eine juristische Absicherung. Es heißt, dass eine erreichte Grenze und eine ausbleibende Antwort zwei verschiedene Ereignisse sind, die sich nur bei genauem Hinsehen unterscheiden lassen. Ein 429 sagt, dass Sie zu viel wollten. Ein 529 meldet laut Fehlerseite (externe Seite, platform.claude.com), dass die Schnittstelle vorübergehend überlastet ist, und dieselbe Seite nennt den Fall dazu: hoher Verkehr über alle Nutzer hinweg. Beide führen dazu, dass keine Antwort kommt, und beide erfordern verschiedene Reaktionen: Im ersten Fall hilft es, den eigenen Takt zu senken, im zweiten hilft nur Warten.

Für einen Aufbau, der etwas zusagen muss, folgt daraus eine unbequeme Konsequenz. Eine Ver­füg­bar­keits­zu­sage gegenüber dem eigenen Nutzer kann sich nicht auf die Grenzen des Anbieters stützen, weil dort ausdrücklich keine Untergrenze zugesagt ist. Eine solche Zusage braucht deshalb einen zweiten Weg.

Zurückhalten, und zwar mit Kennung

Die Bibliotheken der Anbieter wiederholen vorübergehende Fehler von sich aus, zweimal, mit wachsendem Abstand und unter Beachtung der genannten Wartezeit. Das deckt den Normalfall ab und hört danach auf. Wer selbst baut, hält sich an dieselbe Regel und setzt eine Streuung dazu: Laufen zehn Kopien desselben Dienstes, warten sie nach einer Abweisung sonst alle gleich lang und stoßen gemeinsam wieder an.

Zwei Feinheiten fallen dabei leicht unter den Tisch. Erstens ist eine Wiederholung bei einem 400 sinnlos. Meist ist dann die Anfrage selbst fehlerhaft, oder ein selbst gesetzter Ausgabendeckel ist erreicht, wie in Ebene 2 beschrieben. Beides ändert eine Wiederholung nicht, und eine Schleife darüber erzeugt nur Last. Zweitens hat jede Antwort eine Kennung: Laut Fehlerseite (externe Seite, platform.claude.com) kommt jede Antwort der Schnittstelle mit einem eigenen Header request-id, der sie eindeutig bezeichnet.

Mit ihr im Protokoll lässt sich später über einen einzelnen Vorfall sprechen. Ohne sie bleibt bei einer Rückfrage an den Anbieter nur die ungefähre Uhrzeit.

Dieselbe Sprache auf dem eigenen Rechner

Der Aufbau lässt sich vom Anbieter lösen, und im günstigen Fall merkt die Anwendung davon wenig. Programme, die Modelle lokal ausführen, sprechen dieselbe Form, Ollama sogar zwei davon. Welche Programme das sind und an welchem Port sie hören, zeigt Nutzung und Anpassung von LLMs, Kapitel 05. Die eine ist die von OpenAI: Programme, die für OpenAI geschrieben sind, lassen sich laut Ollamas Seite zur OpenAI-Form (externe Seite, docs.ollama.com) an Ollama anschließen, und Ollama unterstützt davon eine Teilmenge.

Die andere ist die Nachrichten-Schnittstelle aus diesem Kapitel. Die zweite Seite (externe Seite, docs.ollama.com) richtet sich an Programme und Werkzeuge für Anthropic, Claude Code eingeschlossen.

Das Wort subset, Teilmenge, steht auf beiden Seiten und ist die eigentliche Auskunft. Auf der zweiten Seite folgt die Liste dessen, was fehlt: Die Steuerung der Tool-Wahl, nachgeladene Tools und die gehostete Websuche werden nicht vollständig unterstützt.

Im einfachsten Fall genügt eine geänderte Adresse, und im Beispiel für den lokalen Server steht dann noch ein Schlüssel. Der Vermerk daneben (externe Seite, docs.ollama.com) sagt, dass er angegeben werden muss und dann nicht beachtet wird.

Wo niemand abrechnet, bleibt von ihm eine Formalie übrig. Dass er hier keine Rechte prüft, ist eine Eigenschaft dieses lokalen Zugangs. Über das, was ein Schlüssel beim Anbieter aufschließt, sagt es nichts.

Eine Adresse auf dem eigenen Rechner sagt allerdings noch nicht, wo gerechnet wird. Beide Seiten beginnen inzwischen mit dem Weg in Ollamas eigene Cloud, und dort prüft der Schlüssel wieder Rechte. Nach einer Anmeldung reicht auch der lokale Server Cloud-Modelle durch (externe Seite, docs.ollama.com). Ob eine Anfrage das Gerät verlässt, hängt dann am gewählten Modell.

Zwei Handgriffe kommen trotzdem hinzu, beide auf derselben Seite. Das Modell muss vorher geholt werden, und eine Anwendung, die auf feste Modellnamen des Anbieters eingestellt ist, braucht einen passenden Namen auf der anderen Seite. Für Werkzeuge, die mit OpenAIs Modellnamen wie gpt-3.5-turbo rechnen, rät die Seite (externe Seite, docs.ollama.com), mit ollama cp ein vorhandenes Modell unter diesem Namen zu kopieren.

Was darüber hinaus zu tun ist, hängt daran, welche Felder eine Anwendung benutzt. Die Seite zählt sie einzeln auf, Endpunkt für Endpunkt, und diese Liste ist die belastbare Antwort auf die Frage, wie teuer ein Wechsel wird.

Damit bekommt die Betriebsfrage aus Beurteilen und Einordnen, Kapitel 01 eine technische Untergrenze: Der Wechsel zwischen einem Anbieter und dem eigenen Rechner fängt bei einer Zeile an. Was danach kommt, steht dort, von der Modellgüte über die Stromrechnung bis zu der Frage, um die es dort eigentlich geht: wer die Eingaben rechtlich verarbeiten darf. Die Geschwindigkeit hat einen eigenen Ort, weil sie am Gerät gemessen werden muss: eine Messung über sieben Beschleu­ni­gungs­ver­fahren.

Was die Anwendung dazutut

Zum Schluss die Gegenrichtung, weil sie erklärt, warum ein selbst gebauter Zugang zunächst schlechter wirkt als das gewohnte Fenster. Zwischen dem Modell und dem, was Sie im Browser sehen, liegt eine ganze Schicht, beschrieben in Kapitel 01: Ver­laufs­ver­wal­tung, Tools, Cache, Sicherheitsfilter, gestreamte Ausgabe.

Wer selbst baut, bekommt das Modell und muss diese Schicht selbst stellen. Das ist der eigentliche Aufwand, und er erklärt, warum die erste eigene Anwendung in zehn Minuten steht und die zweite Fassung Wochen braucht.

Ein Stück davon ist inzwischen beim Anbieter zu haben, und dann fällt genau die Eigenschaft weg, an der das ganze Kapitel hängt. Die verwalteten Agenten führen laut Seite zur Datenaufbewahrung (externe Seite, platform.claude.com) einen Zustand, und die Mitschriften ihrer Sitzungen bleiben liegen, bis man sie löscht.

Wer diesen Weg nimmt, tauscht die Ver­laufs­ver­wal­tung im eigenen Code gegen ein Protokoll, das beim Anbieter liegt, bis jemand es löscht. Aus einer Bauentscheidung wird damit eine Frage an den Vertrag: wie lange es dort liegt und wer es sehen darf. Das ist dieselbe Frage, die Beurteilen und Einordnen, Kapitel 01 für die Eingaben stellt, nur an einer Stelle, an der man sie zuletzt vermutet.

Bei OpenAI ist dasselbe eine Wahl an der Schnittstelle. Die Antworten-Schnittstelle führt den Verlauf auf Wunsch selbst, über die Kennung der vorigen Antwort oder über ein eigenes Gesprächsobjekt. Ein solches Objekt speichert laut Anleitung zum Gesprächszustand (externe Seite, developers.openai.com) Einträge: Nachrichten, Tool-Aufrufe, deren Ergebnisse und anderes.

Abgerechnet wird trotzdem der ganze Verlauf. Für eine Kette über die Kennung der vorigen Antwort schreibt OpenAI in derselben Anleitung (externe Seite, developers.openai.com), dass alle bisherigen Eingabe-Token der Antworten in der Kette als Eingabe berechnet werden.

Die Rechnung aus Ebene 1 gilt also weiter. Das Mitschicken übernimmt dann der Anbieter, und damit stellt sich die Frage an den Vertrag ein zweites Mal: Eine gespeicherte Antwort liegt dort in der Grundeinstellung 30 Tage, ein Gesprächsobjekt ohne diese Frist.