Rate Limits

Überblick

Concurrency-Limits sorgen für faire Nutzung und eine stabile API. Wie viele Jobs gleichzeitig laufen können, hängt von deinem Plan ab.

Limits nach Plan

Dein Plan bestimmt deine Concurrency, die pro Modell festgelegt und pro Nutzer gezählt wird. Höhere Plan-Tiers können mehr Jobs gleichzeitig ausführen. Backlogging ist außerdem für Zero Data Retention-Anfragen und für einige Modelle deaktiviert, auch bei Plänen, die es sonst erlauben. Krea-2-Anfragen werden derzeit in keinem Plan in den Backlog gestellt.

Job-Backlog

Wenn Backlogging verfügbar ist, werden Jobs, die du über dein Concurrency-Limit hinaus einreichst, mit status: "backlogged" angenommen. Sie starten in der Reihenfolge ihrer Einreichung, sobald laufende Jobs abgeschlossen sind. Es gibt keine separate Obergrenze für den Backlog. Wenn Backlogging nicht verfügbar ist, kann ein weiterer Job mit HTTP 429 abgelehnt werden, statt in die Warteschlange gestellt zu werden. Die Obergrenze ist ungefähr: Ein kurzer Burst kann trotzdem darüber hinaus angenommen werden. Wiederhole die Anfrage bei 429 mit Backoff, nachdem laufende Jobs abgeschlossen sind. Body und Header findest du unter Fehler und Debugging.

Best Practices

• Exponential Backoff implementieren – Warte zwischen Retries schrittweise länger
• Anfragen client-seitig in eine Queue stellen – Ein Burst kann über die Obergrenze hinaus angenommen werden, verlass dich also nicht darauf, dass die API die nächste Anfrage stoppt
• Nutzung überwachen – Verfolge die Anzahl der Anfragen, um innerhalb der Limits zu bleiben
• Webhooks verwenden – Reduziere Polling-Anfragen durch Webhooks für den Job-Abschluss

Nächste Schritte