KI-generierte Medien speichern und per CDN ausliefern

Die Medien zu generieren ist die Hälfte, die alle einplanen. Die Hälfte, die dich kalt erwischt, ist das, was in den neunzig Sekunden danach passiert: ob du Bytes oder einen Link bekommen hast, wie lange dieser Link lebt, wo die Datei landet und wer dafür bezahlt, sie an einem Freitagabend an hunderttausend Leute auszuliefern.

Hier steht, was die eroq API für jeden Medientyp zurückgibt, was die kostenlose Bibliothek der Kreationen vom kostenpflichtigen Store unterscheidet und welche kurze Liste von Dingen du in jedem Fall selbst aufbewahren solltest.

Was dir die API wirklich zurückgibt

Drei Endpunkte, drei verschiedene Antworten.

Bilder – POST /v1/images/generations gibt das Bild standardmäßig inline als Base64 in b64_json zurück oder als URL, wenn die Engine mit einer URL antwortet. Die URL-Form forderst du mit response_format an. Details unter /docs/images.

{
  "created": 1756118400,
  "model": "eroq-image-one",
  "data": [{ "b64_json": "UklGRl4jAABXRUJQ…" }],
  "usage": { "credits_spent": 10, "credits_remaining": 987 }
}

Video – asynchron. Du schickst den Auftrag ab, fragst den Status ab, und der fertige Job enthält den Clip inline als Base64-MP4. Dieser Payload wird 24 Stunden lang aufbewahrt. Danach ist der Job nur noch ein Eintrag, keine Datei mehr. Siehe /docs/video.

Sprache – POST /v1/audio/speech gibt überhaupt kein JSON zurück. Der Response-Body ist die MP3, audio/mpeg, bereit, um direkt in eine Datei oder ein Audio-Element zu fließen. Die Stimmparameter stehen unter /docs/speech.

Der eine Satz, den du aus diesem Abschnitt mitnehmen solltest: Nichts davon ist eine dauerhafte URL, solange du nicht ausdrücklich eine anforderst. Ein Base64-Payload ist ein Liefermechanismus, kein Speicher, und ein 24-Stunden-Fenster ist eine Schonfrist, in der deine Pipeline handeln muss – keine Aufbewahrungsrichtlinie, auf der du ein Produkt aufbauen kannst.

Die Bibliothek der Kreationen – kostenlos, aber nicht deine Speicherschicht

Jedes Bild, jedes Video und jede Sprachausgabe, die über /v1 entsteht, wird außerdem automatisch und kostenlos in deiner Bibliothek der Kreationen gespeichert, mit dem vollständigen Rezept in meta – Modell, Einstellungen des Regiepults, Sekunden, Referenzen, alles, was du zum Reproduzieren brauchst. Jedes generierte Element trägt eine library_id.

curl https://eroq.ai/v1/creations \
  -H "Authorization: Bearer $EROQ_API_KEY"

{
  "folders": [{ "id": "…", "name": "Campaign A" }],
  "creations": [{
    "id": "…", "kind": "video", "url": "https://…", "model": "eroq-motion-one",
    "prompt": "slow pan over the rooftop", "meta": { "seconds": 10, "shot": "push-in" }
  }]
}

GET /v1/creations/{id} holt einen Eintrag mit seinem vollständigen Rezept, PATCH verschiebt ihn zwischen Ordnern, DELETE entfernt ihn samt Datei, und für Ordner gibt es das passende CRUD. Es ist dieselbe Bibliothek, die das Studio zeigt: Ein Render, den dein Backend erstellt hat, ist für dein Team sichtbar, und ein Render deines Teams ist für dein Backend sichtbar.

Nutze sie als Rezeptprotokoll und gemeinsamen Arbeitsbereich, nicht als CDN deines Produkts. Sie beantwortet die Frage „Was genau haben wir geschickt, um das hier zu bekommen?“ – und die stellst du öfter, als du denkst. Meist in der Woche, nachdem ein Kunde einen Look abgesegnet hat und du vierzig weitere davon brauchst.

