Abrechnung

Anfragen an die Platform API werden aus Ihrem Workspace bezahlt. Die meisten Workspaces sind vorausbezahlt: Sie kaufen Guthaben, und jede Anfrage zieht ihre Kosten davon ab. Manche Organisationen werden stattdessen per Rechnung abgerechnet, siehe Abrechnung per Rechnung.

Alles Nötige finden Sie in der Platform API unter Abrechnung und Budgets & Limits. Für Änderungen brauchen Sie die Rollenberechtigung Guthaben und Ausgabenlimits verwalten.

Dasselbe Guthaben bezahlt auch den Pay-as-you-go-Chat und Workflows.

Guthaben

Guthaben kaufen

Klicken Sie im Tab Guthaben der Abrechnung auf Guthaben kaufen und wählen Sie ein Paket oder unter Benutzerdefinierter Betrag einen Betrag zwischen 5 € und 1.000 €. Als Standardzahlungsmethode brauchen Sie eine Kredit- oder Debitkarte. Andere Zahlungsmethoden lassen sich für Guthabenkäufe nicht belasten.

Alle Preise verstehen sich zzgl. MwSt., die beim Bezahlen hinzukommt.

Guthabenstand

Der Tab Guthaben zeigt das Verfügbare Gesamtguthaben, die Geschätzte Reichweite in Tagen beim aktuellen Verbrauch und Ihre Ausgaben unter Letzte 7 Tage und Letzte 30 Tage samt Tagesdurchschnitt.

Gekauftes Guthaben läuft 3 Jahre nach dem Kaufdatum ab und wird in der Reihenfolge des Kaufs verbraucht, das älteste zuerst. Der Guthabenverlauf listet jeden Kauf mit Restbetrag und Ablaufdatum. Über Rechnung herunterladen erhalten Sie die Rechnung zu einem Kauf.

Wie Guthaben abgezogen wird

Jede erfolgreiche Anfrage zieht Guthaben ab, je nachdem, was sie verbraucht hat:

• Textgenerierung: pro Eingabe- und Ausgabe-Token, mit eigenen Sätzen für gecachte Eingaben.
• Embeddings: pro Eingabe-Token.
• Bilder: pro Bild, abhängig von Qualität und Größe.
• Video, Avatar-Video, Sprachausgabe, Transkription und Musik: in der Einheit, in der das Modell bepreist ist, zum Beispiel pro Minute erzeugter Musik.
• Websuche: ein fester Betrag pro Anfrage.

Die Sätze hängen vom Modell ab. Sie stehen in der Platform API unter Modelle & Preise und öffentlich unter Modelle & Preise.

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, denn 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

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, denn Anthropic ordnet tools → system → messages. Ein Präfix, das dort endet, erfasst also den Tool-Block davor. Dafür braucht es eine system-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.

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, und zwar in usage.prompt_tokens_details bei /v2/chat/completions und in usage.input_tokens_details bei /v2/responses:

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, denn ein Cache-Write kostet mehr als ein ungecachter Read. Markieren Sie also ein Präfix, das Sie wieder senden, keine einmalige Anfrage.

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_tokens ist 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.

Automatisches Aufladen

Automatisches Aufladen füllt Ihr Guthaben auf, sobald es unter einen Schwellenwert fällt. So laufen Ihre Integrationen ohne Unterbrechung weiter.

Automatisches Aufladen einrichten

Zahlungsmethoden

Im Tab Zahlungsmethoden öffnet Zahlungsmethoden verwalten das Abrechnungsportal unseres Zahlungsanbieters. Dort fügen Sie Karten hinzu, entfernen sie und wählen die Standardkarte, die für Käufe und automatisches Aufladen genutzt wird.

Kartendaten speichert der Zahlungsanbieter Stripe. DeutschlandGPT speichert sie nie.

Einrichtung abschließen

Der Tab Guthaben zeigt Einrichtung abschließen mit drei Schritten: Zahlungsmethode hinterlegen, Guthaben aufladen und Automatisches Aufladen aktivieren. Jeder Schritt hat einen eigenen Button, und der Kasten verschwindet, sobald alle drei erledigt sind.

Monatliches Ausgabenlimit

Um die Gesamtausgaben des Workspace pro Kalendermonat zu begrenzen, öffnen Sie Budgets & Limits und setzen das Feld Monatliches Limit (€). Bleibt das Feld leer, gilt kein Limit.

Ist das Limit erreicht, liefern Anfragen 402 Payment Required, bis der nächste Monat beginnt oder Sie das Limit erhöhen.

Dieselbe Seite verweist unter Weitere Limits auf die übrigen Grenzen: das Chat-Budget je Mitarbeiter, die API-Schlüssel-Limits am einzelnen Schlüssel und die Workflow-Budgets.

Abrechnung per Rechnung

Manche Organisationen werden per Rechnung abgerechnet statt über vorausbezahltes Guthaben. Ihre Abrechnungsseite zeigt Abrechnung per Rechnung, aufzuladen gibt es nichts. Der Verbrauch wird je nach Vereinbarung monatlich, vierteljährlich oder jährlich in Rechnung gestellt. Die Rechnungen über diese Nutzung stehen im Tab Rechnungen der Abrechnung, sichtbar für alle mit der Berechtigung Abrechnung und Lizenzen verwalten; Lizenzrechnungen finden Sie unter Organisationseinstellungen → Abrechnung & Nutzung → Abrechnung.

• Offen, noch nicht abgerechnet zeigt, was auf der nächsten Rechnung erscheint.
• Eine Kreditlinie begrenzt den noch nicht abgerechneten Verbrauch. Mit der nächsten Rechnung wird der Betrag wieder frei. Ohne Kreditlinie kann nichts abgerechnet werden.
• Hat der Workspace zusätzlich Guthaben, wird dieses zuerst verbraucht.

Abrechnungsart und Kreditlinie werden mit DeutschlandGPT vereinbart. Für Änderungen wenden Sie sich an den Support.

Nutzungsübersicht

Der Tab Guthaben zeigt Ihr Guthaben und die jüngsten Ausgaben. Unter Nutzung sehen Sie die Ausgaben nach API-Schlüssel, Modell und Zeitraum und exportieren sie als Tabelle. Siehe Dashboard.

Benachrichtigungen

Im Tab Benachrichtigungen der Abrechnung schaltet der Hauptschalter Benachrichtigungs-E-Mails senden alle Abrechnungs-E-Mails ein oder aus. Darunter wählen Sie die einzelnen Benachrichtigungen:

Jede Benachrichtigung wird höchstens einmal in 24 Stunden verschickt.

Rechnungen

Zu jedem Guthabenkauf gibt es eine Rechnung. Laden Sie sie im Guthabenverlauf über Rechnung herunterladen herunter, oder finden Sie alle Rechnungen im Abrechnungsportal hinter Zahlungsmethoden verwalten. Rechnungen werden gemäß §147 AO 10 Jahre aufbewahrt.