Source: https://aiprimetech.io/de/blog/reduce-llm-token-usage/ Juni 20, 2026 · 7 Min. · API # Den Token-Verbrauch technisch senken, ohne die Qualität zu beeinträchtigen A Von [AI Prime Tech](https://aiprimetech.io/de/) · KI-unterstützt Letzten Monat habe ich einen Kundensupport-Agenten überprüft, der pro Ticket 18,000–42,000 Eingabetokens verbrauchte, bevor er auch nur ein Wort schrieb. Das eigentliche Nutzerproblem umfasste meist weniger als 300 Tokens. Der Rest war Kontext „für alle Fälle“: der vollständige Gesprächsverlauf, jede interne Richtlinienseite, die per Stichwortsuche abgerufen wurde, JSON wortwörtlich kopierte Tool-Ergebnisse und ein Systemprompt mit 900 Tokens, der über sechs Monate hinweg immer weiter angewachsen war. Die Lösung war weder „ein kleineres Modell verwenden“ noch „ max_tokens senken und hoffen“. Wir reduzierten den medianen Tokenverbrauch um etwa 68 %, während die Antwortqualität stabil blieb – durch unspektakuläre Engineering-Arbeit: Kontext kürzen, gezieltere Belege abrufen, den Zustand zusammenfassen, Ausgabeschemas durchsetzen und Tokens ehrlich messen. Dieser Artikel handelt von genau dieser Arbeit. Nicht von Prompt-Golf. Nicht von Tricks, die das Modell schlechter machen. Sondern von praktischen Möglichkeiten, weniger Tokens zu verbrauchen, ohne Ihr System weniger intelligent zu machen. ## Tokenverbrauch ist ein Architekturproblem Die meisten Teams betrachten Tokenkosten als ein Problem der Modellpreise. In der Praxis geht es meist darum, welche Informationen wohin geleitet werden. Ein typischer LLM-Aufruf im Produktivbetrieb umfasst vier Tokenkategorien: - Anweisungstokens: Systemprompt, Entwicklerprompt, Formatierungsregeln, Sicherheitsvorgaben. - Kontexttokens: Chatverlauf, abgerufene Dokumente, Tool-Ausgaben, Datenbankdatensätze. - Denk-/Aufgabentokens: die eigentliche Nutzeranfrage und Details zu Zwischenschritten der Aufgabe. - Ausgabe-Token: die generierte Antwort, das JSON-Objekt, die SQL-Abfrage, die Zusammenfassung oder der Tool-Aufruf. Wenn der Tokenverbrauch außer Kontrolle gerät, sind meist Kontext und Ausgabe die Ursache. Das Modell ist nicht teuer, weil der Nutzer eine schwierige Frage gestellt hat. Es ist teuer, weil die Anwendung die ganze Welt in den Prompt gepackt und dem Modell anschließend erlaubt hat, endlos auszuschweifen. Eine nützliche erste Übung besteht darin, den Tokenverbrauch nach Abschnitt zu protokollieren, nicht nur die Gesamtgröße der Anfrage: ``` { "request_id": "ticket_81291", "model": "sonnet-4.6", "tokens": { "system": 742, "history": 3890, "retrieval": 12640, "tool_results": 2110, "user": 184, "output": 931 }, "latency_ms": 4820 } ``` Sobald Sie diese Aufschlüsselung sehen, wird der Weg zur Optimierung offensichtlich. Sie müssen nicht abstrakt darüber diskutieren, ob Claude Opus 4.8, Sonnet 4.6, GPT-5.5, Gemini 3, Fable 5 oder ein offenes Modell wie Qwen oder DeepSeek „am besten“ ist. Zuerst müssen Sie aufhören, 12,000 irrelevante Tokens aus abgerufenen Inhalten zu senden. ## Beginnen Sie mit einem Tokenbudget pro Route Ich vergebe Budgets gern pro Produktroute statt global. Eine juristische Vertragsprüfung, ein Coding-Agent und ein FAQ-Bot sollten nicht dieselben Annahmen zum Tokenverbrauch zugrunde legen. Beispielbudget für einen Support-Assistenten: | Zugangsweg | Eingabebudget | Ausgabebudget | Modellklasse | Hinweise | Ticket klassifizieren | 600 | 50 | Kostengünstiges/schnelles Modell | Kategorien, Dringlichkeit, Sprache | Belege abrufen | 1,500 | 0 | Embedding/Suche | Keine Generierung erforderlich | Antwort entwerfen | 4,000 | 600 | Leistungsfähiges Modell der mittleren/oberen Klasse | Verwendet ausgewählte Belege | Gesprächsverlauf zusammenfassen | 1,000 | 250 | Kostengünstiges/schnelles Modell | Aktualisiert den gespeicherten Zustand | Eskalationsanalyse | 6,000 | 900 | Leistungsfähiges Modell | Nur für komplexe Fälle Es geht nicht darum, dass diese Zahlen allgemeingültig wären. Sie sind bewusst moderate Ausgangsgrenzen. Entscheidend ist, dass jede Stufe ihren Tokenverbrauch rechtfertigen muss. Eine häufige Stolperfalle: Wenn Sie nur max_tokens für die Ausgabe festlegen, kann Ihre Eingabe trotzdem unbemerkt anwachsen. Ausgabelimits verhindern lange Antworten; sie verhindern nicht, dass zu viele abgerufene Inhalte in den Prompt gepackt werden. ## Kürzen Sie den Kontext vor dem Abruf, nicht danach Viele Systeme rufen Dokumente anhand der neuesten Nutzernachricht ab, nehmen aber trotzdem den vollständigen Gesprächsverlauf in den finalen Prompt auf. Dadurch bleiben alte Abschweifungen, frühere fehlgeschlagene Tool-Aufrufe und überholte Annahmen im Kontext. Pflegen Sie stattdessen einen kompakten Arbeitszustand: ``` { "user_goal": "Get refund for duplicate annual subscription charge", "known_facts": [ "User paid twice on 2025-01-08", "Invoice IDs: inv_1042 and inv_1077", "Account email: user@example.com" ], "constraints": [ "Refund policy allows duplicate-charge refunds within 90 days", "User prefers email follow-up" ], "open_questions": [ "Whether one charge has already been reversed" ], "last_updated_turn": 12 } ``` Ihr finaler Aufruf enthält dann: - Den kompakten Zustand. - Die neueste Nutzernachricht. - Nur relevante abgerufene Richtlinienausschnitte. - Gegebenenfalls die letzten ein oder zwei Gesprächsschritte, wenn ein gleichbleibender Ton wichtig ist. Nehmen Sie nicht blind jede frühere Nachricht auf. Der Chatverlauf ist kein Gedächtnis, sondern ein Transkript. Das Gedächtnis ist der verdichtete Zustand, der nötig ist, um die Aufgabe fortzusetzen. In der Praxis verwende ich drei Ebenen: - Letzte Gesprächsschritte: die letzten 1–4 Gesprächsschritte, je nachdem, wie sensibel die Aufgabe ist. - Fortlaufende Zusammenfassung: beständige Fakten und Entscheidungen. - Externer Informationsabruf: Dokumente, Datenbankdatensätze, Tool-Ausgaben. Das ist meist besser, als das rohe Transkript in den Prompt zu packen, weil das Modell weniger irrelevante Informationen und weniger widersprüchliche Anweisungen sieht. ## Der Informationsabruf sollte selektiv sein, nicht dekorativ Retrieval-Augmented Generation beginnt oft als Qualitätsverbesserung und entwickelt sich zu einer Quelle unnötigen Tokenverbrauchs. Das Fehlermuster ist leicht zu erkennen: top-k ist auf 10 oder 20 gesetzt, die Textblöcke enthalten jeweils 1,000 Tokens, und der finale Prompt enthält einen Stapel nur vage verwandter Dokumente. Ein besserer Informationsabruf ist meist auch ein günstigerer Informationsabruf. Eine praktische Pipeline für den Informationsabruf: ``` def build_context(query, user_state): search_query = rewrite_for_search(query, user_state) candidates = vector_search( query=search_query, top_k=30, filters={"product": user_state["product"]} ) reranked = rerank_cross_encoder( query=search_query, docs=candidates, top_k=6 ) selected = [] token_budget = 1800 for doc in reranked: snippet = extract_relevant_span(doc.text, query=search_query, max_tokens=300) if token_count(selected) + token_count(snippet) <= token_budget: selected.append({ "doc_id": doc.id, "title": doc.title, "text": snippet }) return selected ``` Die wichtigen Details: - Rufen Sie mehr Kandidaten ab, als Sie aufnehmen möchten. - Sortieren Sie die Kandidaten vor der Generierung neu nach Relevanz. - Extrahieren Sie relevante Textpassagen, statt vollständige Textblöcke zu übergeben. - Setzen Sie ein Tokenbudget für abgerufene Inhalte durch. - Behalten Sie Dokument-IDs bei, damit das Modell Belege zitieren oder intern darauf verweisen kann. Die Größe der Textblöcke ist entscheidend. Sind Ihre Textblöcke zu klein, verliert das Modell den Kontext. Sind sie zu groß, bringt jeder Treffer irrelevanten Text mit. Bei Produktdokumentation und Richtlinienseiten beginne ich oft mit etwa 300–600 Tokens pro Textblock und behalte die Überschriften bei. Anschließend passe ich die Größe anhand von Fehlerfällen an. Was passiert tatsächlich, wenn Sie zu viel abgerufenen Kontext in den Prompt packen? Das Modell wird oft unpräziser. Es versucht, verwandte, aber irrelevante Richtlinien miteinander in Einklang zu bringen, übernimmt überholte Vorbehalte oder beantwortet die falsche Version der Frage. Weniger Tokens können die Qualität verbessern, weil sie ablenkende Inhalte entfernen. ## Zusammenfassen bedeutet verantwortungsvolles Verdichten Zusammenfassungen können den Kontext enorm verkürzen, aber nachlässige Zusammenfassungen sind gefährlich. Wenn eine Zusammenfassung eine Vorgabe auslässt, kann Ihr Agent mit großer Überzeugung das Falsche tun. Ich bevorzuge strukturierte Zusammenfassungen gegenüber Fließtext: ``` { "task": "Debug failing OAuth callback in staging", "environment": { "service": "auth-api", "branch": "release-2025-02-14", "runtime": "node 20" }, "confirmed": [ "Callback returns 302 to /login", "Provider sends code and state", "State validation passes" ], "suspected": [ "Session cookie is not persisted after callback" ], "rejected": [ "Provider credentials are invalid", "Redirect URI mismatch" ], "next_steps": [ "Inspect Set-Cookie attributes in staging response", "Compare SameSite and Secure flags with production" ] } ``` Das ist token-effizienter und zuverlässiger als: Der Nutzer untersucht ein OAuth-Problem und hat bereits verschiedene Dinge ausprobiert … Ein guter Zusammenfassungsschritt sollte Folgendes bewahren: - Das Ziel des Nutzers. - Gesicherte Fakten. - Bereits getroffene Entscheidungen. - Vorgaben und Präferenzen. - Fehlgeschlagene Versuche. - Offene Fragen. - IDs, Dateinamen, Zeitstempel und andere exakte Kennungen. Fassen Sie exakte Werte nicht weg, es sei denn, sie sind wirklich irrelevant. „Der Nutzer hat ein Rechnungsproblem“ kostet wenig, ist aber nutzlos. „Doppelte Abbuchung: inv_1042 und inv_1077 am 2025-01-08“ ist die Art der Verdichtung, die Sie anstreben sollten. Bei Agenten, die über längere Zeit laufen, speichere ich auch Versionen der Zusammenfassungen. Wenn das Modell eine schlechte Zusammenfassung erstellt, müssen Sie nachvollziehen können, wann der Zustand vom tatsächlichen Verlauf abgewichen ist. ## Ausschweifende Ausgaben mit Schemas verhindern Ein überraschend großer Teil der Token-Verschwendung entsteht bei der Ausgabe. Im Prompt steht „fasse dich kurz“, aber das Modell schreibt eine Einleitung, Vorbehalte, eine Zusammenfassung und ein Hilfsangebot. Verwenden Sie Schemas für Ausgaben, die maschinell verarbeitet werden. Bitten Sie nicht einfach um „eine JSON-Antwort“; definieren Sie die Struktur und weisen Sie alles andere zurück. Beispiel für einen Klassifizierungsaufruf: ``` { "type": "object", "additionalProperties": false, "required": ["category", "priority", "needs_human", "reason"], "properties": { "category": { "type": "string", "enum": ["billing", "bug", "account", "how_to", "other"] }, "priority": { "type": "string", "enum": ["low", "normal", "high", "urgent"] }, "needs_human": { "type": "boolean" }, "reason": { "type": "string", "maxLength": 160 } } } ``` Geben Sie für Antworten an Nutzer ein Format mit einer festen Obergrenze vor: ``` Write the answer in this structure: - First sentence: direct answer, max 25 words. - Then 2-4 bullets with concrete steps. - Do not include a greeting. - Do not include "let me know if you need anything else." - Stop after the final bullet. ``` Das funktioniert besser als „halte dich kurz“, weil es dem Modell eine Struktur vorgibt. Ein häufiger Fallstrick: Ein niedriger Wert für max_tokens kann nützliche Ausgaben mitten im Gedankengang abschneiden. Ein Schema oder ein eingeschränktes Format reduziert die Ausgabelänge und bewahrt zugleich die Vollständigkeit. Abschneiden ist das letzte Mittel, keine Formatierungsstrategie. ## Stoppsequenzen gezielt einsetzen Stoppsequenzen sind nützlich, wenn die Vervollständigung eine natürliche Grenze hat. Wenn das Modell beispielsweise einen Abschnitt in einem vorlagenbasierten Dokument generiert, können Sie es an der Markierung des nächsten Abschnitts stoppen. ``` { "model": "gpt-5.5", "messages": [ { "role": "user", "content": "Generate only the Risk Summary section for this review..." } ], "max_tokens": 500, "stop": ["\n## Mitigations", "\n## Appendix"] } ``` Stoppsequenzen sind für frei formulierte Antworten eines Assistenten weniger nützlich, weil sie gültige Inhalte abschneiden können. Außerdem verhalten sie sich je nach API und Modellfamilie unterschiedlich, insbesondere bei Tool-Aufrufen oder strukturierten Ausgaben. Betrachten Sie sie als Absicherung von Grenzen, nicht als primäre Verdichtungstechnik. Sinnvolle Anwendungen: - Einen Abschnitt einer bekannten Vorlage generieren. - Verhindern, dass das Modell anschließend noch Beispiele ausgibt. - Bei der Stapelverarbeitung an einem Trennzeichen stoppen. - Ältere Prompts im Vervollständigungsstil begrenzen. Riskante Anwendungen: - An gängigen Satzzeichen stoppen. - Bei Wörtern stoppen, die in normalen Antworten vorkommen können. - Stoppsequenzen anstelle eines geeigneten Ausgabeschemas verwenden. - Bei Claude, GPT, Gemini und Gateways für offene Modelle identisches Verhalten voraussetzen. ## Aufgaben auf günstigere Modelle verteilen Nicht jeder Schritt benötigt Ihr leistungsfähigstes Modell. In Produktionssystemen leite ich Teilaufgaben häufig an kleinere oder günstigere Modelle weiter: | Teilaufgabe | Typische Anforderung | Geeignete Lösung | Spracherkennung | Einfache Klassifizierung | Kleines/günstiges Modell | Ticket-Kategorie | Strukturierte Ausgabe von Labels | Kleines oder mittelgroßes Modell | Umformulierung von Suchanfragen | Kurze Umwandlung | Kleines oder mittelgroßes Modell | Neubewertung der Dokumentrangfolge | Spezialisierter Reranker oder kleines Modell | Nach Möglichkeit nicht generativ | Endgültige Antwort | Schlussfolgern und Tonalität | Leistungsfähigeres Modell | Ausnahme von einer Richtlinie | Nuancen und Risiko | Leistungsfähigstes Modell Hier ist der Zugriff auf mehrere Modelle im Betrieb nützlich. Vielleicht möchten Sie Sonnet 4.6 für die meisten Schreibaufgaben von Agenten einsetzen, GPT-5.5 für einen anspruchsvollen Schlussfolgerungsprozess, Gemini 3 für bestimmte multimodale Workflows oder Workflows mit langem Kontext, Fable 5, wenn das Kontextfenster von 1M tatsächlich benötigt wird, und offene Modelle wie Llama, Qwen, DeepSeek, MiniMax oder Kimi für kontrollierte interne Aufgaben. Aus technischer Sicht geht es um Routing, nicht um Markentreue. Die Einschränkung: Der zusätzliche Aufwand für die Orchestrierung ist real. Jeder weitere Modellaufruf erhöht die Latenz, schafft neue Fehlermöglichkeiten und macht Protokollierung und Evaluierung komplexer. Wenn ein günstiger Klassifikator 300 Token spart, aber 600 ms und einen weiteren Wiederholungspfad hinzufügt, lohnt er sich möglicherweise nicht. Ein Muster, das ich gerne verwende: ``` if route == "simple_faq": model = "haiku-4.5" elif route == "standard_support": model = "sonnet-4.6" elif route == "legal_or_financial_exception": model = "opus-4.8" else: model = "sonnet-4.6" ``` Die konkreten Namen werden sich ändern. Der Grundsatz sollte bleiben: Verwenden Sie das günstigste Modell, das die Qualitätsanforderungen der Aufgabe zuverlässig erfüllt. ## Eingabe- und Ausgabetoken ehrlich messen Token-Optimierung scheitert, wenn Teams nur die durchschnittlichen Kosten pro Anfrage betrachten. Sie benötigen Verteilungen, aufgeschlüsselt nach Route und Verarbeitungsschritt. Erfassen Sie mindestens: - Eingabetoken nach Prompt-Abschnitt. - Ausgabetoken. - Anzahl abgerufener Dokumente und Token für den Abruf. - Modellname und -version. - Latenzperzentile. - Cache-Trefferrate, wenn Prompt- oder Kontext-Caching verwendet wird. - Anzahl der Wiederholungsversuche. - Für Nutzer erkennbare Qualitätssignale. - Raten für die Weiterleitung an Menschen oder für Korrekturen. Ein nützliches Dashboard zeigt p50, p90 und p99. Token-Probleme treten häufig an den Rändern der Verteilung auf. Beispiel für eine Protokollzeile: ``` { "route": "support.draft_answer", "model": "sonnet-4.6", "input_tokens": 3820, "output_tokens": 514, "retrieved_docs": 4, "retrieval_tokens": 1320, "latency_ms": 3100, "cache_hit": false, "quality": { "user_thumb": "up", "human_edited": false } } ``` Seien Sie vorsichtig mit Aussagen wie „Wir haben die Token-Anzahl um 40 % reduziert“. Gab es mehr Wiederholungsversuche? Mehr Weiterleitungen an Menschen? Haben Nutzer mehr Rückfragen gestellt, weil die Antworten zu knapp wurden? Hat das günstigere Modell häufiger ungültiges JSON erzeugt und dadurch Korrekturaufrufe erzwungen? Die ehrliche Kennzahl ist nicht die Anzahl der Token pro Aufruf. Es ist die Anzahl der Token pro erfolgreich abgeschlossener Aufgabe. ## Langer Kontext ist kein Freibrief für Nachlässigkeit Große Kontextfenster sind wirklich nützlich. Die Kontextklasse von 1M bei Fable 5, Geminis Stärken bei langem Kontext und die Modi für langen Kontext in führenden Modellen ermöglichen Workflows, die vor einigen Jahren noch umständlich waren: repositoryweite Codeanalyse, Prüfung umfangreicher Dokumente, mehrstündige Transkripte und umfangreiche Rechercheunterlagen. Langer Kontext ist jedoch eine Fähigkeit, keine Standardarchitektur. Aufrufe mit langem Kontext können sinnvoll sein, wenn: - Die Antwort von vielen weit auseinanderliegenden Teilen der Eingabe abhängt. - Beim Abruf Zusammenhänge zwischen Dokumenten übersehen würden. - Die Aufgabe explorativ ist und Sie noch nicht wissen, was relevant ist. - Der Verlust eines Details teurer ist als das Lesen zusätzlicher Inhalte. Sie sind meist verschwenderisch, wenn: - Der Nutzer eine eng umrissene Sachfrage stellt. - Einige wenige Quellenausschnitte ausreichen. - Der Kontext doppelte oder veraltete Informationen enthält. - Das Modell als Datenbankfilter verwendet wird. Ein gängiges Muster besteht darin, langen Kontext für Offline-Analysen zu verwenden und kompakte Artefakte für die Online-Verarbeitung zu erzeugen. Analysieren Sie beispielsweise einmal den gesamten Richtlinienbestand und erstellen Sie anschließend eine strukturierte Übersicht der Richtlinien, Embeddings, Zusammenfassungen und Testfälle. Der Assistent sollte zur Laufzeit nicht für jedes Ticket den gesamten Bestand erneut lesen. ## Ein praktischer Optimierungsworkflow Wenn ich ein LLM-System mit hohem Token-Verbrauch übernehme, gehe ich normalerweise in dieser Reihenfolge vor: - Zuerst instrumentieren Erfassen Sie den Token-Verbrauch nach Abschnitt. Optimieren Sie nicht im Blindflug. - Abrufkontext begrenzen Legen Sie ein festes Token-Budget für den Abruf fest. Bewerten Sie die Rangfolge neu und extrahieren Sie relevante Textpassagen. - Den vollständigen Gesprächsverlauf durch einen Zustand ersetzen Behalten Sie die jüngsten Gesprächsbeiträge sowie einen strukturierten Speicher bei. - Ausgaben begrenzen Verwenden Sie Schemas für maschinell verarbeitete Ausgaben und explizite Formate für Ausgaben an Nutzer. - Teilaufgaben gezielt weiterleiten Verlagern Sie Klassifizierung, Umformulierung und Zusammenfassung auf günstigere Modelle, sofern diese zuverlässig arbeiten. - Qualität auf Aufgabenebene bewerten Vergleichen Sie erfolgreiche Problemlösungen, nicht nur die Kosten pro Aufruf. - Ausreißer im Blick behalten Untersuchen Sie Token-Spitzen bei p95 und p99. Sie weisen oft auf fehlerhafte Informationsabfragen oder einen unkontrolliert wachsenden Verlauf hin. Hier ist eine einfache Schutzmaßnahme, die ich in Diensten eingesetzt habe: ``` TOKEN_LIMITS = { "support.classify": {"input": 800, "output": 80}, "support.retrieve": {"input": 500, "output": 0}, "support.draft": {"input": 4500, "output": 700}, "support.summarize": {"input": 1800, "output": 300}, } def assert_token_budget(route, prompt_sections, max_output_tokens): input_tokens = { name: count_tokens(text) for name, text in prompt_sections.items() } total_input = sum(input_tokens.values()) limits = TOKEN_LIMITS[route] if total_input > limits["input"]: raise TokenBudgetError(route, total_input, input_tokens) if max_output_tokens > limits["output"]: raise TokenBudgetError(route, max_output_tokens, {"output": max_output_tokens}) ``` Ein frühzeitiger Abbruch ist besser, als eine Woche später festzustellen, dass eine einzige fehlerhafte Suchabfrage Ihr Budget für irrelevante PDFs aufgebraucht hat. ## Praktische Empfehlungen - Die Token-Reduktion sollte mit Transparenz beginnen: Protokollieren Sie Eingabe- und Ausgabe-Tokens nach Prompt-Abschnitt, Route und Modell. - Gezielte Informationsabfragen sind besser als das wahllose Befüllen des Kontexts: Sortieren Sie die Ergebnisse neu, extrahieren Sie relevante Textpassagen und setzen Sie ein Kontextbudget durch. - Zusammenfassungen sollten einen strukturierten Zustand abbilden, statt aus vagen Formulierungen zu bestehen. Bewahren Sie exakte Fakten, IDs, Vorgaben und fehlgeschlagene Versuche. - Ausgabeschemata reduzieren ausschweifende Antworten zuverlässiger als das bloße Senken von max_tokens. - Stoppsequenzen sind nützliche Begrenzungen, ersetzen aber keine strukturierten Ausgaben. - Leiten Sie einfache Teilaufgaben nur dann an günstigere Modelle weiter, wenn die zusätzliche Latenz und die möglichen Fehler die Einsparung rechtfertigen. - Bewerten Sie Einsparungen anhand der Tokens pro erfolgreich abgeschlossener Aufgabe, nicht anhand der Tokens pro einzelnem Aufruf. - Modelle mit großem Kontextfenster sind leistungsfähig, machen Informationsarchitektur aber nicht überflüssig. [Inferenz](/de/blog/tag/inference/)[Prompts](/de/blog/tag/prompts/)[Modelle](/de/blog/tag/models/)[API](/de/blog/tag/api/) A [AI Prime Tech](https://aiprimetech.io/de/) AI Prime Tech veröffentlicht diesen Blog. Die Artikel werden mit KI-Unterstützung verfasst; prüfen Sie versionsspezifische Angaben wie Modell-IDs, Preise und Limits anhand der offiziellen Dokumentation, bevor Sie sich darauf verlassen. Günstigeren Zugang zur Claude API erhalten Ein API-Schlüssel für Claude Opus 5.5, Sonnet 5, Haiku 4.5 und Fable 5.1 sowie GPT-6 Modelle. Nutzungsbasierte Abrechnung, kein Abonnement. [API-Schlüssel erhalten →](/register) AI Prime Tech ist ein unabhängiges API-Gateway eines Drittanbieters. Claude™ und Anthropic® sind Marken von Anthropic, PBC. Eine Verbindung oder Unterstützung wird nicht impliziert.