Der eroq Store – dauerhafte URLs im CDN

Wenn du einen Link willst, der die Anfrage überdauert, lad die Datei hoch:

curl -X POST https://eroq.ai/v1/storage/objects \
  -H "Authorization: Bearer $EROQ_API_KEY" \
  -F [email protected] \
  -F name="poster.webp"

{
  "id": "0b52…",
  "object": "storage.object",
  "url": "https://store.eroq.ai/acc_…/8c1f2-poster.webp",
  "bytes": 482133,
  "content_type": "image/webp",
  "usage": { "credits_spent": 2, "credits_remaining": 880 }
}

Die URL ist sofort live und wird über ein globales CDN ausgeliefert. Dateien dürfen bis zu 100 MB pro Objekt groß sein, GET /v1/storage/objects listet deine aktiven Objekte mit ihren URLs, und DELETE /v1/storage/objects/{id} entfernt eines – sofort am Origin, während sich die Edge-Caches innerhalb von Minuten leeren.

Der Preis: einmalig 2 Credits je angefangene 10 MB. Entscheidend ist das Wort „angefangen“: Ein Bild mit 1024×1024 ist ein Block, also 2 Credits. Ein Clip mit 4 MB ist ein Block. Ein Clip mit 11 MB sind zwei, also 4 Credits. Abgerechnet wird einmal, beim Upload – danach bleibt die Datei gespeichert, solange das Konto besteht, und die Auslieferung ist im Rahmen von Fair Use inklusive. Löschen erstattet nichts, weil der Speicher verbraucht wurde.

Es gibt auch eine Abkürzung mit einem einzigen Aufruf. Beide Generierungs-Endpunkte akzeptieren store: true: Der Render wird gespeichert, und die Antwort enthält statt Base64 eine dauerhafte CDN-URL. Der Store-Tarif wird zusätzlich berechnet und in deinem Nutzungsprotokoll separat aufgeführt:

curl -X POST https://eroq.ai/v1/videos/generations \
  -H "Authorization: Bearer $EROQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "eroq-motion-one",
    "prompt": "Rain crawls down a diner window while a waitress refills a cup without looking up, street neon bleeding through the glass. Static shot, 35mm film, practicals, neon noir palette, calm tempo.",
    "seconds": 5,
    "aspect": "9:16",
    "store": true
  }'

Für eine Pipeline, die ihre Ergebnisse ohnehin immer behält, ist das ein Roundtrip statt zwei – und das Zeitfenster, in dem ein Render nur im Arbeitsspeicher existiert, fällt weg.

Warum Hosting unter derselben Richtlinie steht wie die Generierung

Generierung und Hosting kommen meist von zwei Anbietern, mit zwei Nutzungsrichtlinien, zwei Rechnungen und zwei Sätzen Schlüssel – und an der Naht dazwischen gehen Renders verloren oder werden ein zweites Mal nach Regeln beurteilt, die für das Produkt von jemand anderem geschrieben wurden.

Der Store schließt diese Naht: Er ist Objektspeicher und CDN, direkt in die Generierung eingebaut, und unterliegt derselben schriftlichen Nutzungsrichtlinie wie die Modelle selbst. Was die API im Rahmen der Richtlinie für dich generiert, hostet auch der Store. Genau deshalb gibt es ihn; das CDN ist Pflichtprogramm.

Außerdem ist alles standardmäßig privat. Renders landen in deiner Bibliothek der Kreationen und bleiben privat in deinem Workspace, bis du sie veröffentlichst. Der Privatmodus – ein Schalter im Studio oder private: true an den Bild- und Video-Endpunkten – überspringt sogar das: keine Datei, kein Eintrag in der Bibliothek, und der Prompt erscheint im Nutzungsprotokoll nur als Sternchen. Wenn du Infrastruktur für ein unzensiertes Produkt auswählst, findest du die Abwägungen im Leitfaden zur unzensierten KI-API.

