Deine Credit-Buchungen lesen: jede Abbuchung, jede Erstattung

Das Guthaben liegt 180 unter dem, was deine Rechnung sagt, oder 180 darüber – so oder so willst du wissen, warum, bevor du es einem Kunden erklärst. Das Request-Log beantwortet das, aber nur, wenn du weißt, was es aufzeichnet: Es ist ein Protokoll von Bewegungen, keine Liste erfolgreicher Generierungen, und das sind zwei verschiedene Listen.

Eine Zeile pro Bewegung

Jeder Credit, der sich bewegt, schreibt eine Zeile. Die Zeile enthält den Zeitpunkt, den Vorgang, die Modell-ID und einen Credit-Betrag mit Vorzeichen – und genau das zeigt dir der Bereich Request-Log im Entwickler-Dashboard.

Es gibt sechs Vorgänge, und nur diese Werte wirst du in der Spalte sehen:

• chat – eine Antwort von RP+ oder RP mini, inklusive der zusätzlichen 2 Credits pro angehängtem Bild, wenn Vision genutzt wird.
• image – ein Aufruf zur Bildgenerierung. Ein Batch aus vier Bildern ist eine Zeile, nicht vier.
• video – ein eingereihter Clip.
• speech – ein Text-to-Speech-Aufruf, abgerechnet pro angefangenem Block von 100 Zeichen.
• transcription – ein Speech-to-Text-Aufruf, abgerechnet pro angefangener Audiominute (die gemessene Länge steht in den Details der Zeile).
• storage – ein Upload in den eroq Store, 2 Credits pro angefangenen 10 MB.

Das Log gilt für den ganzen Workspace, die Aufrufe deiner Teamkollegen stehen also auch drin, und es umfasst die letzten 30 Tage in Seiten zu je fünfzig Zeilen. Die Modellspalte zeigt die öffentliche Modell-ID – eroq-image-anime, seedance-2-5, eroq-voice-turbo –, also genau den String, den du im Request übergeben hast. So lässt sich jede Zeile bis zu einem bestimmten Aufruf in deinen eigenen Logs zurückverfolgen.

Abgebucht beim Absenden, nicht bei der Lieferung

Die Regel, die die meisten verwirrenden Buchungen erklärt: Credits werden ausgegeben, bevor die Engine läuft, nie danach. Erst bei Erfolg abzubuchen klingt fairer, lässt sich aber nicht umsetzen – ein Client, der mitten im Stream auflegt, bekäme sonst jedes Mal eine Generierung geschenkt.

Die Abbuchungszeile existiert also ab dem Moment, in dem dein Request angenommen wird. Ein Videoclip wird abgebucht, wenn der Job in die Warteschlange kommt, nicht wenn die Datei eintrifft. Ein Batch aus vier Bildern bucht 40 Credits ab, bevor das erste Pixel gezeichnet ist. Fair wird das durch die andere Hälfte der Regel: Fehlschläge geben die Credits zurück.

Eine negative Zeile ist eine Erstattung

Erstattungen werden als zweite Zeile mit negativem Betrag geschrieben, in der Tabelle mit Erstattung markiert und mit Pluszeichen angezeigt – denn im Buchungsprotokoll ist eine Erstattung Geld, das zu dir zurückfließt.

Erstattungen laufen automatisch und decken jede Art ab, auf die eine Generierung scheitern kann: eine Engine, die nichts zurückgegeben hat, ein Prompt, den die Engine blockiert hat, ein Videojob, der nach seiner Frist von zehn Minuten noch nicht fertig ist, ein Chat-Stream, der abbrach, bevor er ein Token ausgab, ein Upload, der nach der Abbuchung fehlschlug. Du musst nichts beantragen und kein Support-Ticket eröffnen.

Am Betrag erkennst du, was schiefging. Eine Video-Erstattung ist immer der volle Clippreis, denn ein Clip kommt entweder an oder nicht. Eine Bild-Erstattung ist eine Einheit – 10 Credits – pro fehlgeschlagenem Take; ein Batch aus vier Bildern mit zwei Nieten zeigt also eine Abbuchung über 40 Credits und zwei separate Erstattungen über je 10 Credits. In dieser Asymmetrie steckt die ganze Diagnose: Eine Teilerstattung auf einer Bildzeile heißt, dass ein Teil deines Batches leer zurückkam.

Ein Guthaben abgleichen, Schritt für Schritt

Angenommen, eine Session zeigt Folgendes, das Neueste oben, in einem Workspace, der den Tag mit 5.000 Credits begonnen hat:

video   seedance-2-5      +310   (refund)
video   seedance-2-5      −310
image   eroq-image-one     +10   (refund)
image   eroq-image-one     −40
video   eroq-motion-one   −60

Lies von unten nach oben. Ein Fünf-Sekunden-Clip mit Motion One kostete 60 und wurde geliefert. Ein Batch aus vier Bildern kostete 40, ein Take kam leer zurück und wurde mit 10 erstattet, drei Bilder kosteten also 30. Ein Fünf-Sekunden-Clip mit Seedance 2.5 buchte 310 ab und erstattete 310 – er wurde nie geliefert und hat nichts gekostet.

Die Nettobewegung beträgt 90 Credits, das Guthaben steht bei 4.910. Fünf Zeilen, drei Ergebnisse, ein kostenloser Fehlschlag. Daraus folgen zwei Dinge. Erstens: Die Tagessummen im Diagramm verstehen sich abzüglich Erstattungen, die angezeigte Zahl ist also das, was du tatsächlich ausgegeben hast. Zweitens: Der Request-Zähler zählt nur Zeilen mit positivem Betrag, also Abbuchungen – eine Erstattung ist kein Request –, deshalb weichen Request-Anzahl und Zeilenanzahl an jedem Tag mit einem Fehlschlag voneinander ab.

