Abrechnung
Guthaben kaufen, Auto-Aufladung einrichten, Zahlungsmethoden hinterlegen und API-Ausgaben verfolgen.
Die Platform API verwendet ein Prepaid-Guthaben-Modell. Sie kaufen Guthaben im Voraus, und jede API-Anfrage zieht den entsprechenden Betrag ab. Anfragen werden mit dem Fehler 402 Payment Required abgelehnt, wenn das Guthaben aufgebraucht ist.
Die gesamte Abrechnung wird im Abrechnungs-Dashboard der Platform API verwaltet.
Guthaben
Guthaben kaufen
Gehen Sie zu Abrechnung → Guthaben, wählen Sie ein Guthabenpaket oder geben Sie einen individuellen Betrag (5 €–1.000 €) ein. Die Zahlung wird sofort über Stripe verarbeitet.
| Paket | Guthaben |
|---|---|
| 10 € | 10 € Guthaben |
| 25 € | 25 € Guthaben (beliebt) |
| 50 € | 50 € Guthaben |
| 100 € | 100 € Guthaben |
| Individuell | 5 €–1.000 € |
Mit der Bestätigung eines Kaufs stimmen Sie zu, dass digitale Inhalte sofort bereitgestellt werden, und verzichten auf Ihr Widerrufsrecht. Verbrauchtes Guthaben wird nicht erstattet.
Guthabenstand
Ihr aktuelles Guthaben wird oben im Tab „Guthaben" angezeigt. Gekauftes Guthaben verfällt 3 Jahre nach dem Kaufdatum (gemäß §195 BGB) und wird zuerst vom ältesten Guthaben abgezogen (FIFO).
Wie Guthaben abgezogen wird
Jede erfolgreiche API-Anfrage zieht Guthaben ab, basierend auf:
- Text Completion — Preis pro Eingabe-Token und pro Ausgabe-Token
- Embeddings — Preis pro Eingabe-Token
- Bildgenerierung — Preis pro Bild, abhängig von Qualität und Größe
Die genauen Token- und Bildpreise hängen vom Modell ab. Unter Dashboard → Modelle finden Sie die Preise pro Modell.
Was eine Anfrage gekostet hat, direkt in der Antwort
Jede Text-Completion-Antwort nennt ihren eigenen Preis. /v2/chat/completions und
/v2/responses liefern ihn auf usage:
"usage": {
"prompt_tokens": 291339,
"completion_tokens": 5,
"total_tokens": 291344,
"prompt_tokens_details": { "cached_tokens": 0, "cache_write_tokens": 291336 },
"pricing": {
"tier": "long_context",
"currency": "EUR",
"long_context_threshold_input_tokens": 272000,
"input_per_1m": 0.44,
"output_per_1m": 2.0,
"cache_read_per_1m": 0.05,
"cache_write_per_1m": 0.56
},
"cost": 0.16315948
}
cost ist der Betrag, der Ihrem Guthaben abgezogen wurde, in EUR. pricing sind die Sätze,
aus denen er entstanden ist — Ihre Sätze, nach dem Preisfaktor Ihrer Organisation, keine
Katalogwerte. Beides stammt aus derselben Buchung, die Sie belastet hat, kann Ihrer Rechnung
also nicht widersprechen.
Bei einer gestreamten Anfrage steht der Block im Usage-Chunk; Sie brauchen dafür
stream_options: { "include_usage": true }.
Zwei Felder fehlen, wenn sie nicht zutreffen: cache_write_1h_per_1m bei Modellen ohne
Cache-Schreibpreis und long_context_threshold_input_tokens bei Modellen mit einem einzigen
Preis über alle Kontextlängen. Der ganze Block fehlt bei Modellen mit eigenem Provider-Key —
dafür haben wir Ihnen nichts berechnet.
Langkontext-Preise
Einige Modelle werden teurer, sobald die Eingabe einer einzelnen Anfrage einen Schwellenwert überschreitet — meist 272.000 Tokens bei OpenAI-Modellen und 200.000 bei Google-Modellen. Darüber wird die gesamte Anfrage neu bepreist: Eingabe, Cache-Zugriffe, Cache-Schreibvorgänge und Ausgabe laufen über die Langkontext-Sätze, die in der Regel doppelt so hoch sind.
Der Schwellenwert gilt pro Anfrage, nicht pro Konversation. Zwanzig Anfragen mit je 15.000 Tokens werden alle zum kurzen Tarif abgerechnet, eine Anfrage mit 300.000 Tokens nicht.
usage.pricing.tier sagt Ihnen bei jeder Anfrage, welchen der beiden Tarife Sie bezahlt
haben. Schwellenwerte und Sätze je Modell stehen unter
Modelle & Preise und unter
Dashboard → Modelle; ein Strich bedeutet dort, dass das
Modell keinen Langkontext-Tarif hat.
Prompt-Caching
`ttl: "1h"` wird auf `/v2/chat/completions` und `/v2/responses` NICHT unterstützt
Auf den beiden OpenAI-förmigen Endpoints ist der Ein-Stunden-Cache-Point nicht verfügbar. Jeder Cache, den sie schreiben, lebt fünf Minuten — Anthropics Standardwert.
"ttl": "1h" wird weiterhin akzeptiert statt abgelehnt, damit bestehende Integrationen
weiterlaufen und Sie das Feld nicht entfernen müssen — es wird aber nicht angewandt.
Der Breakpoint wird mit der Fünf-Minuten-Lebensdauer gesetzt, zum Fünf-Minuten-Tarif für
Cache-Writes abgerechnet (125 % des Eingabetarifs, nicht 200 % — es wird also nichts zu
viel berechnet), und die Antwort weist es mit der Warnung marker_ttl_unsupported in
prompt_cache aus. Ihr Cache läuft lediglich früher ab als von Ihnen gewünscht.
Eine Folgewirkung: Die Reihenfolge-Regel, die Anthropics eigene API auf gemischte
1h/5m-Anfragen anwendet, gilt auf diesen beiden nicht — alle Breakpoints haben
ohnehin dieselbe Lebensdauer, eine Anfrage, die Anthropic mit 400 ablehnen würde, wird
hier also akzeptiert.
/anthropic/v1/messages ist die Ausnahme und bleibt unverändert. Dort ist
cache_control Anthropics eigenes Feld und keine Erweiterung von uns: ttl: "1h" wird
beachtet, das Mischen mit 5m funktioniert, die Reihenfolge-Regel (1h vor 5m) wird
erzwungen, und ein Ein-Stunden-Write wird mit 200 % des Eingabetarifs abgerechnet.
Für Anthropic-Modelle können Sie ein unveränderliches Präfix Ihrer Anfrage mit
cache_control markieren, damit es beim Anbieter zwischengespeichert und von späteren
Anfragen wiederverwendet wird. Setzen Sie die Markierung auf das letzte Element, das noch
zum Präfix gehören soll — eine system-Nachricht, einen Text-Inhaltsteil oder eine
Tool-Definition:
{
"model": "claude-sonnet-5",
"messages": [
{
"role": "system",
"content": [
{
"type": "text",
"text": "<lange, unveränderliche Anweisungen>",
"cache_control": { "type": "ephemeral" }
}
]
},
{ "role": "user", "content": "Was hat sich heute geändert?" }
]
}
Jeden Breakpoint setzen Sie selbst. Wir ergänzen keine eigenen — eine Anfrage ohne
cache_control wird also gar nicht gecacht. Ein Cache-Write kostet mehr als ein ungecachter
Read, und nur Ihr Zugriffsmuster sagt, ob er sich lohnt.
Ein Cache-Write kostet 125 % des Eingabetarifs bei 5m und 200 % bei 1h — und nur
/anthropic/v1/messages erreicht 1h (siehe oben).
Maximal vier Breakpoints pro Anfrage. Bei mehr werden die letzten vier behalten — sie machen Ihre nächste Anfrage günstig — und die Antwort weist das aus (siehe Was mit Ihren Markierungen passiert). Das Feld wird von Nicht-Anthropic-Modellen ignoriert und kann daher beim Modellwechsel stehen bleiben.
Wo ein Breakpoint landet
Ein Breakpoint cacht alles bis einschließlich des markierten Elements. Wo Sie ihn setzen, entscheidet also, was wiederverwendet wird:
- An einem Content-Part liegt die Grenze an diesem Part. Das ist die übliche Form — ein langes, stabiles Dokument als erster Part, Ihre wechselnde Frage als zweiter, Markierung am ersten — und sie wird exakt umgesetzt: das Dokument wird gecacht, die Frage nicht.
- An einer Nachricht liegt die Grenze am Ende dieser Nachricht.
- An einer Tool-Definition wird der Tool-Block gecacht. Der Breakpoint wird auf Ihre
system-Nachricht gesetzt — Anthropic ordnettools → system → messages, ein Präfix, das dort endet, erfasst also den Tool-Block davor. Dafür braucht es einesystem-Nachricht in derselben Anfrage; ohne sie wird die Markierung verworfen und ausgewiesen, denn der einzige andere Platz wäre Ihr erster User-Turn, der sich bei jeder Anfrage ändert.
Die einzige Stelle, an der die Grenze nicht exakt sein kann, ist eine System-Nachricht mit
mehreren Blöcken: sie wird als ein einzelner Block gesendet, eine Markierung an einem
anderen als dem letzten Block wird also auf den gesamten System-Prompt ausgeweitet. Wenn
Text nach Ihrer Markierung sich zwischen Anfragen ändert, wird der Cache nicht gelesen —
setzen Sie diesen Text stattdessen in eine user-Nachricht. Die Antwort weist das aus.
Was mit Ihren Markierungen passiert
Wenn wir eine Markierung nicht genau wie geschrieben umsetzen können, sagt die Antwort das in
prompt_cache, statt es Ihnen erst auf der Rechnung zu überlassen:
{
"prompt_cache": {
"cache_write_tokens": { "5m": 11219, "1h": 0 },
"warnings": [
{
"code": "marker_dropped_no_anchor",
"message": "1 cache_control breakpoint(s) on tool definitions could not be placed…"
}
]
}
}
cache_write_tokens ist die vom Anbieter gemeldete Aufteilung nach TTL — die beiden Zahlen,
die eine Cache-Write-Gebühr erklären. Das Feld fehlt vollständig, wenn es nichts zu melden
gibt; eine Anfrage ohne cache_control bleibt also unverändert.
code | was passiert ist |
|---|---|
markers_ignored_disabled | Die Cache-Tarif-Abrechnung ist für Ihre Organisation nicht freigeschaltet. Bei /v2/chat/completions und /v2/responses wurde gar nichts gecacht; bei /anthropic/v1/messages wurden Ihre Breakpoints beachtet, aber jedes Eingabetoken wird zum vollen Prompt-Tarif abgerechnet und ein Cache-Write nicht separat berechnet. Die Meldung sagt, welcher Fall zutrifft. |
markers_ignored_model | Dieses Modell nimmt keine Breakpoints in der Anfrage an. Ebenso: nichts gecacht, nichts berechnet. |
breakpoint_limit_exceeded | Mehr als vier Breakpoints; die frühesten wurden verworfen. |
marker_dropped_uncacheable | Der markierte Block kann nicht als Cache-Grenze dienen (Reasoning-Block, leerer Text, Dokument ohne Bild). Ihn zu senden hätte die gesamte Anfrage fehlschlagen lassen. |
marker_dropped_no_anchor | Eine Tool-Markierung wurde verworfen, weil die Anfrage keine system-Nachricht hat, die sie tragen könnte. Fügen Sie eine hinzu, um den Tool-Block zu cachen. |
marker_ttl_unsupported | Sie haben ttl: "1h" auf /v2/chat/completions oder /v2/responses angefordert, die es nicht unterstützen. Der Breakpoint wurde mit der Fünf-Minuten-Lebensdauer gesetzt und zum Fünf-Minuten-Tarif abgerechnet. |
marker_ttl_upgraded | Eine Tool-Markierung und Ihre erste Nachricht verlangten unterschiedliche TTLs und wurden bei der längeren zusammengeführt — dieser Block wird damit zu 200 % des Eingabetarifs abgerechnet. Nur auf /anthropic/v1/messages erreichbar; geben Sie beiden dieselbe ttl. |
marker_boundary_widened | Eine Markierung an einem nicht-letzten system-Block wurde auf den gesamten System-Prompt ausgeweitet (siehe oben). |
marker_dropped_structured_output | Eine Markierung an einer Tool-Definition wurde verworfen: diese Antwort wurde ohne Tools erzeugt, es gab also keinen Tool-Block zum Cachen. |
Bei /anthropic/v1/messages wird die Aufteilung nach TTL stattdessen in Anthropics eigenem
Feld zurückgegeben — usage.cache_creation.ephemeral_5m_input_tokens und …_1h_input_tokens
— und prompt_cache enthält nur die Warnungen, da Anthropics eigene API kein Feld dafür hat.
Die Antwort weist das Ergebnis aus — in usage.prompt_tokens_details bei
/v2/chat/completions und in usage.input_tokens_details bei /v2/responses:
| Feld | Bedeutung | Preis |
|---|---|---|
cached_tokens | aus dem Cache geliefert | der Cache-Lese-Tarif des Modells, standardmäßig 10 % des Eingabetarifs |
cache_write_tokens | in den Cache geschrieben | der Cache-Schreib-Tarif des Modells, standardmäßig 125 % des Eingabetarifs (200 % bei ttl: "1h") |
Beide Tarife unterscheiden sich je Modell, und manche Modelle berechnen für einen Write gar
nichts. Die genauen Zahlen stehen unter Modelle & Preise — oder in
Ihrer eigenen Antwort unter usage.pricing, das die Tarife dieser Anfrage nennt.
prompt_tokens bzw. input_tokens ist die Gesamtsumme: die beiden Felder oben sind
Teilmengen davon, keine Ergänzungen. Caching spart nur Geld, wenn das Präfix erneut gesendet
wird — ein Cache-Write kostet mehr als ein ungecachter Read. Markieren Sie also ein Präfix,
das Sie wieder senden, keine einmalige Anfrage.
Prompt-Caching wird pro Organisation freigeschaltet; bis dahin wird jedes Eingabetoken — gecacht oder nicht — zum vollen Eingabetarif abgerechnet. Was die Freischaltung bewirkt, hängt vom Endpoint ab:
- Bei
/v2/chat/completionsund/v2/responseswirdcache_controlakzeptiert und ignoriert, undcache_write_tokensfehlt in der Antwort.prompt_cache.warningssagt das ausdrücklich (markers_ignored_disabled), statt die Markierungen stillschweigend verschwinden zu lassen. - Bei
/anthropic/v1/messageswurden Breakpoints schon immer beachtet und werden es weiterhin;cache_read_input_tokens/cache_creation_input_tokenswerden wie gewohnt ausgewiesen. Es ändert sich nur der Tarif, zu dem abgerechnet wird.ttl: "1h"wird hier unabhängig von der Freischaltung beachtet, wie schon immer.
Wenden Sie sich an den Support, um es für Ihre Organisation aktivieren zu lassen.
Mistral-Modelle: prompt_cache_key
Mistral cacht Präfixe automatisch. Es gibt keine Breakpoints zu setzen, und
cache_control bewirkt bei einem Mistral-Modell nichts. Was eine Mistral-Anfrage stattdessen
braucht, ist prompt_cache_key — eine stabile, undurchsichtige Zeichenkette, die die
Cache-Spur der Anfrage benennt:
{
"model": "mistral-small-4",
"prompt_cache_key": "conversation-42",
"messages": [{ "role": "user", "content": "Was hat sich heute geändert?" }]
}
Senden Sie denselben Wert für jede Anfrage, die sich ein Präfix teilt — eine Konversation,
eine Sitzung, ein Workflow-Lauf. Anfragen mit demselben Key werden auf denselben Cache-Knoten
geleitet, und genau das lässt die zweite Anfrage das Präfix der ersten wiederfinden. Das Feld
wird auf /v2/chat/completions und /v2/responses akzeptiert; /v2/responses gibt es in der
Antwort zurück.
Drei Konsequenzen, die Sie vor der Integration kennen sollten:
- Es gibt nichts zu aktivieren und nichts auszugeben. Anders als bei einem Anthropic-Breakpoint berechnet Mistral keinen Aufschlag für das Schreiben in den Cache: ein gecachter Lesevorgang kostet 10% des Input-Tarifs, ein Fehlschlag schlicht den normalen Input-Tarif. Eine Spur, die nie wieder gelesen wird, kostet exakt so viel wie die Anfrage ohnehin gekostet hätte. Deshalb setzen wir immer einen Key — Ihren, wenn Sie einen senden, sonst Ihren Workspace — statt Sie um eine Aktivierung zu bitten.
- Ein Treffer ist eine Wahrscheinlichkeit, keine Zusage. Mistrals eigene Dokumentation
sagt, der Key erhöhe die Trefferchance, garantiere sie aber nicht — Messungen bestätigen
das: bei einem wiederholten Präfix sahen wir bei manchen Mistral-Modellen nahezu 100%, bei
anderen deutlich unter die Hälfte, und kein Anfrageabstand war kurz genug, um das zu
ändern. Betrachten Sie die Ersparnis als Rabatt, den Sie oft bekommen, nicht als Tarif, mit
dem Sie kalkulieren können. Mistral cacht zudem in 64-Token-Blöcken,
cached_tokensist daher immer ein Vielfaches von 64, und ein kurzes Präfix ist unter Umständen gar nicht cachebar. - Ihr Wert wird Ihrem Workspace zugeordnet. Wir hashen ihn zusammen mit Ihrer
Workspace-ID, bevor er uns verlässt. Zwei Tenants, die beide
"default"senden, teilen sich also nie eine Spur, und Ihr Key kann nicht auf den Cache eines anderen zielen. Er ist ein Routing-Hinweis, keine Isolationsgrenze — legen Sie keine Geheimnisse oder personenbezogenen Daten hinein.
/anthropic/v1/messages nimmt keinen prompt_cache_key entgegen, da Anthropics Wire-Format
kein solches Feld kennt. Ein über diesen Endpunkt bedientes Mistral-Modell nutzt Ihren
Workspace als Spur.
Auto-Aufladung
Die Auto-Aufladung fügt Ihrem Workspace automatisch Guthaben hinzu, wenn Ihr Stand unter einen Schwellenwert fällt, damit Ihre Integrationen ohne manuelle Eingriffe weiterlaufen.
Auto-Aufladung einrichten
Zahlungsmethode hinzufügen
Öffnen Sie Abrechnung → Zahlungsmethoden und klicken Sie auf Verwalten, um im Stripe-Billing-Portal eine Kredit- oder Debitkarte zu hinterlegen. Stripe speichert Ihre Kartendaten sicher.
Auto-Aufladung aktivieren
Aktivieren Sie im Tab Abrechnung → Guthaben die Auto-Aufladung und konfigurieren Sie:
| Einstellung | Beschreibung | Standard |
|---|---|---|
| Aufladeschwelle | Guthabenstand, der eine Aufladung auslöst | 5 € |
| Aufladebetrag | Betrag, der jedes Mal aufgeladen wird | 5 € |
Wenn Ihr Guthaben unter die Schwelle fällt, wird Ihre Karte automatisch mit dem Aufladebetrag belastet.
Nach drei aufeinanderfolgenden fehlgeschlagenen Auto-Aufladungen wird die automatische Abrechnung pausiert. Sie erhalten eine E-Mail-Benachrichtigung. Hinterlegen Sie eine gültige Zahlungsmethode und aktivieren Sie die Auto-Aufladung erneut.
Zahlungsmethoden
Öffnen Sie Abrechnung → Zahlungsmethoden und klicken Sie auf Verwalten, um im Stripe-Billing-Portal Karten hinzuzufügen oder zu entfernen. Sie können mehrere Karten hinterlegen; die Standardkarte wird für Käufe und Auto-Aufladungen verwendet.
Zahlungen werden über Stripe abgewickelt. DeutschlandGPT speichert keine Kartenrohdaten.
Monatliches Ausgabenlimit
Um Ihre gesamten API-Ausgaben in einem Kalendermonat zu begrenzen, setzen Sie im Tab Abrechnung → Guthaben ein monatliches Ausgabenlimit.
Sobald das Limit erreicht ist, geben alle API-Anfragen 402 Payment Required zurück, bis der nächste Monat beginnt oder Sie das Limit erhöhen. Das Limit wird zu Beginn jedes Kalendermonats zurückgesetzt.
Mit der Einstellung Kein Limit sind unbegrenzte Ausgaben möglich (abhängig vom verfügbaren Guthaben).
Nutzungsübersicht
Abrechnung → Guthaben zeigt Ihr aktuelles Guthaben, die Ausgaben des aktuellen Monats und ein Diagramm der täglichen Nutzung.
Dashboard → Nutzung schlüsselt die Ausgaben nach API-Schlüssel, Modell und Zeitraum auf — nützlich, um zu erkennen, welche Integrationen das meiste Guthaben verbrauchen.
Benachrichtigungen
E-Mail-Benachrichtigungen können unter Abrechnung → Benachrichtigungen konfiguriert werden:
| Benachrichtigung | Auslöser |
|---|---|
| Guthaben niedrig | Guthaben fällt unter einen konfigurierbaren Schwellenwert (Standard: 1 €) |
| Guthaben aufgebraucht | Guthaben erreicht null |
| Monatslimit-Warnung | Ausgaben erreichen 80 % des Monatslimits (konfigurierbar) |
| Monatslimit erreicht | Ausgaben erreichen 100 % des Monatslimits |
| Auto-Aufladung deaktiviert | Guthaben unter Schwelle, aber Auto-Aufladung ist deaktiviert |
Jeder Benachrichtigungstyp hat eine 24-Stunden-Abklingzeit, um wiederholte E-Mails zu vermeiden.
Rechnungen
Stripe-Rechnungen für alle Guthabenkäufe sind im Stripe-Billing-Portal verfügbar — öffnen Sie es über Abrechnung → Zahlungsmethoden → Verwalten. Rechnungen werden gemäß §147 AO 10 Jahre aufbewahrt.