Was du selbst aufbewahren solltest

Egal, wofür du dich bei den Bytes entscheidest: Diese Dinge gehören in deine eigene Datenbank. Sie alle sind billig zu speichern und teuer zu rekonstruieren.

• Den vollständigen Request-Payload. Prompt, Modell, Sekunden, Seitenverhältnis, jeden Parameter des Regiepults. Die Bibliothek hebt das Rezept zwar auch auf, aber deine eigene Kopie überlebt einen Anbieterwechsel.
• Die Job-ID und den Kunden, zu dem der Job gehörte. Bei einem gemeinsamen Guthaben ist die Kostenabrechnung pro Kunde deine Aufgabe, und diesen Join kannst du im Nachhinein nicht mehr machen.
• usage.credits_spent, pro Render. Übernimm den Wert aus der Antwort. Ausgaben später aus einer Preisliste zu rekonstruieren, ist der Anfang jedes Abrechnungsstreits.
• Den Seed, bei Engines, die einen berücksichtigen – er macht den Unterschied zwischen „Wir können noch so einen Take machen“ und „Wir hatten einmal Glück“. Mehr unter /glossary/seed; welche Engine was kann, steht unter /models.
• Eine Kopie der Bytes, wenn das Medium ein Liefergegenstand ist, den du jemandem schuldest. Nicht, weil eine bestimmte URL kaputtgehen wird, sondern weil eine Datei, für die ein Kunde bezahlt hat, nicht an genau einem einzigen Ort liegen sollte.

Ausliefern, ohne doppelt zu zahlen

Lass deine <img>- und <video>-Tags direkt auf die CDN-URL zeigen. Leite Medien nicht über deinen Anwendungsserver – du zahlst die Bandbreite doppelt, fügst einen zusätzlichen Hop Latenz hinzu und machst aus einem statischen Asset einen Request, über den dein Autoscaler nachdenken muss.

Zwei praktische Hinweise für Video. Gib jedem Clip ein Posterbild, denn ein Video-Element ohne Poster ist ein graues Rechteck, bis der erste Frame dekodiert ist – und in einem Feed wirkt das wie eine kaputte Seite. Und setz die dauerhafte URL in dem Moment, in dem der Render ankommt: Dein Webhook-Handler oder deine Polling-Schleife ist der richtige Ort zum Kopieren oder Speichern, nicht ein nächtlicher Job, der erst läuft, wenn das 24-Stunden-Fenster schon geschlossen ist.

Häufige Fragen

Wie lange speichert eroq ein generiertes Video?

Der fertige Clip ist 24 Stunden lang inline im Job verfügbar. Wenn du eine dauerhafte URL brauchst, sichere ihn vorher – entweder mit store: true beim Generierungsaufruf oder indem du ihn danach in den eroq Store hochlädst.

Was kostet das Hosting von Medien im eroq Store?

Einmalig 2 Credits je angefangene 10 MB, abgerechnet beim Upload. Ein typisches Bild mit 1024×1024 ist ein Block, ein Clip mit 11 MB sind zwei. Die Auslieferung über das CDN ist im Rahmen von Fair Use inklusive, und das Löschen eines Objekts erstattet den Upload nicht.

Ist die Bibliothek der Kreationen dasselbe wie der Store?

Nein. Die Bibliothek speichert jeden Render automatisch und kostenlos mit seinem vollständigen Rezept und ist zum Wiederfinden und Remixen gedacht. Der Store ist kostenpflichtiges, dauerhaftes Objekt-Hosting mit CDN-URLs, die du direkt deinen Nutzern ausliefern kannst.

Lies dir die Speicher- und Medien-Endpunkte unter /docs durch und leg fest, wohin jeder Render geht, bevor du ihn renderst.