Herausfinden, wer es ausgegeben hat

Das Log schlüsselt die Ausgaben nicht nach Personen auf, denn dafür gibt es den Tab Mitglieder in deinem Workspace. Jede Mitgliederzeile zeigt die in diesem Kalendermonat ausgegebenen Credits, abzüglich Erstattungen und nach unten bei null begrenzt.

An genau dieser Spalte wird auch ein monatliches Limit pro Mitglied gemessen, und die Verrechnung ist Absicht: Ein Freelancer, dessen Render fehlschlug und sich selbst erstattet hat, hat nichts von seinem Kontingent verbraucht. Das Limit setzt sich am Monatsersten zurück, und ein Admin kann es anheben, ohne jemandes Rolle anzufassen.

Die Zuordnung zu einem Schlüssel läuft über dieselbe Spalte statt über eine eigene. Jede Buchungszeile vermerkt den API-Schlüssel, der den Aufruf gemacht hat – Aufrufe aus dem Studio vermerken keinen, weil eine Browser-Session kein Schlüssel ist –, und ein Schlüssel gehört genau einem Mitglied und erbt dessen Rolle. Ausgaben pro Mitglied sind also Ausgaben pro Schlüssel, zusammengefasst nach Inhaber. Gib jeder Integration einen eigenen Platz als Mitglied, wenn die Aufteilung sauber sein soll; was jede Stufe darf, steht in Workspace-Rollen und Berechtigungen.

Die Sicht der API ist enger

GET /v1/account liefert dir ein Guthaben und eine Zusammenfassung über 30 Tage:

{
  "object": "account",
  "credits": 4870,
  "usage_30d": { "requests": 213, "credits": 9614 }
}

Ein Haken, der Leute einen ganzen Nachmittag kostet: Dieser Endpunkt bezieht sich auf das Konto, dem der Schlüssel gehört, das Log im Dashboard dagegen auf den Workspace. In einem Solo-Workspace stimmen beide überein. In einem geteilten nicht – das usage_30d deines Schlüssels lässt alles weg, was deine Teamkollegen aus demselben Guthaben ausgegeben haben, obwohl credits genau das gemeinsame Guthaben ist, von dem alle zehren. Für Workspace-Summen liest du das Dashboard, für „Was hat der Inhaber dieses Schlüssels gemacht?“ /v1/account.

Auch usage_30d.credits versteht sich abzüglich Erstattungen, und requests zählt nur Abbuchungen, genau wie das Diagramm.

Die Zeilen, mit denen niemand rechnet

Zwei Muster stecken hinter den meisten Fragen der Art „Was ist das für eine Zeile?“.

Eine storage-Zeile neben einer Generierung. Mit store: true wird das Ergebnis im eroq Store gespeichert und eine CDN-URL zurückgegeben, zusätzlich berechnet mit 2 Credits pro angefangenen 10 MB. Das ist eine zweite Zeile mit dem Modell eroq-store – deshalb steht ein Bild für 10 Credits manchmal mit 12 in der Liste. Einen Render in deiner Bibliothek zu speichern ist kostenlos und schreibt überhaupt keine Zeile – das tut nur der Store.

Mehrere chat-Zeilen für eine Unterhaltung. Chat wird pro Antwort abgerechnet, eine Szene mit zwölf Runden ergibt auf RP+ also zwölf Zeilen zu je 3 Credits. Mehr zur Preisgestaltung für diese Art von Nutzung steht in Credit-Preise für KI-APIs, mehr zu Team-Guthaben in KI-Credits im Team verwalten.

Öffne das Request-Log und gleich deine letzte Session ab – sobald du weißt, welche Zeilen Erstattungen sind, dauert das etwa eine Minute.

Häufige Fragen

Warum sinkt mein Guthaben, bevor der Render fertig ist?

Weil Credits abgebucht werden, wenn ein Job angenommen wird, und nicht erst, wenn er geliefert wird – nur so bekommt ein abgebrochener Request keine Generierung geschenkt. Schlägt der Render fehl, läuft er in eine Zeitüberschreitung oder wird er blockiert, bringt eine Erstattungszeile die Credits automatisch zurück. Dein Guthaben landet so oder so da, wo es hingehört.

Was bedeutet eine negative Zahl in der Credit-Spalte?

Es ist eine Erstattung, die ins Guthaben des Workspace zurückfließt – deshalb markiert die Tabelle die Zeile und zeigt sie mit Pluszeichen an. Jede Erstattung nennt den Vorgang und das Modell, das sie rückgängig macht, sodass du sie der Abbuchung darüber zuordnen kannst. Blockierte Prompts, fehlgeschlagene Renders und Jobs nach Ablauf ihrer Frist erzeugen alle eine.

Warum weichen die Summen im Dashboard von dem ab, was mein API-Schlüssel meldet?

Das Log im Dashboard umfasst den ganzen Workspace, GET /v1/account nur das Konto, dem der Schlüssel gehört. Bei einem gemeinsamen Guthaben fallen die 30-Tage-Werte des Schlüssels niedriger aus als die des Workspace, weil die Ausgaben deiner Teamkollegen nicht deinem Konto zugerechnet werden. Das Guthaben in credits ist gemeinsam, das stimmt also immer überein.

Wie weit reicht das Request-Log zurück?

Dreißig Tage, geladen in Schritten von fünfzig Zeilen. Das Tagesdiagramm deckt denselben Zeitraum ab; wenn du eine längere Historie brauchst, exportiere also, was du brauchst, bevor es herausfällt. Die monatlichen Ausgaben pro Mitglied im Tab Mitglieder des Workspace werden über den laufenden Kalendermonat berechnet – noch einmal ein anderer Zeitraum.